A tool description is model input; it does not itself grant file-access or transmission authority.
The Model Context Protocol (MCP) defines an interface for tool names, descriptions, and input schemas. Tool poisoning places unintended instructions in such text supplied to a model.
This post uses the official MCP specification for interface facts and InjecAgent for evidence about attacks through external tool responses. InjecAgent does not benchmark attacks against MCP metadata.
Tool definitions and execution authority
Under the MCP 2025-06-18 tool specification, clients obtain definitions through tools/list and invoke tools through tools/call. The host application's configuration determines which definitions reach the model and which calls execute.
A request written in a description is not user authorization. For example, "send another file before checking the connection" does not derive file-transmission authority from permission to check connectivity.
| Input | Purpose | Separate check |
|---|---|---|
| Tool name and description | Explain capabilities and guide selection | Origin and change history |
| Input schema | Validate argument structure | Caller authority over the resource |
| Tool response | Return task results | Content origin and authority for subsequent actions |
A schema-valid call can still be unauthorized. Valid JSON and a permitted action are different conditions.
Research evidence about external inputs
InjecAgent, published in Findings of ACL 2024, evaluates indirect prompt injection through tool responses. It provides evidence that attacker-controlled responses can influence agent behavior.
Descriptions and execution results occupy different input locations. Its attack success rates therefore cannot be presented as MCP description-poisoning rates. A particular client's risk requires testing its actual exposed definitions and permissions.
flowchart LR
S[MCP server] --> D[Tool definitions]
D --> H[Host exposure policy]
H --> M[Model call proposal]
M --> A[Server and client validation]
A --> T[Tool execution]
T --> R[Result validation]
R --> MThis diagram illustrates interfaces and validation locations. It does not reproduce the effectiveness of a particular defense product.
Specification requirements and application policy
The specification requires servers to validate inputs, control access, limit invocation rates, and sanitize outputs. It recommends client confirmation for sensitive operations, argument visibility, and result validation. Requirements and recommendations should remain distinct.
| Control | Location | Remaining limitation |
|---|---|---|
| Argument validation | Server | Valid arguments can still come from an unauthorized requester |
| Resource authorization | Server and execution environment | Excessive service credentials expand access |
| Sensitive-action confirmation | Client | Users must understand the target and content |
| Definition-change review | Host operating policy | Static review cannot classify every natural-language attack |
| Result validation | Client | Semantic and contextual attacks can be missed |
Definition-change review is an operational proposal in this post. A host can compare approved and current definitions, then reassess changes affecting authority. Using a particular scanner does not establish safety.
Boundaries to test
Test reading a tool definition separately from reading its result. Check whether either route actually executes unauthorized file access or transmission.
1. Fix the authenticated user and tool resource permissions.
2. Change only a tool description or a tool response in each case.
3. Record proposed calls separately from actual execution.
4. Check rejection of unauthorized operations at the execution boundary.
5. Measure legitimate task success and additional confirmation cost.This procedure proposes evaluation for a specific service. Model refusal alone does not establish that server authorization works.
Summary
MCP definitions and responses are model inputs whose origin and authority require separate handling. InjecAgent supports the risk from external tool responses but supplies no MCP description-attack success rate. Apply the specification's validation requirements and enforce service-specific resource permissions separately. Test definition, execution, and result paths individually to establish the actual protection scope.