Tool Use Pattern: Designing Agent Tool Sets
How a tool set is designed — names, descriptions, scope, response format — determines whether an agent is reliable or unpredictable.
Why This Pattern
Both named anti-patterns — One-to-one API Mirroring and Overloaded Tools — come from designing tools around the API's shape instead of the business action's shape. The reasoning discipline: name and scope every tool around what a person would say they're trying to do, not around what the underlying endpoint is called, because the LLM is selecting tools using the same intent language a user would use.
When to Use It
Every genie that takes action uses tools; the question is always how well the tool set is designed, not whether to use tools.
When NOT to Use It
- One-to-one API Mirroring — turning every granular API endpoint into its own MCP tool introduces hallucinations and forces complex orchestration for what should be a single business action.
- Overloaded tools — cramming a whole business goal into one tool via a
modeparameter makes it hard for the LLM to know why it's calling the tool, and hard to recover when something fails.
How It Works in Workato
Every skill should define explicit When to Use and When Not to Use guidance in its prompting fields — specific enough that the correct tool is obvious from the request alone, with negative guidance pointing to the correct alternative tool.
Source: MCP Cookbook V1.0, p. 16 · Agentic Development Cookbook V2.0, pp. 18–19