Scanner failure

What mcp-scan saw

Each of the sixteen scanners runs inside a try/catch wrapper. When one throws, the wrapper converts the exception into this finding, naming the scanner and the server and carrying the error message. The scan continues with the remaining scanners.

Why it fires

The isolation is the point: without it one malformed server entry would abort the run and hide every other server's findings. This finding tells you that a specific check produced no result for a specific server, so a clean report for that server is incomplete rather than good.

When this is a false positive

• This is never a finding about your server's security. It is a tool bug or an environment problem, so the right response is to read the error, not to assess risk.
• A config shape the parser did not expect, for example args expressed as an object rather than an array, or env values that are numbers or booleans.
• A sandboxed or offline environment where a network scanner throws on a blocked connection instead of timing out cleanly.
• A filesystem permission error when the env-leak scanner walks up into a directory it cannot read.

How to fix it

1. Read the error message in the finding. It names the failing scanner and the server, which is usually enough to reproduce.
2. Re-run with --verbose to get the surrounding detail from the logger.
3. Check the server entry's shape: args should be an array of strings, env should be string values.
4. If the run was offline or sandboxed, re-run with --offline so the network-dependent scanners take their bundled-snapshot path instead of throwing.
5. Treat that server's report as incomplete until the scanner runs clean, since the failing check contributed nothing.
6. If the config is well formed and it still throws, open an issue on the mcp-scan repo with the offending entry.