Give the model a menu, not a keyring

Connecting a tool server takes about a minute. It arrives with forty tools, they all show up in the model’s context, and the model picks whichever one it thinks fits. This is the part everybody enjoys, and it is why the integration got merged on a Tuesday without much discussion.

Here is what you also merged. A tool’s description is not documentation. It is text that goes into the model’s context and is read as instructions, from a server you do not control, updateable by its author at any time, invisible to the person using your product.

Researchers have a name for abusing this. A tool poisoning attack is one where “malicious instructions are embedded within MCP tool descriptions that are invisible to users but visible to AI models”, so they can “manipulate AI models into performing unauthorized actions without user awareness.” There is a nastier variant, tool shadowing, where a malicious server injects a description that changes how the agent behaves toward a different, trusted tool. In the published demonstration, the agent sends every email to the attacker even when the user explicitly names a different recipient, and the authors note the problem is not one product’s: it “can be replicated with any MCP client that does not properly validate or display tool descriptions.”

It works, and upgrading the model makes it worse

The largest measurement of this ran against 45 live, real-world MCP servers, published at AAAI in March 2026. Attack success reached 72.8%, with refusal rates under 3%.

The finding worth sitting with is the one about model quality. More capable models were more susceptible, because the attack rides on exactly the thing you pay extra for: careful, faithful instruction-following. A poisoned tool description is a well-written instruction. The better the model is at doing what it is told, the better this works.

So there is no upgrade path out of this. The registered tool list is the boundary, and no model release moves it.

OWASP agrees about where this sits. Excessive Agency moved from sixth on the 2025 list to third for 2026, one of the sharpest climbs on the list.

The move

Register only the tools this task needs, split by verb, and gate every irreversible one.

Vercel’s guidance states the first half about as concretely as it can be stated: “Register only the tools the task requires. A coding agent that edits a development branch runs with development-branch credentials, and a recommendation agent that reads product records gets read-only access to those records, with insert, update, delete, export, and send permissions left out of scope entirely.”

And the second half, which is the part most teams skip: “Read, write, delete, export, and send belong as distinct permissions instead of one bundled role.” One tool called manage_orders is a keyring. Five tools, of which this task gets two, is a menu.

THE KEYRING                        THE MENU

crm.manage_contacts                this task: "draft a reply to a support ticket"
  read   write   delete
  export send    merge             tickets.read           yes
                                   contacts.read          yes
one tool, six verbs,               drafts.write           yes
one description, always            ---------------------------------
registered, always in context      contacts.write         not registered
                                   contacts.export        not registered
                                   contacts.delete        not registered
                                   billing.*              not registered

                                   irreversible calls: approval gate,
                                   with the arguments shown to a human

The right-hand column is not a permissions system bolted on afterwards. It is a shorter list of tools registered for this task, which means the dangerous ones are not merely denied, they are absent from the context entirely. There is nothing for a poisoned description to talk the model into reaching for.

The stronger version, if you can afford it

An approval gate on irreversible actions is the practical answer, and you should have one. But there is a stricter architectural shape worth knowing, because it removes the need to be right about what counts as irreversible.

A 2025 paper on design patterns for securing agents states the principle plainly: “once an LLM agent has ingested untrusted input, it must be constrained so that it is impossible for that input to trigger any consequential actions.” Not unlikely. Impossible. In practice that means deciding which tools may be called before untrusted content enters the context, and refusing to expand that set afterwards.

What it costs

A shorter menu is a less capable agent, and sometimes it will be the wrong menu. You will scope a task to read-only and then discover the useful version needed one write. That is a real cost and the honest fix is a second, explicitly-scoped tool set, not widening the first one.

Approval gates get clicked through. A gate that fires forty times an hour trains people to approve without reading, which is worse than no gate because it manufactures a record of consent. Gate the irreversible and the expensive, and let the rest run.

And the counter-argument deserves airing. Anthropic reports that giving models a way to search a large tool library improved selection accuracy substantially in their internal testing, from 49% to 74% for one model and 79.5% to 88.1% for another. That is a vendor measuring its own feature, so treat it as reported rather than settled, but it points at something true: the answer to too many tools is not always fewer tools, it is sometimes better retrieval over them. Note what it does not change. Retrieval improves which tool gets picked. It does not stop a poisoned description being read.

Try this week

Print the tool list your agent actually receives. Not the ones you meant to give it, the ones in the context: name, description, full schema.

Two questions. How many of those tools could do something you could not undo? And how many of those descriptions were written by someone outside your company?

Then take your most common task and register the smallest set of tools that completes it. Just that one task, as an experiment, and run your evals against it. Most teams find the number is three or four out of forty, and that the other thirty-six were there because they arrived in a bundle.