Design tools an agent can use reliably
An agent is only as reliable as the tools you give it. Narrow scope, tight input schemas, and actionable error messages prevent most tool-call failures.
Narrow, well-named tools
A tool that does one clear thing is easier for the model to choose correctly than a sprawling multi-purpose one. Name tools and parameters the way you would name them for a new engineer, because the model reasons about them the same way.
Validate inputs at the boundary
Do not assume the agent passed sensible arguments. Validate at the tool boundary and reject bad input with a clear reason, so the agent can correct itself rather than silently doing the wrong thing.
Return errors the agent can act on
A tool that fails with "error 400" teaches the agent nothing. A tool that says "customer_id not found, check the id and try again" gives it a path to recover. Good error messages are one of the highest-leverage reliability investments, because they turn dead ends into retries. Where a tool causes side effects, make it idempotent so a retry is safe.
Key takeaways
- Prefer narrow, clearly named tools over broad multi-purpose ones.
- Validate arguments at the tool boundary and reject bad input clearly.
- Return actionable error messages, and make side-effecting tools idempotent.