Tool poisoning: when a seemingly trustworthy tool hides instructions

Introduction

The term tool poisoning describes a class of risk in which content associated with a tool, such as its description or its results, can lead the model to behave differently from what is expected. It does not mean that all MCP tools are poisoned or that the protocol forces that behavior.

Why the description matters

The model may receive details about a tool that are not shown to the user at the same level of detail. An ambiguous or misleading description, or one that includes instructions unrelated to the declared function, can influence tool selection and the data sent to it. An approval screen that shows only a short name may not make it possible to understand the requested operation.

Invariant Labs’ research from April 2025 popularized the term and presented experiments on malicious descriptions and later changes to tools. It is research evidence on risks and specific configurations, not a measure of prevalence across the ecosystem or a normative MCP requirement.

Review more than the name

Document each tool’s purpose, inputs, effects and the data it accesses. Check that the description matches the implementation and show the user the arguments and material effects before a sensitive action. Keep approval tied to a verifiable server identity and version, and review changes to schema or behavior.

Limit capabilities, separate reading from writing, validate inputs and apply authorization in the service that performs the operation. A seemingly benign description does not replace technical controls; a confirmation does not help either if it hides the important parameters.

Conclusion

Tool poisoning highlights a general point: tools and their results are part of the trust surface. Evaluate the content the model consumes together with the code, permissions and approval experience.