Task 2.2: Implement structured error responses for MCP tools

• AKeep the generic message but have the agent retry every failure with exponential backoff before giving up

  Incorrect

  Retrying a policy violation wastes calls and time; the agent needs to know which failures are worth retrying.

• BReturn an error result with a category, such as transient or policy, and a flag saying whether to retry

  Correct

  A tool execution error that says what kind of failure it is lets the agent retry the timeout and explain the expired window instead.

• CRetry gateway timeouts inside the tool and return "Operation failed" only for the failures that remain

  Incorrect

  Timeouts that outlast the internal retries and expired windows still look identical, so the agent still cannot tell which to retry and which to explain.

• DReturn a successful result with an empty refund record so that the agent does not loop on failures

  Incorrect

  Reporting a failure as success hides it; the agent would tell the customer the refund went through.

Report tool failures as error results with enough structure for the agent to choose: a category that separates transient failures from business-rule ones, and a retryable flag. A uniform "Operation failed" removes that choice, however the retries are arranged.

• AReturn a retryable isError result on timeouts, and a normal result that states zero matches when the query worked

  Correct

  A failed lookup and a valid empty result mean different things and call for different decisions, so the tool must keep them apart.

• BRetry the database query until it succeeds, however long that takes, so that callers never see a timeout

  Incorrect

  Unbounded retries can stall the whole run; transient failures need a limit and then an honest report.

• CReturn an empty list in both cases and add a note to the coordinator's prompt that empty results may be timeouts

  Incorrect

  The coordinator still cannot tell which empty list was a timeout, so it can only guess.

• DTreat every empty result as a failure and raise an error, so the coordinator always retries the search

  Incorrect

  A query with no matches is a successful answer; turning it into an error triggers pointless retries.

Distinguish access failures from valid empty results. Report the first as a structured, retryable error and the second as a successful query with no matches, so the coordinator can retry one and trust the other.

• ANothing; the server will answer eventually

  Incorrect

  That is not guaranteed, and the agent is frozen meanwhile.

• BA timeout for each tool call, reported as an error

  Correct

  The MCP spec says clients should implement timeouts so a hung call becomes a recoverable error.

• CA rule that the agent may call the server only once per session

  Incorrect

  Limiting calls does not stop the one call that hangs.

• DA longer wait before the client gives up and restarts the agent

  Incorrect

  Restarting loses the run's progress over one slow call.

Clients should implement timeouts for tool calls and surface them as errors the model can act on.

• AThe same data serialized as JSON in a text content block

  Correct

  For backward compatibility, a tool returning structured content should also return it as TextContent.

• BNothing else, since structuredContent replaces the content field

  Incorrect

  Older clients read content, so they would see an empty result.

• CAn image of the result for clients that cannot read JSON

  Incorrect

  A text copy of the JSON is the documented fallback.

• DA protocol error so that older clients know to upgrade

  Incorrect

  That breaks working tools to signal a version difference.

Structured results go in structuredContent and should conform to the outputSchema; also include the serialized JSON as text content for clients that read only content.

• ARetry the call every few seconds until it succeeds while the customer waits

  Incorrect

  Tight retries keep the customer waiting with no update and do not shorten the outage.

• BEscalate to a human at once so that a person can create the label

  Incorrect

  A person cannot create the label while the system is down either; escalation adds a wait without solving anything.

• CSay plainly that the label could not be created yet and what happens next

  Correct

  Claude incorporates the error into its reply, so the customer hears the truth and the next step instead of a false success.

• DTell the customer the label will arrive by email shortly, without mentioning the failure

  Incorrect

  This promises something that has not happened and hides that the action failed.

When a tool returns an error, Claude incorporates it into its response: tell the customer honestly that the action did not complete and what will happen next, rather than looping, escalating to someone who cannot help, or implying success.

• AHave add_item return a successful empty cart when the ID has expired, so that the call never fails

  Incorrect

  Reporting success hides the expiry; the agent would add items to a cart that no longer exists.

• BKeep each cart tied to the MCP connection instead of passing cart_id between calls

  Incorrect

  MCP has no protocol-level session, so a server cannot rely on per-connection state to relate one call to the next.

• CEncode the customer ID and creation time inside cart_id so that the agent can work out when it expires

  Incorrect

  Handles that encode internal structure invite parsing or guessing; the specification recommends opaque identifiers.

• DState the 24-hour expiry in create_cart's description so that the agent sees the lifetime when it creates a cart

  Correct

  The retention policy belongs in the creation tool's description, where the model sees it when deciding to create state.

• EMake add_item answer an expired ID with a tool execution error saying the cart expired and a new one can be created

  Correct

  A call against an expired handle should return an error that says so, letting the model recover by creating a new handle.

MCP servers that keep state across calls return an explicit, opaque handle. State its lifetime in the creation tool's description, and when a call uses an expired or unknown handle, return a tool execution error that says so, so the model can create a new one.

• APass structured results to the model as they arrive, since the server is responsible for conforming to its schema

  Incorrect

  Servers must conform, but this one does not; the specification also asks clients to validate what they receive.

• BValidate each structured result against the tool's outputSchema and report a mismatch to the model as an error

  Correct

  Clients should validate structured results against the output schema and validate tool results before passing them to the model.

• CDrop the outputSchema from the tool definitions so that mismatches no longer occur

  Incorrect

  Removing the schema removes the check, not the missing fields.

• DAsk the model in the system prompt to double-check each record for missing fields

  Incorrect

  A probabilistic check in the prompt is weaker than validating against the schema you already have.

When a tool declares an outputSchema, servers must return conforming structured results and clients should validate them. Validate on the client and surface a failure as an error the agent can act on, rather than passing incomplete data on as if it were whole.