Why MCP servers break agents silently (and your error tracker stays green)

Here's an experiment we run in our demo harness: a CRM-style MCP server ships v2, renaming `customer_id` to `contact_id` and adding a required `account_type`. The agent keeps sending the v1 shape. What happens next depends entirely on how the server was built, and neither outcome shows up as a schema problem anywhere in your stack.

The lenient path: 200 and wrong

Hand-rolled servers, proxies, and gateways commonly accept whatever arrives and ignore unknown fields. Our demo server's v2 handler returns `{"routed_to":"team-default","status":200}` for every v1-shaped request. No exception, no error log, no failed span. The agent believes it succeeded. Tickets misroute for days, and the debugging session starts with 'the agent got dumber', prompts, model version, temperature, because nothing in the stack versions the tool schema.

LLMs make this worse than classical software: a traditional client crashes on malformed situations, but a model absorbs them and produces confident wrong behavior. The traditional error signal that monitoring depends on never fires.

The strict path: -32602 and useless

SDK-default servers validate inputs, so the same request gets `MCP error -32602: Invalid arguments`. Your error tracker does catch that, 2,700 times, at 2am, as a stack trace ending in an RPC error. It doesn't say the schema changed seven minutes ago, doesn't show the diff, doesn't name the field or the agents affected. The engineer still does the archaeology.

What detection actually requires

Both paths share a root cause that only contract monitoring sees: the advertised schema diverged from what the consumer sends. Snapshot the contract on a schedule, diff it, cross-reference against a manifest of what each agent uses, and both failure modes collapse into one alert with a patch. Error tracking tells you you're bleeding; contract monitoring tells you who moved the knife.