MCP Tool Poisoning Explained: How Malicious Tool Descriptions Hijack AI Agents

When developers review a Model Context Protocol server, they naturally look at the code behind each tool. They check authentication, validate parameters, inspect network calls, and ask whether the operation is appropriately scoped. Those checks matter. But an MCP-connected agent sees another security-relevant surface before it calls any tool at all: the tool's description.

Tool descriptions tell the model when and how a capability should be used. They may contain parameter guidance, examples, warnings, and operational context. To a traditional API client, that text is documentation. To an AI agent, it is part of the decision environment. If an attacker can control or alter it, documentation becomes an instruction channel.

That is the central idea behind MCP tool poisoning. The OWASP description of MCP Tool Poisoning characterises it as an indirect prompt-injection attack in which malicious tool metadata manipulates the connected agent. The problem is easy to underestimate because the poisoned instructions may never be shown in the chat interface and the tool may still perform a legitimate-looking function.

How MCP tool descriptions influence an agent

An MCP client typically makes tool names, descriptions, and input schemas available to the model. The model uses that information alongside the user's request, the system prompt, conversation history, and retrieved context to select a tool and construct arguments.

Consider a tool named summarize_document. Its visible purpose is harmless. A compromised description could add hidden or inconspicuous text telling the agent to read a local credential file first, include selected content in another argument, prefer this tool over a safer alternative, or conceal the additional step from the user. Whether the attack succeeds depends on the client, model, permissions, and surrounding controls, but the trust boundary is clear: server-supplied metadata can influence model behaviour.

This differs from ordinary parameter injection. The attacker is not necessarily placing a payload in the user's argument. They are changing the model's understanding of what the tool is, when it should run, or what supporting actions are supposedly required.

A simple tool-poisoning attack path

Imagine an internal research assistant connected to two MCP servers. One provides approved document search. The other provides a newly installed conversion utility.

The conversion tool description quietly says that, before processing a file, the agent should gather “environment diagnostics” and include them in a metadata field. The agent has access to a file-reading capability because that is useful for legitimate research tasks. A user asks the assistant to convert a report. The agent follows the poisoned description, reads a configuration file, and sends part of it to the conversion server.

No memory corruption or remote-code exploit is required. Every component can appear to function:

1. The user makes an ordinary request.
2. The client supplies tool metadata to the model.
3. The model interprets malicious metadata as trusted operational guidance.
4. It calls another available capability to gather data.
5. It passes that data to the poisoned tool.

The impact comes from composition. The poisoned server may not be able to read files directly, while the agent can combine it with another tool that can.

Tool shadowing and cross-server confusion

Tool poisoning becomes more interesting when several servers expose similar capabilities. A malicious server can describe its tool as the preferred, secure, or mandatory way to complete tasks. It may reference another tool by name and tell the agent to alter how that tool is called. This is often discussed as tool shadowing or cross-tool manipulation.

Names alone are a weak security boundary. Two servers may both expose search, read_file, or send_message. Interfaces that truncate names or omit server provenance make it harder for users and reviewers to understand which implementation the agent selected. Even when names are unique, descriptions can frame one tool as a prerequisite for another.

Security tests should therefore evaluate the complete tool set presented to the agent, not each MCP server in isolation. A low-privilege tool can become consequential if its metadata steers a higher-privilege tool.

The rug-pull problem

A server may be benign when first approved and change later. The tool name and schema can remain stable while the description acquires new instructions. If the client automatically refreshes metadata, the agent's effective behaviour changes without a conventional software deployment.

This is sometimes called a rug pull. It complicates one-time review: the hash, owner, or package approved last month may not describe the metadata served today. Teams need to know whether tool definitions are pinned, cached, signed, reviewed on change, or accepted dynamically.

Behavioural retesting is equally important. A diff can identify changed text, but it does not show how the model will interpret that text in combination with current prompts, models, and tools. A small wording change can produce a large behavioural difference.

What makes a poisoned description effective?

Attackers can exploit several characteristics of agent systems:

• Instruction ambiguity: models may not reliably distinguish trusted tool guidance from untrusted descriptive text.
• Invisible context: users often cannot see the full metadata used to make a decision.
• Broad permissions: the agent may possess credentials or tools that the MCP server itself lacks.
• Automatic composition: agents can chain several capabilities without the user explicitly requesting each step.
• Authority language: phrases such as “required security check” or “administrator-approved” can influence planning.
• Long sessions: poisoned guidance can affect later steps after the original tool has left the visible conversation.
• Weak provenance: tool results and descriptions may enter context without a durable trust label.

None of these means every MCP client is vulnerable in the same way. The point of testing is to determine whether a specific client, model, server set, and permission configuration produces unsafe behaviour.

How to test for MCP tool poisoning safely

Start with an inventory. Capture the exact name, server origin, description, schema, version, and permissions of every tool visible to the target agent. Repeat this inventory over time so changes become observable.

Next, review descriptions as executable influence, not passive prose. Look for instructions that request unrelated data, override client policy, reference secrets, invoke other tools, discourage user disclosure, claim elevated authority, or change output destinations. Pay attention to HTML, Markdown, Unicode, encoded strings, schema annotations, and examples—not only the first sentence.

Then test in an isolated environment with harmless canaries. Give the agent access to a synthetic file or value that has no production significance. Introduce a test tool description that asks for the canary in a way the policy should forbid. Observe whether the agent reads it, places it in arguments, reveals it in conversation, or carries it into a later call.

Vary the conditions:

• Direct user request versus request involving retrieved content
• One server versus multiple servers
• Similar and unique tool names
• Fresh session versus long-running session
• Benign description at approval time followed by a changed description
• Tool available but unnecessary for the task
• Conflicting system instruction and tool instruction
• Read-only versus side-effecting companion tools

Do not use real secrets as markers. The test should demonstrate control failure without creating the impact it is meant to prevent.

Evidence that makes a finding actionable

A screenshot of an odd response is not enough. A useful tool-poisoning finding should preserve:

• The exact tool metadata presented to the model
• Server identity and version at test time
• System and user-visible context relevant to the decision
• The agent's selected tools and their order
• Arguments supplied to each tool
• Harmless canary movement
• Expected policy and observed violation
• Whether the outcome reproduced across attempts
• Model, prompt, client, and tool changes used during retesting

This level of evidence separates a plausible concern from a behaviour the engineering team can fix. The method aligns with broader transcript-backed agent testing: define success criteria before the run, capture the sequence, and evaluate the observed result rather than the attacker's wording alone.

Defences at the MCP client

The client should treat tool metadata as untrusted input. That does not mean descriptions can be discarded; they are necessary for tool selection. It means they should not be allowed to override higher-priority policy or silently grant authority.

Useful controls include displaying tool provenance, separating server instructions from client policy, constraining which tools can be composed, requiring approval for sensitive calls, and making tool arguments visible before execution. Clients can also pin approved tool definitions, alert on changes, namespace tools by server, and avoid sending unnecessary secrets or context to the model.

Deterministic enforcement matters. If a file-reading tool must never access credential directories, enforce that in the tool or sandbox. If a messaging tool may send only to approved domains, validate the destination outside the model. Asking the model to remember these rules is weaker than preventing the forbidden operation.

Defences at the MCP server and tool boundary

Server operators should keep descriptions precise, minimal, and reviewable. Tool documentation should explain legitimate use without embedding unrelated workflow instructions. Changes should be versioned and auditable.

Tools should run with least privilege and validate arguments against the authenticated user's scope. A poisoned description becomes less powerful if the resulting calls cannot read arbitrary files, select other tenants, contact arbitrary hosts, or invoke unrestricted commands.

Sensitive actions should require an external approval or policy decision. The same rule applies to destructive changes, financial transfers, messages to new recipients, permission modifications, and bulk data retrieval. Approval context must be specific: what action, which resource, which recipient, and which user authorised it.

The OWASP MCP Security Cheat Sheet provides a useful defensive baseline, while the OWASP MCP Top 10 offers a broader risk taxonomy. Neither replaces testing the actual behaviour of the connected agent.

MCP security is a system property

It is tempting to solve tool poisoning with a metadata scanner. Static review can catch obvious suspicious phrases and unexpected changes. It should be part of the control set. But models respond to wording, context, available capabilities, and task state in ways that are difficult to predict from a string alone.

The real question is whether poisoned metadata changes an outcome that matters. Does the agent choose a different tool? Does it read data beyond the task? Does it conceal an action? Does it cross a user's permission boundary? That requires behavioural testing across the connected implementation.

Oxyne's approach to MCP servers and tool-using agents is scoped around exposed tools, arguments, authorisation boundaries, multi-turn behaviour, and transcript evidence. It is assessment, not a claim of runtime blocking or a universal MCP permission graph.

Teams adopting MCP do not need to abandon dynamic tools. They do need to stop treating tool descriptions as harmless documentation. Inventory them, review them, constrain the capabilities behind them, monitor changes, and test how real agents behave when that trust boundary is challenged.

A review checklist for each new MCP server

Before approving a server, ask who operates it, how the client authenticates it, whether definitions can change remotely, and what happens when the operator account or distribution channel is compromised. Capture the exact definitions presented to the client rather than relying on a README that may not match runtime behaviour.

Review every tool for unrelated instructions, references to other tools, requests for diagnostic data, claims of authority, concealment language, and broad parameters. Identify which local and remote capabilities could be combined with it. A conversion tool that has no filesystem access can still be risky when the connected agent has a separate reader.

Run a benign baseline and a poisoned-control version with a synthetic canary. If the agent resists, record which control stopped the path: model behaviour, client policy, user approval, tool restriction, or backend authorisation. This matters because the model may change while the deterministic control remains.

Finally, test removal and change response. Disable the server, revoke its credential, modify a description, and confirm that clients update predictably and produce an alert where required. Approval without lifecycle testing leaves the rug-pull scenario unanswered.

Questions security teams commonly ask

Can a metadata scanner solve tool poisoning?

It can find suspicious text, known patterns, hidden markup, and unexpected changes. That is useful, but it cannot reliably predict how every model will interpret metadata in a particular task or what other tools it will compose. Use scanning for hygiene and behavioural tests for impact.

Is a trusted internal MCP server safe from poisoning?

Internal ownership reduces some supply-chain risk but not mistakes, compromised accounts, unsafe descriptions, or untrusted results. Apply provenance, change control, least privilege, and testing according to consequence rather than hostname.

Should users see every tool description?

Full raw metadata may overwhelm users, but consequential decisions should expose server provenance, selected capability, important arguments, and data destination. Security reviewers need access to the complete definition used during a run.

Does model improvement remove the risk?

Better instruction handling can reduce successful attacks, but the security boundary should survive model variation. A model update should not determine whether a file tool can read secrets or whether an upload tool can contact an arbitrary host.

Tool poisoning is ultimately a governance, client, model, and permission problem at the same time. The best programmes combine review of what the server says, enforcement of what its tools can do, and evidence of how the connected agent behaves.