Nobody writes error messages for an audience. They get written for whoever is unlucky enough to hit them, and that reader has always been a developer with a terminal open. Two researchers have now measured what happens when the reader is an agent that can do nothing except call tools.
They read the error-handling code of the 150 most-starred Model Context Protocol servers on GitHub and pulled out every message a failing tool can hand back to a model. About a third of them tell the caller what to do next. Half of those steps assume something the server cannot possibly know about whoever is calling, such as that it's got a terminal, a browser, a config file it can edit, or the ability to wait. On expired-credential errors, almost every piece of advice asked for exactly one of those.
Then they made agents read it. Each agent got the same task, the same failing tool call and the same saved state; the only thing that varied was the wording of the error. Told plainly that the session had expired, agents logged back in and finished the job about four times in five. Given that same message plus one sentence saying to run a terminal command, they finished 45% of the time. Rewriting that sentence to name the server's own login tool took it to 84%. Same repair, different wording. The rate-limit case is starker. GitHub's "Wait before retrying." left agents stuck in all but a handful of attempts, while naming the call to repeat rescued close to nine in ten.
"The agents in the experiment did what the step said: they carried out a step that named one of their tools, and when the step asked for something they could not do, most of them stopped, although their own tools could have made the repair and the same agents made it when the text gave only the cause."
The more capable the model, the more that one sentence cost it. The largest of the newest generation tested almost never recovered. It ended the turn and asked the user to go and sign in, with the login tool sitting unused in its own tool list. The authors call this literal compliance, and connect it to what OpenAI and Anthropic have published about their newest models weighing written instructions more heavily. That explanation is theirs, and this study can't test it, because the smallest model of that same generation behaved more like the older ones, and every model tested came from a single vendor. Whether this is a property of newer models or of one particular model is left open.
The vendor question matters less than who writes the text in the first place.
"The steps in error text are written by tool authors whom the agent's developer does not control, so the same server text can cost more recovery as agents move to newer models."
An error string is now part of your prompt, and it was written by someone you don't employ. Nothing in a vendor's benchmark suite will surface it, because agent evaluations run the happy path with tools that work, and the wording of a 401 never enters into it. A team can swap in a better model, change nothing else, and watch a reliability regression arrive through a dependency's copywriting.
On this evidence, a model upgrade deserves a rerun of the failure paths, not just the working ones. Expire a token, trip a rate limit, revoke a permission, and see whether the agent repairs itself or hands the job back. Where it hands the job back, the fix is on the side you control. The researchers stripped the advice out of every surveyed message with a one-sentence prompt for nine cents, and recovery came back. Treat third-party error copy as untrusted input, not because anyone is attacking you, but because it is addressed to a reader who is no longer the one showing up.
Sources
- Xu, X., Wu, W., "MCP Error Messages Written for Developers Hurt the Most Capable Agents Most" — https://arxiv.org/abs/2609.35381