Core concept: A tool failure should arrive as data the agent can act on. MCP reports tool execution failures inside the result, not as a protocol error. Good error payloads add machine-readable recovery hints.

Why A and C are correct:

A: The MCP spec reports "Tool Execution Errors" in tool results "with isError: true", listing "API failures" as an example. A downstream rate limit is exactly that. The flag tells the agent the call failed instead of a fake success.
C: A rate limit is transient. An isRetryable: true field tells the agent to back off and try again rather than escalate or abandon the task.
Together they answer the agent's two questions: did this fail, and is another attempt worth making? Anthropic's tool guidance asks you to "communicate specific and actionable improvements, rather than opaque error codes".

Why the others are wrong:

B: system_prompt_override is not an MCP field. A tool result must never rewrite the agent's system prompt; that is a prompt-injection path, not error handling.
D: temperature_adjustment is a sampling knob, not error metadata. Changing temperature does nothing about a downstream rate limit.

Remember: Errors are written for the model to read: flag the failure with isError, then say whether retrying will help.

Question 180