Why a clean scan isn't a safety guarantee

What "structural" means here

Every check this tool runs looks at the shape of the launch config itself: is a server started with filesystem or shell access broader than it likely needs, is a secret written directly into the config instead of referenced from an environment variable, is a package or container image launched without a version pin so it can silently change on the next run, and do any two servers you've loaded together claim the same tool name. These are exactly the mistakes a careful human reviewer would look for by eye — mechanized so they don't get missed on a rushed review.

What it can't see

A structural scan has no way to know whether a pinned package version itself carries a known vulnerability or a supply-chain compromise, whether a server's actual runtime behavior matches what its tool descriptions claim, whether a description carries hidden model-directed instruction language, or whether a server that scanned clean last week was updated to something different since. Catching those needs a registry or vulnerability lookup, a tool that diffs a captured manifest against an earlier one over time, or a human reading the server's own source — not a one-time look at the config text.

This is the same reason a linter passing doesn't mean a test suite would: they check different, complementary things.

What a clean scan is worth, then

It rules out the specific, common mistakes above, cheaply, before you launch anything — worth running every time you add or change a server. Treat it as a floor: pair it with a version-pin habit, a registry or vulnerability check on anything unfamiliar, and a periodic re-scan after updates, rather than a one-time pass you never revisit.

Common questions

If a config scan comes back with zero findings, is the setup safe?

No. A zero-finding result means none of this tool's mechanical checks fired against the text you pasted — it does not mean the servers you're launching are safe. The scan looks at structure (broad filesystem or shell access, hardcoded secrets, missing version pins, duplicate tool names), not at what a server's code actually does when it runs, and it cannot see a vulnerability, a compromise, or a malicious update that hasn't yet shown up as one of those structural patterns.

What can a structural config scan actually catch?

Patterns visible in the launch config itself: a server started with broad filesystem or shell scope it may not need, a secret written directly into the config instead of referenced from an environment variable, a package or image launched without a version pin (so it can change under you on the next run), and tool names that collide or shadow each other across servers you've loaded together. These are the same category of mistake a careful human reviewer would look for — structural, not behavioral.

What can't it catch?

Anything that isn't visible as a pattern in the config text: whether a pinned package version itself contains a vulnerability or a supply-chain compromise, whether a server's actual runtime behavior matches what its description claims, whether a tool's description carries hidden model-directed instructions, or whether a server that looked fine yesterday was updated to something different today. Those need a registry/vulnerability check, a manifest-diff tool run over time, or a human reading the server's own source — not a one-time structural scan of the config.

So what is a clean scan actually worth?

It rules out the specific, common mistakes the scan checks for, cheaply and before you launch anything — the same value a linter has before a test suite runs. It is a floor, not a ceiling: worth running every time you add or change a server, and worth pairing with the practices that catch what it can't see, not a substitute for them.