The Description-Code Inconsistency Blind Spot

A June 3, 2026 measurement study of 2,214 real-world Model Context Protocol servers found that nearly one in ten tool descriptions do not match what the underlying code actually does. The mismatch is invisible to any agent relying on the description to decide whether a tool call is safe.

On June 3, 2026, a research team from Fudan University, Yutao Shi, Xiaohan Zhang, Xiangjing Zhang, Xihua Shen, Hui Ouyang, Huming Qiu, and Mi Zhang, along with Min Yang, published a large-scale measurement study of a structural weakness in the Model Context Protocol, the emerging standard that lets large language models discover and invoke external tools. The Model Context Protocol depends on a simple mechanism: an LLM reads a natural-language description of what a tool does and uses that description to decide whether and how to call it. The paper's central finding is that this mechanism rests on an assumption that is not mandatorily verified in practice: that a tool's description faithfully reflects what its underlying code actually does. When it does not, the researchers name the resulting problem Description-Code Inconsistency, or DCI.

Applying an automated detection framework called DCIChecker, which combines structure-aware static analysis with a method the authors call Direct-Reverse-Arbitration prompting, to a dataset of 19,200 description-code pairs drawn from 2,214 real-world MCP servers, the researchers found that 9.93% of pairs exhibited inconsistency, according to the paper's abstract. The paper formally defines the problem and proposes a taxonomy spanning two broad categories: functionality inconsistencies, where a tool does something different from what it claims, and undeclared side effects, where a tool does what it claims but also does something it does not disclose.

Why This Is a Different Failure Mode Than Malicious Code

Description-code inconsistency is not, by itself, evidence of malicious intent. A tool's description can drift from its implementation through ordinary software maintenance, a code update that changes behavior without a corresponding documentation update, the same failure mode that produces stale API documentation across the software industry generally. What makes DCI a distinct and more serious problem in the agentic context is that the description is not merely documentation for a human developer to read at their leisure. It is the operative interface an autonomous agent uses, at runtime, to decide whether invoking a given tool is safe and appropriate for the task at hand. A human developer who encounters stale documentation can investigate further before calling a function. An agent making that same decision at machine speed, across potentially thousands of tool invocations, has no equivalent pause built into the architecture by default.

The paper's own language captures the severity: DCI creates a "critical defense blind spot" that facilitates a spectrum of risk running from ordinary operational failures to stealthy malicious behavior. That range matters. At the benign end, an agent that trusts a stale description might simply fail at its task or produce an incorrect result. At the adversarial end, a malicious actor who controls or compromises an MCP server has a direct incentive to make the description say one thing while the code does another, since the agent's only visibility into the tool's behavior, absent DCIChecker or an equivalent verification step, is the description itself.

Where This Sits Relative to Prior Guidance

Guidance from national security agencies addressing Model Context Protocol adoption has previously emphasized the general risk of unvetted third-party components carrying excessive or unintended privileges when integrated into agent workflows, a concern the CISA-led Five Eyes advisory on agentic AI raises directly under its Design and Configuration risk category. That guidance addresses privilege scope, what a tool is allowed to do. The Fudan measurement study addresses a layer beneath that: whether the description an agent relies on to decide whether to invoke a tool in the first place is even accurate, independent of whatever privilege scope has been assigned to it. A tool can be correctly scoped in terms of its permissions and still be dangerously mischaracterized in terms of what it will actually do when called, and existing privilege-focused guidance does not resolve that separate problem.

This measurement study is the first large-scale empirical quantification of that gap specifically for MCP servers, and it arrives at a moment when MCP adoption is accelerating across the agentic ecosystem largely on the strength of the same trust assumption the paper tests: that a published tool description can be relied upon.

What DCIChecker Does Not Resolve

DCIChecker is a detection tool, not a prevention mechanism embedded in the protocol itself. It can flag inconsistencies in servers it is run against, but the Model Context Protocol as currently specified contains no requirement that a server's description be verified against its implementation before the server is published or before an agent is permitted to invoke it. The 9.93% inconsistency rate the paper measured describes the state of the ecosystem as it existed at the time of the study's data collection. It does not describe a rate that automatically improves without some mechanism, technical or institutional, requiring verification going forward.

Open Questions

• Should description-code consistency verification become a mandatory precondition for MCP server publication, and if so, who would operate that verification at ecosystem scale?
• How does an agent operator distinguish, without a tool like DCIChecker, between a tool whose description drifted through ordinary maintenance and one whose description was deliberately falsified?
• What proportion of the 9.93% measured inconsistency rate reflects undeclared side effects specifically, the category most likely to enable stealthy malicious behavior, as opposed to more benign functionality drift?
• At what point does an MCP server registry or marketplace bear responsibility for verifying description accuracy, comparable to the vetting question raised by malicious agent skills found in adjacent marketplaces?
• How would an agent, at runtime, detect that the description it is relying on to decide whether a tool call is safe has become inconsistent with the tool's actual current behavior, given that the inconsistency by definition is not visible in the description itself?
• Does the Direct-Reverse-Arbitration prompting method generalize to other agent-tool interface standards beyond MCP, or is the detection approach specific to this protocol's structure?

The governance artifact is retained. The governance function is not.