The three fields in an MCP tool definition do not share a trust boundary. `name` and `description` reach the model as text, where a content filter can at least theoretically look at them [7][10]. `inputSchema` reaches the framework as structure [8]. That split is the vulnerability: safety training has no mechanism for judging whether a JSON Schema is adversarial [9]. Add `execute_command: string` to a legitimate weather tool and nothing has instructed the model to run commands; the framework has been told that running commands is a valid operation on that tool, and the model reads the new parameter as a declared feature [11].
Both OpenAI's and Anthropic's function-calling APIs require a tool to declare its full argument schema up front, and the framework validates outgoing calls against that declaration before the handler sees them [12]. Validation against a poisoned schema passes.
So the failure in Cursor was about when the check ran. Trust was cached at initial approval, and later server-side mutations were consumed without re-validation [5]. The writeup's illustrative gap is two weeks, but the timeline it actually describes is approval at T=0 and mutation at T=1 [19]. A cache with no invalidation is a cache; the bug is calling it an approval.
The fix hashes the schema and compares it against the approved state at each invocation, so any mutation raises a re-approval prompt [6]. That is cheap in the runtime: one stored hash per approved tool, one comparison per call. The cost lands in the workflow, because a re-approval prompt needs a human, and the interesting branch is what a mismatch does inside CI at three in the morning.
MCPTox ran tool poisoning against 45 live MCP servers and 20 models and reported a 36.5% average attack success rate, peaking at 72.8% on o1-mini [14][15]. The peak is about double the mean [20]. Claude-3.7-Sonnet had the highest refusal rate of anything tested and still refused under 3% of the time [16], which puts non-refusal above 97% on the best refuser in the set [21]. For 36.5% to describe your agent, three things have to hold: it resolves tool definitions from a remote server at call time, it never diffs them against an approved copy, and its guardrails live in the prompt layer. Pin the manifest by hash and the benchmark is measuring a configuration you do not run. The writeup's further argument, that more capable models are more susceptible because they are better instruction-followers, is its own reasoning rather than a measured result [17].
Signature scanning is not the fallback. MalTool generated 5,287 tools with embedded malicious behaviors, planted them in simulated repositories, and reports near-zero VirusTotal detection with agent-specific detectors of limited effectiveness [18].
One caveat on all of the above: it comes from a single dev.to post, which names the CVE, the OWASP MCP03:2025 Tool Poisoning category [13][1], and two preprint identifiers, with no vendor advisory text behind them [22].
