A server author reports every failure as a JSON-RPC error, reasoning that it is the stricter and more honest choice. Agents using the server never recover from bad arguments. Diagnose the design.

The principle — How a failure is classified decides who is told about it, and therefore whether anyone can act on it.

Why the key is correct — The two categories exist because they have different audiences. Protocol Errors indicate issues with the request structure itself that models are less likely to be able to fix, while Tool Execution Errors contain actionable feedback that language models can use to self-correct and retry with adjusted parameters. Input validation belongs to the second. The client-side rules then follow the classification, not the content: clients SHOULD provide tool execution errors to language models to enable self-correction, whereas clients MAY provide protocol errors to language models, though these are less likely to result in successful recovery. By filing everything as a protocol error, the author has opted every fixable failure into the category clients are least inclined to surface — and the symptom, agents that never recover from bad arguments, is exactly what that predicts.

Why the others are wrong — Clients are behaving as advised, so blaming them misreads the cause. A bare failure is not the actionable feedback self-correction depends on. And returning the error as an ordinary result would hide the failure entirely, which is worse than misclassifying it.

Remember this — Classify by who can fix it, because the routing follows the class. A server author who gets this wrong will see the symptom on the agent's side rather than their own, which is what makes it a hard bug to trace back to its source.

Sources — MCP first-party documentation.