An agent's action space is the list of tools it can call. Tool design is deciding what those tools are, how they are described, and what they return, so the model picks the right one and can use what comes back. The basic principle follows from one fact: the model never sees your code, only each tool's name, description, parameters, and results. So you design tools around the user's tasks, describe them the way you would brief a new colleague, return short results with identifiers (IDs) and helpful errors, and load only the tools the current task needs.

Throughout this tutorial the example is an online store's customer support agent. It answers "where is my order?", changes shipping addresses, issues refunds, and cancels orders, on top of an order service with 38 REST endpoints plus payments, shipping, and ticketing. Across the company's internal platform there are about 200 candidate tools from 9 services.

Tool design matters when you hand an agent an existing system like that, or when an agent keeps picking the wrong tool, looping on errors, or running out of context on large results. It does not matter much for a fixed workflow whose steps never change, where ordinary code should call the APIs and the model should only handle the language step. A chat feature that makes a single tool call also needs nothing beyond plain function calling.

In an agent design round, "what tools does it have?" usually comes right after you choose the loop, and it leads to follow-ups on descriptions, scale, code, and protocol. A mid-level answer lists sensible task-level tools and separates reads from writes. A senior answer also reshapes descriptions and results for the model, handles a platform with 200 tools, chooses between JSON calls and code, and argues when MCP (Model Context Protocol), a shared protocol for exposing tools, is worth its extra hop.