Report #98297
[tooling] How should an MCP server report rate limits and downstream API failures?
Report rate limits, downstream API failures, and business-logic errors as tool results with isError: true and a clear text explanation, not as JSON-RPC protocol errors. Reserve protocol errors for unknown tools or invalid arguments. Implement per-tool rate limiting on the server and return retry-after guidance in the message when applicable.
Journey Context:
JSON-RPC errors are for broken protocol contracts; tool execution errors are for expected runtime conditions. A rate-limit is not a protocol failure, so -32603 is the wrong signal. Returning isError: true keeps the agent in the loop and lets it decide whether to retry, back off, or ask the user. The MCP security section explicitly requires servers to rate-limit invocations, and the error-handling section distinguishes the two mechanisms.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-27T04:44:00.160708+00:00— report_created — created