MCP tool descriptions are part of the attack surface
MCP tool descriptions help an agent decide which tool to call. That makes the description part of the model's input path. AgentTrust ID treats the description as metadata and checks the actual tool call against server-side identity, session scope, and action effect before the tool runs.
Recent MCP security research has focused on this exact boundary. Papers on implicit tool poisoning, multi-tool poisoning, and MCP security pitfalls describe ways a malicious or misleading tool description can steer a model toward the wrong behavior.
MCP tool descriptions
An MCP server publishes tools with names, descriptions, and input schemas. The model reads that information before it chooses a tool.
That text is useful. It tells the model that tickets.search searches support tickets, or that email.draft creates a draft message.
The same text can become a risk when the tool source is compromised, overly broad, or written to influence the model outside the user's task.
How tool poisoning happens
Tool poisoning happens when a tool's metadata changes the model's decision path.
A malicious tool can describe itself as safe while asking the model to call it with private data. A benign tool can carry a prompt-like description that says to prefer it over other tools. A second tool can influence how the model uses the first tool.
The model may follow the text because the description sits near the tool choice step. The authorization boundary belongs after that choice, at the point where the tool call is about to run.
Example
This example wraps an MCP tool call with an AgentTrust ID action check. The tool description can influence the requested tool name. The runtime check decides whether that call fits the session.
import json
from agenttrustid import AgentTrustClient
client = AgentTrustClient.from_env()
# Illustrative. In production the effect map comes from the
# server-side tool registry.
TOOL_EFFECTS = {
"tickets.search": "read",
"tickets.draft_reply": "mutating",
"tickets.delete": "destructive",
}
def call_mcp_tool(agent_id: str, session_id: str, tool_name: str, tool_input: dict):
effect = TOOL_EFFECTS.get(tool_name)
if effect is None:
raise PermissionError(f"unregistered tool: {tool_name}")
decision = client.actions.check(
agent_id=agent_id,
session_id=session_id,
tool_name=tool_name,
tool_input_summary=json.dumps(tool_input)[:200],
action_effect=effect,
)
if not decision.allowed:
raise PermissionError(decision.reason)
return run_upstream_mcp_tool(tool_name, tool_input)
The wrapper treats tool_name as the request. It reads authority from the registered agent, the active session, and the policy behind the action check.
A poisoned description can also steer the model toward a legitimate tool with attacker-chosen arguments. The input summary carries those arguments into the check and the action record, so the decision and the audit trail see the requested arguments along with the tool name.
Business impact
MCP makes tools easier to connect. That also makes tool inventory and tool review part of the security work.
A poisoned description can push an agent toward exfiltration, deletion, or the wrong system of record. The immediate blast radius depends on what the tool can reach and what the runtime allows.
Without action records, an operator may only see that a tool ran. With action records, the operator can see which agent asked, which session was active, which effect was checked, and why the decision was allowed or denied.
Prevention
Treat tool descriptions as model input. Review them like other prompt-adjacent text.
Register tools with explicit effects. Reads, writes, deletes, deploys, and admin actions need different paths.
Put the action check directly in front of the MCP call. A model-selected tool name becomes a request. The runtime check supplies the authority decision.
Solving this with AgentTrust ID
AgentTrust ID translates MCP tool calls into action checks with agent, org, session, tool name, source, and effect. The unified checker applies session scope, read-only mode, delegation ceilings, approval state, and Guardian routing.
The tool description can influence what the model asks for. The session record and policy decide what the tool wrapper runs.
To check MCP tool calls before execution, start with the SDK guide. To talk through MCP tool metadata risk, join the waitlist.
