Tool descriptions become security contracts: 253 bugs in 273 MCP servers, most without a crash
Synopsis
When a large language model calls an external tool, the orchestration layer checks that the call is well formed, not that its arguments are safe. ToFu turns the argument semantics already documented in tool metadata into executable security checks, then generates fuzzing inputs and oracles from them, confirming 253 bugs across 343 tools in 118 of 273 runnable MCP servers, most of which returned normally.
Interpretation
Whether a tool implementation honors the input semantics it advertises can now be tested automatically, without first engineering a successful prompt injection. Earlier analyses started from predefined weakness classes, specific taint flows, or particular agent-tool attacks, so coverage was bounded by what the analyst anticipated. Across 273 cleanly executable MCP servers, ToFu flagged 118 servers with 253 manually verified bugs spanning 343 tools.
The starting point is metadata the tool already exposes to the model: argument names, natural-language descriptions, and input schemas. A string may denote a path, a URL, or a command, each with different security constraints, so the primitive type alone cannot select a check. ToFu uses 74 semantics-aware sanitizers: 11 run on every execution, 35 run when their evidence appears, and 27 are selected by an LLM from argument semantics; the LLM only maps and seeds, and never serves as the oracle.
Detection does not rely on crashes but on whether a tool accepted an input its own contract should have rejected. Conventional fuzzing oracles such as crashes, assertion failures, and memory violations miss tools that read an out-of-workspace file or contact a prohibited destination and still return normally. Of the 508 flagged candidates, 326 were confirmed by directly observing a dangerous operation or an unescaped adversarial value in the output, and the remaining 182 were inputs that violated a semantic constraint while the tool reported success.
Perspective
The findings cover 273 cleanly executable MCP servers and the 3405 tools extracted from them, drawn from Python and JavaScript repositories filtered by stars, non-archived status, and non-client role. The method targets single tool invocations issued through an orchestration layer and requires the tool to run in the current environment; Python targets can be observed through 21 tracers over file, process, and network operations, while JavaScript targets have no in-process tracer and rely on input contracts and outcome checks.
The authors note that roughly one fifth of the servers flagged only by static baselines involve permissive CORS configurations, incorrect sanitizing regular expressions, or file-system races, which single-input fuzzing is not suited to. Four servers affected the evaluation host during fuzzing, motivating sandboxed execution. Multi-agent execution paths, third-party component coverage, and stateful call sequences are left to future work.