You wired your AI agent — a program that acts on its own, calling external tools to get things done — to a dozen MCP (Model Context Protocol — a universal plug standard for AI tools, like USB but for data) servers. You tested it. Demo went great. You shipped it to production, where real systems break in real ways.

Then the first tool timeout hit. Your agent retried the same failing call nine times, burned $12 in tokens (word-chunks AI processes, billed per use), and hallucinated a fake result. Because nothing — literally nothing in the protocol — told it the error was permanent.

Four priorities, zero about errors

On April 19, the MCP project published its 2026 roadmap. Four priorities: transport evolution, agent communication, governance, enterprise readiness. Error taxonomy — the thing that breaks every production agent — didn't make the list. Not mentioned. Not planned. Not on anyone's radar.

This isn't an oversight you can shrug off. The official MCP specification (current revision: November 25, 2025) defines tool execution errors as isError: true plus a free-text English string — the same structure as a successful response, but with a boolean flipped. No error code field. No retry-after header. No severity level. The spec literally says tool errors contain "actionable feedback that language models can use to self-correct." That "actionable feedback" is an unstructured English sentence the LLM has to read and interpret on its own.

HTTP — the protocol your browser uses — solved this over thirty years ago. 404 means "doesn't exist." 429 means "slow down." 503 means "try again later." Three digits. A lookup table. MCP asks a probabilistic language model to do what an if-statement should.

Everyone builds their own duct tape

Alexey Tyurin published an MCP Reliability Playbook on March 9, 2026, through Google Cloud Community. He had to invent his own error taxonomy — CircuitOpenError, TimeoutError, RateLimitError — as custom typed errors, because the protocol provides none. Circuit breaker with a 50% error threshold, exponential backoff with jitter. 317 tests just to make tools not crash his agent. All custom. All per-server. All incompatible with everyone else's duct tape.

Meanwhile, researchers at Polytechnique Montreal analyzed 407 MCP-specific bugs across 385 repositories (published March 5, 2026) and found tool response handling was the most frequent fault category — 66.7% of surveyed practitioners had hit it. And a Claude Code bug from March 11 showed the protocol breaking in an even more basic way: when MCP tools returned data in the content field without structuredContent, Claude Code perceived an empty response and retried infinitely. The agent didn't know it was already getting the right answer.

The numbers don't lie

AWS Heroes research from March 18 quantified the damage: 97.1% of MCP tools have at least one description quality issue, and chained tool calls at 95% individual success each deliver only 85.7% overall reliability. Add unstructured error handling to that chain, and you're rolling dice with production traffic.

The AAIF MCP Summit on April 19 in New York drew 1,200 attendees and Linux Foundation CEO Jim Zemlin calling MCP "the Linux of agents." Bold comparison — Linux shipped proper error codes from day one.

What you should do right now

Until Anthropic — the protocol owner — ships an MCP spec revision with machine-readable error types, wrap your MCP tools with structured error envelopes: a string error_type, a boolean is_retryable, and a numeric retry_delay_seconds. Set a hard per-tool retry budget on the client side. Three attempts max. Then fail loudly.

The agent tool ecosystem is replaying the early web's error-handling chaos at 10x speed. Somewhere between "tool error" and "$12 in burned tokens," there's a three-digit status code waiting to be invented. The platform that ships it first will own the reliability layer everyone else depends on — the way 200 OK became invisible infrastructure nobody thinks about.

Until then, your agent is guessing. And it's not great at guessing.