A host logs two failures from the same MCP server. In one, the model called a tool name the server does not offer. In the other, a valid tool reached an upstream weather API that returned HTTP 503. How should each failure be reported by the server?
Select an answer to reveal the explanation.
Short Explanation
Ask a waiter for a dish that isn't on the menu and your order never reaches the kitchen — that's a protocol error. Order a real dish and the oven breaks — that's the kitchen reporting a problem, a tool execution error. The trap is flipping the two, so you lose the error the model could actually fix.
Full Explanation
MCP tools use two error channels. Protocol errors cover problems with the request itself that a model is unlikely to fix: an unknown tool, a request that fails the CallToolRequest schema, or a server fault. They are returned as standard JSON-RPC errors, and an unknown tool uses -32602. Tool execution errors cover failures that happen while running a real tool, such as API failures, input validation problems and business-logic errors; they are returned in a normal result with isError set to true, so the client can pass the actionable text to the model for self-correction. An upstream 503 is precisely an API failure. Reporting both as isError results misclassifies a request that never matched any tool. Reporting both as protocol errors hides the 503 from the model, which could otherwise wait and retry or choose another approach. Swapping them reverses the defined categories. Exam caveat: clients may still show protocol errors to the model, but they are less likely to lead to recovery, while tool execution errors should be provided to the model. Operational check: replay both calls and confirm the unknown tool returns an error object while the 503 returns a result with isError true and explanatory text.