What is an AI agent, and why does tool selection matter?
An AI agent gathers information, chooses its next step and calls software tools to pursue a goal. A tool lets it do something beyond writing text: look up an order, find shipment events or prepare a reply for a support employee to review. Function calling means the model proposes a named operation and its arguments. Application code validates that proposal and calls the actual system. Producing a tool name does not establish that the operation is correct, authorised or complete, and a fluent explanation does not replace a checked result.
Tool selection involves two decisions. Your team first decides which capabilities belong in the catalogue; the agent then chooses among them for a particular task. Exposing every backend endpoint creates overlapping choices and unnecessary access to data. A small catalogue is not automatically sufficient either: a missing capability can push the agent towards guessing. The aim is a set that completes authorised tasks with understandable results. A tool that returns every customer record to find one order may appear functional while exposing far more information than the task requires. Keep routing in code when known conditions determine the choice, and give the model discretion where the next information need depends on evidence discovered during the task.
A tool contract checklist
Complete these six checks before adding a tool. A contract covers more than the input schema: it explains when to use the operation, where its authority ends and how to interpret its result. For each row, write a valid example and a call that must be rejected. If the tool owner cannot answer a question, resolve the gap before exposing it. Pay particular attention to similar names: reading an order status and cancelling an order are different capabilities, with different permissions and consequences.
| Check | Write into the contract | Acceptance evidence |
|---|---|---|
| Purpose and name | One purpose, a clear action name | Example distinguishes it from similar tools |
| Inputs | Required fields, types and limits | Missing or excessive inputs are rejected |
| Outputs | Identifiers, status, time and result scope | Agent can choose the next step |
| Authority | Permitted role, tenant and target | Server blocks unauthorised calls |
| Errors and retries | Error categories and safe retry rules | Timeout cannot create a duplicate operation |
| Operations | Owner, version, time and call limits | Trace identifies who should investigate |
Review the checklist with the product team. Instead of putting an entire process manual in a tool description, state its permitted purpose, prerequisites and external effects plainly. If an order search returns several plausible matches, specify that the agent must ask a distinguishing question rather than select the first record. Document which fields can resolve that ambiguity without asking the customer to disclose unnecessary information.
How to design narrow tools that advance the task
Start with examples of tasks the agent should complete. For each, record the necessary information and expected final state, then design the narrowest useful operation. Anthropic's tool design guidance recommends task-oriented tools and realistic evaluation rather than exposing existing endpoints indiscriminately. Related reads can be combined behind one tool when they are normally needed together; do not hide a state-changing operation inside that convenience. A customer context lookup, for example, should not silently update a record merely because the underlying application offers that option.
Define inputs such as order ID, date range, allowed statuses and maximum results. Use stable identifiers to select targets, while returning readable names and status information to help the model interpret them. The JSON Schema object reference describes properties, required fields and treatment of additional properties as separate rules. Validate them on the server. A correctly typed order ID can still belong to another customer, so schema validation does not establish business validity or authorisation. Decide what happens to unknown fields instead of allowing their meaning to vary between implementations.
Return information needed for the next decision: order ID, current status, shipment ID and the time the data was last updated. Offer pagination and date filters for long histories. If results are truncated, say that more records exist; an incomplete list must not look complete. Include time zones for relevant timestamps and currency for amounts. Distinguish not found, unauthorised, invalid input, rate limit and temporary service failure. Those categories should lead to different behaviour: clarify, stop, wait or safely retry. Avoid a generic error string that encourages the agent to try unrelated tools until something appears to work.
Separate reading, proposing and executing
For a support agent, order and shipment lookup tools are often a useful starting point. Preparing a reply is another capability; sending it is a separate external effect. If refund suggestions become necessary, expose a proposal tool that creates a review item rather than immediately providing payment execution. The target, amount and currency shown to the reviewer must remain the same when the approved action runs. A change to those parameters requires a new proposal, rather than reusing the earlier approval.
OWASP's excessive agency guidance distinguishes unnecessary functionality, permissions and autonomy. At every call, the tool server should check the authenticated user's role, tenant and rights over the target. A role or customer identifier supplied by the model is not evidence of authority. Apply limits to duration, request rate and result size. Text inside a tool result must not replace the application's security policy or expand the operations available to the agent.
For write tools, preserve an action identifier and define retry behaviour. A timeout does not prove that the downstream service did nothing; query the operation's status before repeating it. Traces should include tool version, actor, target, start time, error category and verified result. Keep enough information to investigate without copying unnecessary sensitive content into logs. Identify the service owner and recovery procedure. Verify the final state in the actual system rather than accepting a success sentence from the model or treating an HTTP response as proof of the intended business outcome.
Hypothetical example: a support agent with three tools
Suppose a hypothetical pilot evaluates 120 support requests: 80 order-status questions, 25 shipment delays and 15 damage complaints. The initial catalogue provides order lookup, shipment lookup and reply drafting. When a customer has two relevant orders, the agent asks which one they mean. For damage complaints, it gathers evidence and prepares a draft for employee review; it does not execute a refund. Assume you set a maximum of ten results per tool call and six calls per task. These are example configuration choices, to be checked against the actual support process.
Build a second candidate catalogue with twelve tools. Imagine the smaller set completes 108 requests correctly and the larger set completes 109, while wrong tool selections rise from three to nine. These are illustrative figures, not measured product results. Assess the extra successful case alongside the impact of wrong calls, latency and cost. If shipment-exception lookup is the capability responsible for the improvement, add that tool alone to the smaller set and evaluate again. There is no requirement to adopt the full larger catalogue. Use the same cases for comparison, and count a necessary clarifying question as correct behaviour rather than a failure to act quickly.
A test plan for tool selection
- Specify the expected result. For every case, record the correct target, permitted action and required human handoff. Where several safe tool paths exist, accept them instead of enforcing one arbitrary sequence.
- Separate choice from arguments. Label wrong tool, correct tool with wrong target, and failure to use a necessary tool separately. Change descriptions in response to the particular category they should improve.
- Exercise the boundaries. Include missing identifiers, similar orders, another tenant, stale information, empty results, rate limits and timeouts. Check the expected stop, wait or clarification behaviour.
- Verify external effects. Test attempts to write without approval and repeated execution calls. Inspect the final record in the test environment; the model's claim that it succeeded is insufficient.
- Compare catalogues. Measure task completion, wrong calls, total calls, cost and latency on identical cases. Re-run a separate held-out set after changing the model, schema or description.
Common mistakes
- Turning every API endpoint into a tool and leaving the model to distinguish overlapping operations.
- Treating schema validation as authorisation and allowing access to another customer's valid identifier.
- Hiding sending or record changes inside an operation described as read only.
- Returning a truncated list without explaining the result limit or available continuation.
- Repeating a write after a timeout without checking whether the first operation completed.
How Hatson Tech builds this
We start by mapping task examples, source-system permissions and expected final states. We design the narrow catalogue, server validation and operation traces together as part of AI agent development. For the underlying concept, see our AI agents guide; for operating limits, see AI agents in production. Initial acceptance checks require the tool to complete the permitted task under the correct identity and stop when evidence is ambiguous. That gives the team a concrete basis for deciding whether another capability is needed.