MCP tool poisoning and prompt injection

Tool poisoning hides instructions in the fields a model reads to choose a tool: the description, parameter names and schema text. A person approving the server usually sees a short summary, while the model sees all of it.

A variant changes the description after approval, so a tool that passed review later carries new text. The specification lets servers announce changes to the tool list, which gives clients a point at which to check again.

A support ticket, a customer name or a web page can all carry text addressed to the model, and a read-only tool will return it faithfully. Our post on read-only servers follows that path in detail.

This is the case API owners meet most often, because their own users control the content. The specification asks servers to sanitize tool outputs and asks clients to validate results before passing them to the model. No filter catches everything, so the controls below still matter.

A server cannot make a model immune, and it can decide what a successful injection is able to reach.

Clients carry the other half. The specification says they should show tool inputs before sending them, confirm sensitive operations and log tool usage, and must treat tool annotations as untrusted unless the server is trusted.

The combination to avoid is one agent holding private data, untrusted content and a way to send data out. Removing any one of the three, through separate servers or narrower tool lists, closes that path.

Octri does not claim to detect injected text in API responses, and no filter can promise that. The controls limit what injected text can make an agent do.

Tools come from your OpenAPI document and reach agents only when you publish, so a change to a description goes through your own review.

Writes default to asking first with the exact request on screen, and a tool you switch off is never listed.

Credentials echoed in API responses are removed before the agent sees them.

Tool groups give a job a shorter list, such as a read-only server for support. A group narrows what an agent sees, and an installation is what keeps a team on one group.

Each publish that changes the tools is a numbered release, and each agent is told what was added, renamed or removed since it last connected.