MyDot Consultancy

Featured image: AI-generated conceptual illustration. Sources checked 26 October 2026.

A support agent with access to fifty overlapping tools may be less usable than one with six well-designed capabilities. The issue is not the number alone. It is whether the agent can distinguish the tools, supply the right inputs and understand the results. Exposing every endpoint in a business application rarely creates that clarity automatically.

Tool design starts with the work you want completed. A support employee thinks in tasks such as finding an order, checking eligibility and preparing a response. An API may be organized around tables, internal service names and historical implementation choices. An agent-facing tool layer should translate between those two views without weakening the controls underneath.

Audit the confusing choices first

Imagine a hypothetical retailer with tools named search, lookup, find_customer, query_records and get_profile. Several can return customer information, but each uses different identifiers and exposes different fields. An agent handling a return has to discover those differences while also solving the customer’s problem.

Begin with real failed runs. Did the agent choose the wrong tool, repeatedly call similar tools or request information that was already present? Did it receive too much irrelevant data? Group those problems by task rather than assuming that a longer tool description will fix everything.

Anthropic’s Writing effective tools for agents discusses tool selection, namespacing and useful responses. The practical application is to make capabilities distinct enough that a reasonable agent can choose among them from the task and available evidence.

Name the business operation and its scope

A name such as orders_find_by_reference carries more meaning than search_v2. The description can then specify accepted references, returned fields and cases where another tool is appropriate. Consistent naming helps distinguish a read from a change and one system from another.

Do not hide side effects in convenient names. A tool called resolve_ticket should not silently send a customer message, issue a credit and close the case unless those combined actions are explicit and appropriately authorized. Convenience is not a reason to bundle unrelated permissions.

For the return workflow, separate checking eligibility, preparing a refund proposal and executing an approved refund. These steps may share data, but they have different consequences. The tool layer should make those consequences visible rather than asking the model to remember an exception buried in a long prompt.

Give the next decision what it needs

A return-eligibility result should contain the relevant policy decision, supporting order facts and a clear reason when eligibility cannot be determined. Returning the entire customer history may make the result harder to use and expose data unrelated to the task. Conversely, returning only true or false may leave the agent unable to explain a legitimate exception.

Choose fields by examining the next decision. Does the agent need the purchase date, product category, policy version or prior return status? Include those deliberately. Use stable identifiers for follow-up calls and human-readable labels for explanations. Keep pagination explicit so a partial result is not mistaken for a complete search.

Treat an empty result as information with a defined meaning. “No matching order in this store” differs from “search service unavailable.” If both produce an empty list, the agent may incorrectly tell a customer that an order does not exist. Result design should preserve distinctions the business cares about.

Keep implementation details outside the model when possible

An agent does not need to reconstruct a complicated internal API sequence every time a user asks a routine question. A well-scoped tool can perform deterministic lookups and checks, then return a useful summary. This reduces opportunities for the model to omit a required technical step.

The boundary must remain inspectable. Record which underlying systems were consulted and expose enough status information to diagnose failures. A tool that combines several reads should report partial coverage rather than presenting an incomplete result as comprehensive. A tool that changes state needs an even clearer execution contract.

The OpenAI Agents SDK tools guide documents different tool mechanisms and function-tool handling. Choose the mechanism after defining the task boundary. A framework can wrap a function, but it cannot decide whether that function represents a safe business capability.

Test tools as a set

A tool may work perfectly in isolation and still confuse an agent when presented beside similar options. Evaluate realistic tasks using the actual collection of tools the agent will see. Include ambiguous language, missing identifiers and cases that should lead to a clarification rather than an action.

• Selection: did the agent choose the intended capability without unnecessary detours?
• Arguments: were identifiers and filters grounded in available evidence?
• Interpretation: did it understand empty, partial and failed results correctly?
• Authority: did read-only requests stay read-only?
• Outcome: did the task reach the required state without unapproved side effects?

Keep a record of tool descriptions and versions alongside evaluation results. If you rename a parameter or change the response shape, rerun the affected tasks. The Anthropic evaluation guide provides a broader framework for making behavioral changes visible. Apply it to tool design, not just model selection.

Remove ambiguity before adding capability

When a team proposes another tool, ask what new task it enables and why an existing capability cannot serve that task safely. Sometimes the right change is a clearer description, a better lookup or a more informative error. Sometimes a genuinely separate tool is needed because its permission boundary is different.

The goal is not a universal minimum tool count. A specialist agent may need several capabilities, and a broad system may need controlled discovery. The goal is a toolset whose distinctions match the work. Clear names, scoped actions and useful results give the agent fewer opportunities to make the wrong choice and give operators a better explanation when it does.

Sources and further reading

Anthropic: Writing effective tools for agents. Namespacing, tool selection and response design; published September 2025.

OpenAI Agents SDK: Tools. Primary reference for tool mechanisms and handling; checked October 2026.

Anthropic: Demystifying evals for AI agents. Evaluation methods for multi-step agent behavior; published January 2026.