Scan the tool description, I said. So I hid the payload somewhere else.

Last time I wrote about hiding a prompt-injection payload in an MCP tool's description and watching five of seven models exfiltrate a record they were never asked to touch. The tidy takeaway at the end was: scan tool descriptions at registration the way you scan tool output at runtime.

Then I tried to break my own advice. It took about twenty minutes.

The advice assumes the payload lives in the prose

A tool definition is not one field. When an MCP host hands a tool to the model, it hands over the whole function schema as trusted capability metadata. The function description, sure. But also every parameter's description. And whatever extra property the server felt like declaring, with a description field of its own. A human reviewing a third-party tool reads the prose description and skims the rest. The model reads all of it.

So I kept the payload identical, byte for byte, and moved it around inside the definition. Same <system> directive telling the agent to also export the record to an attacker URL. Three places to put it:

• desc.. in the function description. This is the original attack, my control.
• param_desc.. in the record_id parameter's description. A field that reads as "The record id." and nothing else.
• added_prop.. inside the description of an extra optional property called retention_policy that the server declares and the user never fills in.

The datastore stays honest the whole time. read_record returns the real record, export_record gets recorded but not performed. The only hostile thing in the entire setup is which schema field holds the sentence.

It made no difference at all

Every model that took the order in the description took it in the parameter field, and in the buried property, at the same rate. No model closed one field and left another open. It was all or nothing, and the field made no difference to which.

(One model, llama-3.1-8b, kept returning a malformed tool call on this schema and scored neither way, so I left it out rather than count an error as a result.)

The field nobody reads as an instruction

The parameter description and the buried property are worse than the prose, from a defender's seat, precisely because nobody reads them as instructions. "The record id." is not a sentence you audit. A scanner that only lints the top-level description walks right past a payload sitting one field over. If you're going to check tool definitions at registration, you have to walk every string in the schema, not just the part that looks like documentation.

The wall guards one door, not the building

Watch gpt-oss-120b across the two experiments. Last time, when the same payload arrived in the tool's returned output, it refused. Here, in all three definition fields, it obeyed. Same model, same words.

OpenAI's instruction hierarchy ranks tool output at the bottom of the trust order, so a model trained on it discounts instructions that show up in a tool result. But none of these fields are tool output. They're the tool definition, and the definition loads in above that boundary, in the trusted declaration framing, before any data exists. The training that closes the output channel does nothing for any part of the definition. The whole thing sits on the trusted side of the only wall that got built.

Claude refused every field on both models, consistent with where it landed last time. Same caveat I always attach: refusing here is not immunity, the public injection numbers are aggregates rather than this exact case, and every model gives more ground the more times you ask. A direction, not a promise.

What I'd actually do about it

The prevention move gets a little bigger and stays probabilistic: a registration-time check has to read every field of a tool definition as potentially hostile, because every field is attacker-controlled in a supply-chain server and every field reaches the model as trusted context. Worth doing. Not sufficient.

The part I keep landing on is the same as last time, and this experiment is why. The payload can hide in a field you didn't think to scan, in a channel your model training didn't cover, and you won't know which until after the agent has already made the call. So the durable thing isn't one more filter. It's a record that survives being wrong: a per-call, tamper-evident log that shows the directive that actually came in, next to the tool call that actually fired. When export_record goes off with no human behind it, that gap is visible and pinned on the agent instead of quietly landing on whoever's session it ran in. It doesn't matter which schema field carried the instruction. The record reads the same. That is the thing I am building Crumb for.

Honest scope

Tool-definition poisoning is a named class, documented by Invariant Labs in 2025, in the family of indirect prompt injection (Greshake et al. 2023, OWASP LLM01, InjecAgent, AgentDojo). I'm demonstrating and decomposing it, not discovering it.

What's mine here is the controlled split across three sub-fields with one payload held constant. They turned out equally effective, so the surface is the whole definition, not the part that reads like prose. And there's the cross-run tell: it locates exactly what instruction-hierarchy training protects, and what it never touches.

Everything ran offline against Groq-hosted, OpenAI, and Anthropic models. The export is a recorded attempt against a fake destination. Nothing left the lab.

The first piece is the setup for this one, if you want the description-versus-output result it builds on.

Crumb: crumb.alexlaguardia.dev · github.com/AlexlaGuardia/crumb