MCP Descriptor

What MCP Descriptors Do

An MCP descriptor is the control plane for agent tool access: it tells an AI agent what services exist, where they live, and how to call them. That makes it more than metadata, because it shapes the agent’s effective action surface.

In practice, the descriptor is the bridge between intent and execution. A clean descriptor helps an agent discover the right tool for the job, while a weak or manipulated one can make the same agent reach the wrong endpoint, select the wrong tool, or inherit unsafe defaults.

Because descriptors sit at the boundary between planning and execution, they are part of the trust fabric around agentic systems. For a broader view of how agent tooling, authorization, and misuse interact, see OWASP Agentic Applications Top 10 and OWASP Agentic AI Top 10.

How MCP Descriptors Influence Tool Selection

The descriptor is not the tool itself. It is the instruction set that helps the agent interpret available capabilities, endpoints, schemas, and sometimes trust expectations. In effect, it determines what the agent believes is callable and how it should construct the call.

That means the descriptor can shape behaviour before any network request is made. If a descriptor presents a dangerous tool as normal, or hides important restrictions, the agent may confidently choose an action that the operator never intended.

This is why descriptor accuracy matters in the same way API contract accuracy matters. The agent is only as safe as the information it uses to select tools, and the descriptor is often the first object that encodes that information.

For the protocol-level authorisation model behind this pattern, the Model Context Protocol authorization specification is the clearest reference point.

Compromise, Poisoning, and Misrouting

A compromised or poisoned descriptor can redirect an agent toward unsafe tool calls without breaking the underlying credentials. That is the key danger: the authentication may still be valid, but the target and context of the action have been altered.

Attackers or upstream supply-chain issues can abuse that gap by changing service endpoints, swapping tool metadata, or injecting a misleading capability description. The result is often not immediate credential theft, but silent command redirection and unsafe automation.

This failure mode is especially serious when the descriptor is trusted by an orchestrating agent across multiple tool calls. A single poisoned configuration object can create repeated misuse, because the agent continues to follow the malformed trust signal.

Security teams should treat descriptor integrity as part of the attack surface, not as a harmless configuration detail.

Operational Boundaries and Trust Assumptions

MCP descriptors work best when the agent’s discovery layer is tightly separated from the execution layer. If those two concerns are blurred, a descriptor can become a hidden policy decision point, with too much power to define where the agent may go next.

The most important trust question is whether the descriptor merely advertises tools or also influences authorisation, routing, or implicit trust. When it does more than advertise, it becomes a security-sensitive object and should be governed accordingly.

That is why descriptor handling should be reviewed alongside agent permissions, tool registration, and any gateway or broker that rewrites calls. The safer the boundary, the less likely a poisoned descriptor is to turn into unsafe execution.

For practical hardening guidance around this boundary, MCP Security Guide is the most direct companion reference, and the agentic AI applications guide helps frame the broader operating model.

Risk and Threat Considerations

MCP descriptors create a concentrated trust dependency, because a small configuration object can shape a large amount of downstream agent behaviour. If that object is altered, the agent may keep operating normally while actually being steered into unsafe tools, wrong services, or attacker-controlled endpoints.

Failure mechanism: Descriptor tampering, spoofing, or poisoning changes discovery or routing data, so the agent selects an unsafe tool path even though the original credential material remains valid.

Impact: The likely outcomes are tool misuse, privilege abuse, data exposure, or repeated unsafe actions across multiple calls, especially where the agent reuses the same descriptor trust signal.

Practitioner Guidance

Why practitioners should care: Treat the descriptor as security-relevant configuration, not just integration metadata. Its integrity affects what the agent can reach, how it interprets tool availability, and whether the execution path still matches operator intent.

Common misunderstanding: Valid authentication does not guarantee safe behaviour if the descriptor that guides tool selection has been altered. The agent can be “correctly signed in” and still be pointed at the wrong capability.

Practitioner takeaway: If an MCP-based agent behaves unexpectedly, inspect the descriptor and its update path as carefully as you would inspect credentials or policy.

Related resources from NHI Mgmt Group

• What is the Model Context Protocol (MCP) and why does it matter for security?
• What is MCP Step-Up Authorisation and how does it implement least privilege for agents?
• What are MCP Authorisation Extensions and why do they matter for enterprise governance?
• What are MCP Authorization Extensions and how do they help organizations?