A tool is an interface for a model
By the end: Explain why tool design is interface design, and evaluate a tool from the model’s point of view.
The single highest-leverage thing you can improve in most agents is not the prompt and not the model. It is the tools. Teams routinely spend days refining wording while leaving a tool that returns an opaque blob of JSON with three fields the model needs and forty it does not.
That framing produces immediate consequences. A tool should do a task the model would recognise, not mirror your internal service boundaries. If a job always needs three calls in a fixed order, that is one tool, not three. If a tool needs an identifier the model has no way to obtain, either it needs a companion tool that finds identifiers or it needs to accept the thing the model actually has.
Return what helps the next decision. Models reason over what they can see, so a result that includes the three relevant fields with clear names beats one that includes everything and buries them. Where a result could be long, summarise and offer a way to fetch detail rather than dumping it into context.
- Before: get_order(order_id) → the full ORM row, 40 fields, internal enum codes, nested nulls.
- After: get_order(order_id) → { id, status: "shipped", shipped_on, carrier, tracking_url, customer_email, items: [{ sku, name, qty }] }
- Effect: fewer follow-up calls, shorter context, and answers that stop inventing field meanings.