Why do MCP tool descriptions create supply chain risk for agentic systems?

Why MCP Tool Descriptions Become Supply Chain Risk

MCP tool descriptions matter because they are not just documentation. In an agentic system, the description can shape what the model believes a tool does, when to use it, and what side effects are acceptable. If that text is poisoned, a malicious or compromised upstream server can influence downstream behaviour without changing the client code. That turns a seemingly low-risk metadata field into a trust boundary that can steer execution.

The supply chain aspect comes from dependency and approval. Teams often review the MCP server once, then assume the tool schema and descriptions remain stable. If a server can update its descriptions after onboarding, the client may be trusting a moving target. That creates a governance gap similar to accepting unsigned package updates: the source looked safe at approval time, but later content can change the security meaning of the integration.

For agentic systems, this is not a theoretical concern. Description text can act like indirect instructions, especially when the agent uses it to select tools, route tasks, or infer constraints. In practice, many teams discover the problem only after an agent has already treated a trusted description as operational guidance.

How the Risk Materialises in Practice

The core mechanism is prompt injection through trusted metadata. An MCP server may expose a tool whose description says it is for “retrieving customer records” but also includes hidden or misleading instructions that bias the model toward disclosure, unsafe escalation, or exfiltration. Because the description sits inside the tool-discovery path, the agent may treat it as part of the system’s legitimate capability set rather than as untrusted input.

The problem gets worse when organisations separate approval from runtime verification. A tool may be approved during a security review, but the server can later alter its schema, natural-language descriptions, or examples. If the client does not pin the version, hash, or policy state, it has no reliable way to detect that the trust assumptions have shifted. This is why MCP governance should be treated like software supply chain control, not only as a runtime authorization problem.

Practitioners should think about three layers of control:

• Discovery controls, so untrusted descriptions cannot silently shape tool selection.
• Change controls, so schema and description drift is detected after onboarding.
• Execution controls, so the agent cannot convert a misleading description into high-impact actions without a separate policy check.

This is closely related to broader agentic guidance on prompt-injection-resistant design, and the OWASP Agentic AI Top 10 captures why instruction contamination must be treated as a primary architectural risk. For governance context, the NIST AI Risk Management Framework is useful because it emphasises mapping, measuring, and managing AI-related risk across the lifecycle, not only at deployment. These controls tend to break down when tool registries are dynamic, descriptions are generated upstream, and approval is treated as a one-time event.

Where the Edge Cases and Trade-offs Show Up

Tighter description governance often slows iteration, because teams want the freedom to add tools, refine descriptions, and improve agent usefulness quickly. That trade-off is real: reducing ambiguity can also reduce flexibility. The practical question is not whether descriptions should be rich, but whether they are allowed to carry operational authority without independent validation.

Some environments can tolerate descriptive text as a convenience layer when the tool itself is low impact and the agent cannot cause material harm. Current guidance suggests the risk threshold changes sharply when the tool can read sensitive data, trigger external actions, or chain into other systems. In those cases, the description is part of the attack surface and should be treated as mutable supply chain input.

Teams should also be careful with “trusted internal” assumptions. Internal does not mean safe if the server is shared, delegated, or updated by another team with different security standards. The same issue appears when vendors, plugins, or orchestrators generate descriptions automatically and no one owns the review process. The hardest failures are usually not obvious compromise events, but quiet trust expansion over time.

Practitioner Guidance

What to prioritise: Treat the tool registry as governed content, not just integration metadata. If a description can influence tool choice or action selection, give it the same review discipline as any other security-relevant dependency.

Decision rule: If the MCP server can change descriptions or schemas after approval, require version pinning, change detection, and re-approval before the agent can use the tool in production.

What to verify: Confirm that tool descriptions are not the only safeguard preventing unsafe execution. There should be an independent policy layer that checks intent, scope, and impact before sensitive actions occur.

What practitioners underestimate: A “helpful” natural-language description can become a covert control channel when the model is optimizing for task completion. The safe design goal is not perfect text hygiene, but bounded authority with visible drift.

Practitioner takeaway: If the agent can act on it, the description is part of the security perimeter, and perimeter assumptions must be revalidated whenever the upstream server changes.

Related resources from NHI Mgmt Group

• Why do MCP integrations increase supply chain risk for AI systems?
• Why do AI gateways and agentic systems create new operational risk when they handle customer requests and tool execution?
• Why do unclaimed package names create a supply chain risk for developer environments and build systems?
• Why do vague or overlapping MCP tool descriptions create operational risk in multi-server environments?