Swapping every leaf value for a marker string clears the schema on 42% of 265 MCP tools

A vacuous verdict is narrower than it sounds. Holding structure and type constant means the probe asks one question: does the schema constrain values? A schema that lists required keys and their types validates the corrupted payload, because nothing about the payload's shape changed. That same schema would still reject a response that lost half its fields mid-stream. The clearest case in the sample is a tool declaring `outputSchema: {type: "object"}`, which validates any object, including a corrupted one ^[18].

Two numbers sit under the 3% figure. 56% of the 265 tools declare no output schema, which leaves 44% declaring one ^[5]. Of those, about 7% reject the corrupted payload: 3 divided by 44 ^[1]. In absolute terms, 3% of 265 tools is roughly 8 ^[2].

For that ratio to transfer to your servers, your schemas have to have been produced the way theirs were. The scan uses no model and is deterministic; the author says every number is a property of the server ^[7]. If you hand-wrote `enum`, `pattern`, `format` or bounds constraints into your output schemas, the scan's number is not about you, and those value-level constraints are the author's stated condition for closing the gap ^[9].

Writing on dev.to, mcp-drill's author said that "coverage is a vanity metric here" ^[17]. FastMCP infers schemas from return type hints, which pushes coverage toward 100% while enforceability stays near 0% ^[10].

Where a server declares nothing, the client has no contract to check against, and the only automatic guard left is that the transport succeeded ^[11]. Where it declares a vacuous schema, validation runs and the corrupted response passes. The author's example of the second case is a `fetch` tool that returns `{"result": "ok"}` with status 200 even when the tool name is wrong ^[12]. "Your agent cannot tell a bad result from a good one," he wrote ^[16].

This is a different question from the one security scanners ask. According to the post, mcp-scan asks whether a server can be abused to do something evil, while mcp-drill asks whether a server can be trusted when it returns a result ^[15]. Generic HTTP fault injectors cannot run either test, because MCP is JSON-RPC over stdio or Streamable HTTP with bidirectional notifications ^[4]. `mcp-drill scan --json` writes the probe results for your own servers to a file, and `--badge` emits a shields.io endpoint ^[14].