The Tool Schema Can Lie to You

A tool schema is a promise a server makes once, at discovery, and an agent is expected to keep trusting for as long as the connection lasts. The Model Context Protocol has no mechanism that requires a server to keep that promise. Nothing stops a server from advertising one schema when an agent lists its tools and quietly serving a different one, with different parameters or a materially different effect, by the time that agent actually calls it. "MCP Server Security" named this as a risk in passing: a compromised or malicious server changing its own tool schema between discovery and call time. It deserves treating as its own failure mode, because the thing that makes it dangerous isn't the mechanism, it's how naturally it survives every review process built around trusting discovery.

Discovery happens once, calls happen many times

An agent typically lists a server's tools when a session starts, reads each tool's name, description, and parameter schema, and builds its working understanding of what's safe to call and how. That snapshot then gets trusted for the life of the session, sometimes far longer if the agent framework caches it. But the schema an agent read at discovery is not a contract the server is bound to. It's a string of JSON the server chose to return at that moment, and nothing in the protocol says it can't return something else, to the same tool name, the next time it's asked.

A changed schema and a lying one look identical from the outside

Re-registration isn't limited to obviously malicious servers. A legitimate server can update a tool's parameters between one deployment and the next, and from the agent's side that update is indistinguishable from an attacker widening a tool's effective scope after the agent already decided to trust it. Either way, the agent is now acting on a schema it never actually saw. A review process that vets a server once, at onboarding, and treats that review as valid for every call that follows, is reviewing a moment that has already passed by the time any call happens.

Trusting a schema because you saw it once is trusting a version of the tool that may no longer exist.

Check the call, not the handshake

The fix isn't a better discovery-time review. It's not trusting discovery as authoritative in the first place. Every outgoing MCP call carries a tool name, the schema it claims to implement, and the arguments being passed, regardless of transport, whether that's stdio, SSE, or HTTP. Evaluating that triplet against policy at call time, on every call, rather than relying on what was read once at discovery, is what actually closes the gap: a schema that drifted after registration gets caught at the moment it matters, because nothing about the decision depends on a session-start snapshot that's since gone stale.

Discovery tells an agent what a server says it can do. Only checking the call itself tells you what it's actually asking to do right now, and that's the check that has to hold every time, not just the first.

Sources

• Tools. Model Context Protocol specification, version 2026-07-28. A server's tool list may change over time and the protocol provides a notification for it; clients must treat tool annotations as untrusted unless they come from trusted servers.
• MCP Security Notification: Tool Poisoning Attacks. Invariant Labs, April 2025. Describes "rug pull" attacks, where a malicious server changes a tool's description after the client has already approved it.