A flight-booking tool receives a departure date that is already in the past. The model could fix the call if it were told what went wrong. How should the server report this problem?
Select an answer to reveal the explanation.
Short Explanation
If the model can fix it, you tell the model in words it can read. That's what isError true with a clear message does. A JSON-RPC error is for broken requests, and that's the trap here.
Full Explanation
The tools specification separates two error mechanisms. Protocol errors cover problems with the request structure that models are unlikely to fix, such as an unknown tool, a malformed request or a server error, and they are returned as standard JSON-RPC errors. Tool execution errors carry actionable feedback that models can use to self-correct and retry with adjusted parameters; they include API failures, business logic errors and input validation errors such as a date in the wrong format or a value out of range. They are reported inside a normal result with isError set to true, and the specification's own example is an invalid departure date that must be in the future. Clients SHOULD pass tool execution errors to the model, which is why this path enables correction. Returning -32602 treats a fixable argument value as a malformed request, and clients may not pass protocol errors to the model at all. A successful result with an empty content array hides the failure and gives the model nothing to act on. A log notification is request-scoped diagnostic output emitted only when a log level is requested, and it is not a substitute for a result the model reads. Exam caveat: an unknown tool name is the opposite case, a protocol error. Operational check: call the tool with a past date and confirm the result has isError true and readable text naming the problem.