What tool description injection is
In MCP deployments, servers advertise tools with names, schemas, and free-text descriptions. Clients typically surface that metadata to the model so the agent can decide when and how to call a tool. Tool description injection abuses that path: malicious or altered description text carries instructions the model will treat as part of its operating context.
The distinctive risk is trust placement. Prompt text from end users is often filtered, logged, or reviewed as untrusted input. Tool descriptions are frequently accepted as configuration. If those descriptions are attacker-controlled, the model may follow embedded directives that never appear in a user message and never pass through traditional request-validation layers.
How the injection surface forms during tool discovery
The exposure begins before a user asks a question. During discovery, the client retrieves tool metadata from connected MCP servers and builds the set of capabilities the model may use. That retrieval and assembly step is where untrusted description text can enter the session.
Where the risk lives across the connection lifecycle:
-
Discovery
Tool metadata is retrieved from MCP servers before any user prompt is processed.
-
Context injection
Description text enters the model’s context window as trusted instruction content.
-
Invocation
The model acts on embedded directives that a human reviewer never saw.
Because description text is natural language, it can encode behavioral rules, data-handling instructions, or exfiltration guidance in forms that look like ordinary documentation. If approval UIs truncate or summarize descriptions, humans may approve a tool while the model still receives the full, adversarially crafted text.
The failure mode is not only “bad content exists.” It is that the client promotes server-supplied prose into the same instruction channel the model uses for planning and tool selection.
Documented pattern: tool poisoning and rug-pull variants
Two closely related patterns appear in this attack surface.
Tool poisoning presents a description that looks legitimate for an expected capability while smuggling additional instructions. The tool may still perform a plausible primary action, which makes superficial review harder.
Rug-pull variants change metadata after initial approval. A tool may be reviewed and accepted with benign text, then later return altered name, description, or schema content on a subsequent connection. If the client does not compare current metadata to the previously approved version, the model can receive new instructions under an already-trusted tool identity.
In both cases, the attacker’s leverage comes from modifying what the model reads about the tool, not necessarily from breaking the transport or bypassing network controls.
Distinguishing tool description injection from related MCP risks
Tool description injection sits alongside other MCP concerns, but it is not the same as every tool-related failure.
- Description injection targets the natural-language metadata channel that shapes model reasoning before or during tool choice.
- Over-broad tool permissions expand what a tool can do at execution time, regardless of what the description claims.
- Untrusted third-party servers increase the chance that metadata itself is attacker-influenced, which raises description-injection risk but is a broader supply-chain issue.
Effective defense needs both layers: treat descriptions as untrusted content that can influence the model, and constrain what tools are allowed to execute even if the model is persuaded to call them.
Governance considerations beyond the runtime layer
Runtime checks are necessary because metadata can change between sessions and because models act on text humans may never fully inspect. Governance still has to define ownership and review expectations around third-party MCP servers, which teams may connect tools from external sources, and how description changes are treated after initial approval.
Consent and approval workflows should close the gap between human review and model input. Showing complete, untruncated description text at approval time reduces the chance that hidden instructions survive only in the model-facing payload. Isolating metadata from lower-trust external servers limits how far a single compromised description can contaminate higher-trust tool sets.
Auditability matters as well. When agent behavior changes after a reconnect or tool update, operators need records of the metadata the model actually received, not only the tool name that was invoked.