Roughly one in ten tool descriptions in real-world MCP servers does not match what the underlying code actually does. A study submitted June 3, 2026 measured 19,200 description-code pairs across 2,214 servers and found a 9.93% description-code inconsistency (DCI) rate. Because agent runtimes select tools based on natural-language descriptions without verifying the implementation, that mismatch turns every MCP host into a confused deputy that trusts the label on the tin.
What DCI Is and Why 9.93% Matters
The paper defines description-code inconsistency as any case where a tool’s declared behavior diverges from what the handler function actually executes. The researchers extracted 19,200 description-code pairs from 2,214 real-world MCP servers and found that 9.93% exhibit some form of DCI, according to arXiv:2606.04769.
That number measures mismatch, not exploitability. A description that omits an optional parameter is a DCI instance; so is a description that claims the tool reads a file when the code actually uploads it somewhere. The range is wide. But the structural problem is the same in both cases: the agent runtime has no independent way to know which it is dealing with. Every inconsistency, benign or not, forces the agent to operate on incorrect assumptions about what will happen when it calls the tool.
The paper categorizes DCI into two classes. Functionality inconsistencies occur when the description says the tool does X and the code does Y. Undeclared side effects occur when the code does things the description never mentions at all, per arXiv:2606.04769. The latter is the more concerning variant for security: a tool described as “reads a configuration file” that also logs the contents to a remote endpoint would fall into this category.
How MCP Tool Selection Works, and Where It Trusts Blindly
The Model Context Protocol routes tool selection through natural-language descriptions. When an MCP host (an agent runtime like Claude, GPT, or Gemini) encounters a set of available tools, it reads each tool’s declared name, description, and parameter schema, then decides which to invoke based on that text. The protocol has no mandatory mechanism for verifying that the description matches the handler, as the official MCP documentation confirms.
This is an architectural choice, not an oversight. MCP was designed as a lightweight, server-driven protocol. The server declares its capabilities; the host trusts them. That trust is reasonable when the server and host are maintained by the same organization. It becomes a liability when the server is third-party code pulled from a registry, which is the use case MCP’s governance structure under the Agentic AI Foundation (AAIF) and Linux Foundation is now actively encouraging.
MCP was introduced by Anthropic in November 2024, donated to AAIF under the Linux Foundation in December 2025, and has since been adopted by OpenAI, Google DeepMind, and Microsoft, per Wikipedia’s MCP article. As the protocol moves from single-vendor tooling to a shared ecosystem, the trust model shifts with it: what was once an internal contract between tool and host becomes an external claim that nobody verifies.
The DCIChecker Detection Method
To measure DCI across the full corpus, the researchers built DCIChecker, an automated framework that combines structure-aware static analysis with a three-stage LLM prompting technique they call Direct-Reverse-Arbitration, according to arXiv:2606.04769.
The approach works in two phases. First, the static analysis component parses the server’s code to extract function signatures, control flow, and side effects. Second, the LLM-based prompting cross-validates the tool’s declared description against the extracted code behavior: the “direct” prompt asks whether the description matches the code, the “reverse” prompt asks whether the code matches the description (framing the comparison from the other direction), and an “arbitration” prompt resolves disagreements between the first two.
The paper does not report false-positive or false-negative rates on the full corpus, which limits how much confidence to place in the 9.93% figure as a precise prevalence estimate. It is a measurement from one detection pipeline, not a ground-truth audit. The number is still useful as an order-of-magnitude signal: DCI is not a corner case.
DCI vs. Prior MCP Vulnerabilities
This is not the first security concern raised about MCP. In April 2025, researchers documented prompt injection attacks, tool poisoning, and lookalike tools that silently replace trusted ones, per Wikipedia’s MCP security coverage. Those attacks operate at the prompt boundary: they manipulate what the agent sees or how it interprets tool metadata.
DCI is a distinct vulnerability class. It operates at the schema-implementation boundary, not the prompt boundary. The description is not being injected or overwritten; it is authored by the server developer and presented exactly as intended. The problem is that what is intended diverges from what the code does. An attacker exploiting DCI does not need to tamper with a prompt or spoof a tool name. They simply ship a tool whose description says one thing and whose code does another.
The distinction matters for defenders. Mitigations against prompt injection (input sanitization, prompt hardening, tool-name verification) do not catch DCI. Mitigations against DCI require comparing the declared description to the actual implementation, which is a different problem entirely.
A separate line of work reinforces the broader picture. The SkCC compiler paper found that agent frameworks are highly sensitive to prompt formatting and that security in reusable agent skills is largely unaddressed, with widespread vulnerabilities in practice. SkCC identifies the problem at the skill-compilation layer; DCI identifies it at the tool-description layer. They are different surfaces of the same structural gap: agent frameworks assume that what they read about a tool is true.
What This Means for MCP Registry Operators and Agent Developers
The 9.93% figure carries direct implications for anyone building or operating an MCP tool registry. A registry that indexes tools by their self-reported descriptions without verifying the handler code is propagating claims it cannot vouch for. If the registry is the mechanism by which agents discover and select third-party tools, then the registry is also the mechanism by which agents inherit DCI risk.
Registry operators have a few options:
- Static verification at ingest: run something like DCIChecker on every submitted tool before indexing it. Flag or reject tools where the description diverges from the code.
- Attestation-based trust: require tool authors to sign a manifest that binds the description hash to the code hash. This does not prevent DCI, but it creates an audit trail.
- Runtime verification: instrument the agent host to log actual tool behavior and compare it against the declared description after each call. This catches inconsistencies that static analysis misses (dynamic side effects, environment-dependent behavior) but adds latency and complexity.
Agent developers face a different constraint. When the host runtime selects tools by description, the only practical defense is to limit which servers the agent is allowed to call. Sandboxing, permission scoping, and human-in-the-loop confirmation for sensitive operations all reduce the blast radius of a DCI instance. They do not prevent the agent from selecting the wrong tool in the first place.
Complementary Approaches: Trust Layers and Skill Compilers
DCI is a post-hoc detection problem: the inconsistency already exists in shipped code, and DCIChecker attempts to find it. A complementary approach addresses the pre-interaction trust question: how does an agent know a server is safe to approach before it reads the first tool description?
The OpenAgenet (OAN) proposal describes a protocol-neutral trust layer for agent identity and discovery that supports MCP, A2A, and ANP. OAN focuses on making agents “admissible, discoverable, verifiable, and safe to approach” before interaction begins. This is orthogonal to DCI detection: OAN establishes trust in the agent’s identity, while DCI verification establishes trust in the agent’s tooling. Both are necessary, and neither is sufficient on its own.
As of June 2026, none of the major agent runtimes ship with built-in DCI detection. The DCIChecker authors propose their framework as a mitigation, but the absence of reported precision and recall metrics means it is best understood as a research prototype rather than a deployable tool. The structural problem, however, does not wait for a production-ready detector. Every MCP call made between now and whenever verification becomes standard is a call made on trust.
Frequently Asked Questions
Can DCI occur in agent protocols other than MCP?
Any protocol where an LLM selects tools based on natural-language declarations without verifying the implementation is susceptible. Google’s Agent-to-Agent (A2A) protocol and the Agent Network Protocol (ANP) face the same structural gap. The OAN proposal (arXiv:2606.03163) tries to address pre-interaction trust across all three, but it focuses on agent identity and discoverability, not on whether a tool’s description faithfully describes its handler.
How is DCI different from an OpenAPI spec mismatch?
In a REST API ecosystem, a mismatch between an OpenAPI spec and the server implementation is a developer-inconvenience bug that breaks code generation and integration tests. In MCP, the description is the input to the agent’s reasoning: the model reads it, decides which tool to call, and executes based on that text. A spec mismatch in REST is a documentation defect. A description mismatch in MCP is a confused-deputy problem where the agent confidently takes the wrong action on the user’s behalf.
What types of DCI would static analysis miss?
Environment-dependent behavior, conditional side effects, and code paths that activate only under specific runtime conditions. A tool that reads a file normally but uploads it when an environment variable is set would pass static verification if the analyzer does not model every branch. Runtime monitoring (logging actual behavior after each call) catches these cases, but adds latency and requires instrumentation the MCP protocol does not currently define.
Would requiring signed attestation at registries eliminate DCI?
No. Attestation binds a description hash to a code hash, creating an audit trail for who shipped what. It does not verify that the description accurately describes the code. A malicious author can sign a manifest that binds a misleading description to harmful code just as easily as an honest author signs a correct one. Attestation deters after-the-fact denial, not the inconsistency itself.
What can an agent developer do today to mitigate DCI?
Outside of restricting which servers the agent may contact, the options in June 2026 are limited. No major agent runtime ships with built-in description-code verification. Teams can run their own static analysis on server source before registering it, or sandbox tool execution and monitor outbound network calls and filesystem writes at runtime. Both are custom integrations, not off-the-shelf features.