Tool Descriptor

The metadata an MCP server provides to describe a tool — its name, description, parameter schema, and usage notes — that an AI agent reads when deciding which tool to call.

A Tool Descriptor is the metadata that an MCP server exposes to describe each tool it offers. It typically includes the tool's name, a free-form natural-language description, a parameter schema (often JSON Schema), and any usage notes. The AI agent reads tool descriptors during planning to decide which tool best matches the current task and how to format the call.

Tool descriptors look mundane — they are the equivalent of API documentation. In the MCP threat model, they are anything but. A descriptor's free-form description field is read directly into the LLM's context window during tool selection. Whatever instructions are written there carry roughly the same authority as the system prompt itself, because the LLM has no built-in mechanism to distinguish between developer-authored input and server-supplied metadata.

Why Descriptors Are an Attack Surface

Three properties make tool descriptors a uniquely valuable target for attackers:

First, they flow into the trust-bearing context. Once a descriptor enters the LLM's working context, instructions inside it can influence every subsequent reasoning step. There is no delimiter that marks "this came from a third party I don't control."

Second, they are not user-visible by default. Most MCP clients show tool names in their UI but not full descriptions. A user who installs an MCP server rarely reviews each descriptor end to end. Even careful users may scan a description on first install but not recheck it after updates.

Third, they are mutable from the server side. A server can change its descriptor between sessions, including under attacker control if the server has been compromised. A descriptor that was benign at install time can become weaponised the next time the agent reads it.

The combination produces tool poisoning attacks: adversarial instructions hidden in the descriptor that hijack agent behaviour. CVE-2025-54136 (the "MCPoison" exploit against Cursor IDE) is the canonical example — attackers controlling an MCP server wrote unsanitised directives into the descriptors that Cursor processed.

Defending Tool Descriptors

Hosts and integrators should treat descriptor strings as untrusted inputs. Sanitisation in front of the LLM context — stripping known prompt injection patterns, enforcing length limits, quarantining suspicious tokens — is a low-cost first layer. More fundamentally, the agent's planning step should receive a structurally validated subset of descriptor data (e.g., parameter schemas) rather than the raw natural-language description, so the descriptor's prose can no longer carry instructions.

Logging the full descriptor at the moment it enters the context, and diffing against the previous run, is one of the few mechanical signals that catches descriptor mutation post-install. For the broader pattern of MCP-specific supply-chain attacks, see the MCP Breach Index 2025–2026.

Need expert guidance on Tool Descriptor?

Our team at Zealynx has deep expertise in blockchain security and DeFi protocols. Whether you need an audit or consultation, we're here to help.

Get a Quote

oog
zealynx

Smart Contract Security Digest

Monthly exploit breakdowns, audit checklists, and DeFi security research — straight to your inbox

© 2026 Zealynx