MCP Tool Metadata Injection

What Is MCP Tool Metadata Injection?

MCP tool metadata injection describes influence that reaches a model through descriptive material an MCP server supplies before any tool is called: tool names and titles, descriptions, input schemas and their field descriptions, annotations, server instructions and other server-provided text that a host chooses to expose to the model. That material can shape which tool the planner picks, how it reads a task and how it interprets a capability.

The name is a descriptive taxonomy term used on this site. The Model Context Protocol specification does not define a formal vulnerability category with this exact name. Research and community writing use overlapping terms such as tool description poisoning or tool registration poisoning; none of them is a single universally standardized label.

Why This Is a Separate Boundary

Most prompt-injection discussion concentrates on content that arrives during a task: user input, retrieved pages, tool results. Tool metadata arrives earlier and sits closer to the control plane. It describes what the agent can do, so the model tends to read it as orientation rather than as data under inspection. That position gives it leverage over selection and planning even when every later step is well controlled.

The separate boundary matters because its controls differ: registry integrity, catalogue review, change control and per-task tool exposure act before invocation, while result provenance and re-authorization act after it.

Tool Metadata Versus Tool Output

Tool output injection begins after a tool call and concerns what the call returns. This article concerns the description of a tool before anything is called. A single server can present both surfaces, and both need their own controls: tool metadata is not tool output.

Scope and Related Classes

Metadata can be adversarial without a compromise: an operator may write over-claiming descriptions, a benign server may be poorly worded, or two servers may overlap. Conversely, a compromised server can do far more than alter metadata. Keeping the classes apart keeps findings precise.

The MCP Surface Model

MCP connects AI applications to servers that expose tools, resources and prompts. The host is the AI application; it runs one or more clients, each connected to a server. The host decides what server-supplied material is shown to the model, in which form and alongside which application instructions.

The server is marked untrusted by default here because its natural-language content is not application authority, even when its identity is established. The 2026-07-28 revision changes transport and session aspects, for example a stateless core, an optional discovery call and cacheable list results. Exactly how a particular host assembles context remains implementation-specific and has to be checked per host and version.

Tool Definition Fields

Structural fields can be validated deterministically: types, required properties, allowed values. Natural-language fields cannot be validated for meaning in the same way. A schema describes valid argument structure; it does not grant permission to execute a call.

Server Instructions

Servers can supply instructions describing how their tools are best used. MCP maintainer guidance notes that hosts may inject these into the system prompt, but that the exact handling is up to the implementer and should be evaluated per client rather than assumed. The same guidance recommends that clients expose instructions to users and let them review, enable or disable them.

Tool Annotations Are Hints

Annotations such as readOnlyHint, destructiveHint, idempotentHint and openWorldHint are hints. The MCP maintainers' annotations article states that annotations are not guaranteed to describe tool behaviour faithfully and that clients must treat them as untrusted unless they come from a trusted server. An untrusted server can simply misstate them.

An annotation describes claimed behaviour. It is not proof of actual behaviour and it is not enforcement.

Discovery and Registration Versus Authorization

Discovery tells a client what a server offers. Registration or onboarding adds a server to what a host may use. Runtime authorization decides whether a specific principal may perform a specific operation on a specific resource now. These are three steps with different owners and evidence.

Three Separate Questions

Server authentication establishes server identity and transport trust, not semantic instruction authority. The 2026-07-28 revision hardens MCP authorization, for example with issuer validation and client metadata documents; that improves the first question and leaves the second and third unchanged.

Selection, Invocation and Result

Model output remains a proposal at every stage. A selection that looks odd is a signal; it is not in itself security impact.

Model-visible Representation

Only metadata actually placed in model context can directly influence the model. Hosts differ: some expose full descriptions of every connected tool, some filter or summarize, some load tool definitions on demand, some show server instructions and some do not. Findings from one host therefore do not transfer automatically to another.

Harmless Synthetic Examples

The examples use fictional servers and neutral wording. They contain no reusable descriptions or payloads.

Registry Integrity and Provenance

Provenance tells you where metadata came from. Known provenance is not instruction authority; it supports review and attribution. See Data Provenance.

Dynamic Catalogues and Change Control

Tool catalogues can change: servers add, remove or reword tools, and MCP supports notifying clients about list changes. The 2026-07-28 revision adds cache hints and deterministic ordering to list results so clients can cache catalogues. Caching is a performance feature; it does not decide whether a changed definition is acceptable.

1. 01
   Fingerprint

   Hash each tool definition and instruction set as rendered to the model.

2. 02
   Diff

   Compare against the last reviewed version on every refresh.

3. 03
   Hold

   Keep new or materially changed tools unavailable until review for protected workloads.

4. 04
   Record

   Log which catalogue version each run actually used.

Capability Minimization and Per-task Allowlists

The less a model sees, the less metadata can influence it. Expose only the tools a task profile needs, from servers approved for that profile. A tool that is not in the model-visible catalogue for a task cannot be selected for it through its own description.

Minimization also defines which capabilities should exist at all, a question covered by Least Privilege.

Deterministic Authorization of Each Call

Runtime and downstream authorization remain outside the model. Metadata can make a proposal more likely; it cannot make an unauthorized call permitted. See Agent Authorization.

Limiting Impact

None of these is a complete MCP solution. Each limits a different part of the consequence. See Network / Egress Restrictions, Sandboxing / Containment, Information Flow Control and Human-in-the-Loop.

Detection and Telemetry

Detectors can flag instruction-like wording in descriptions, as discussed in Prompt Injection Detection. Logs show correlation, not model causality: a changed description followed by a changed selection is evidence to investigate, not proof that one caused the other. Sequence analysis such as Tool-Chain Analysis helps when selection shifts across steps.

Incident Response Considerations

See Incident Response for the wider process.

Controlled Testing

Test with synthetic MCP servers and fictional tool definitions in an isolated environment, with no real third-party actions. Measure outcomes separately rather than as a single pass or fail.

See Adversarial Testing for authorization and scoping of test programmes.

Common Misconceptions

Standards and Sources

OWASP and NIST provide broader prompt-injection and agent context. They do not define this exact MCP-specific category. MCP-specific statements in this article rely on official MCP specification pages, maintainer articles and SDK documentation.

Key Takeaways

For the broader action path see AI Agent Prompt Injection and AI Agents and Tool Calling.

FAQ