A booking tool expects dates as YYYY-MM-DD, but the model calls it with "31/02/2026". The request matches the CallToolRequest structure. The team wants the model to be able to notice the mistake and correct the call on its own. What should the server return?
Select an answer to reveal the explanation.
Short Explanation
When the model fills in a field wrong, you hand the form back with a sticky note: "use YYYY-MM-DD." That's a tool execution error with isError true, and the model can fix it itself. The trap is a JSON-RPC error, which the model is far less likely to recover from.
Full Explanation
The tools specification separates protocol errors from tool execution errors, and it lists input validation errors, explicitly including a date in the wrong format or a value out of range, as tool execution errors. These are returned in a normal tool result with isError set to true and content that explains what went wrong, because clients should provide such errors to the model so it can self-correct and retry with adjusted parameters. A JSON-RPC -32602 error is meant for requests that fail the CallToolRequest schema or name an unknown tool; the request here is structurally valid, and a protocol error is less likely to reach or help the model. Returning success with empty content hides the failure and invites the model to report a booking that never happened. Asking the user through elicitation shifts a model-made mistake onto the user, adds a round trip, and does not meet the stated goal that the model correct the call itself. Exam caveat: the best error text is actionable, naming the expected format and the rejected value. Operational check: call the tool with a malformed date and confirm the response is a result with isError true and a message the model can act on, then confirm a corrected retry succeeds.