Tool calling (function calling)

In tool calling, the application tells the model which functions exist, with a name, a description and a typed argument schema. When the model decides it needs one, it emits a structured call, for example get_order with order_id set to a value, rather than free text. The application validates the arguments, runs the function against the real system, and returns the result to the model, which then decides the next step. The model never executes anything itself; it asks, and the application decides.

This is the foundation of every agent. Retrieval, database queries, CRM updates, payment actions and hand-offs are all tools. Good tool design matters more than prompt wording: small, well-named functions with strict schemas and clear error messages produce far more reliable agents than a few large, vague ones.

Tool calling is not the same as giving a model access to your systems. The application layer chooses which tools to expose to which agent, checks permissions on every call, applies policy gates to consequential actions, and logs each call and result. It is also distinct from MCP, which is a standard for describing and serving tools across applications; tool calling is what the model does with them.

• CTO / Head of Engineering: tool design and schema strictness are the largest lever on agent reliability; treat tools as an API product.
• CISO: every tool is a capability the model can request; least privilege per agent and validation of every argument are essential.
• Product manager: the set of tools defines what the agent can actually do for users; it is the real feature list.
• Data lead: read tools over your data need permission-aware access so the agent cannot surface rows a user may not see.

Models produce text; businesses run on systems. Tool calling exists to bridge the two in a controlled way: the model expresses intent in a structured form, and the application executes it with validation, permissions and logging. The failure it prevents is the fragile approach of parsing free text for commands, which breaks unpredictably. The trade-off is that tools must be designed carefully: too many, too broad or poorly described, and the model chooses wrongly. Structured outputs and evals on tool selection are how teams keep that under control.

• A SaaS copilot calling the product's own API to create projects, update settings and generate reports on the user's behalf.
• A banking assistant calling balance, card-block and dispute-filing tools with per-call authentication tied to the customer.
• A hospital voice agent calling slot-search and booking tools against the scheduling system during a live call.
• A retail returns agent calling order-lookup, policy-check and refund tools, with the refund tool behind a threshold gate.
• An analytics assistant calling a governed query tool that applies row-level security before running SQL.

Technique / practiceAn engineering technique, and the core of every agent Eazyware builds under AI agents. Tools are designed as a small internal API with strict schemas, per-agent permissions and evals on tool selection accuracy.

Eazyware service that covers it: AI Agents & Automation. Starting prices are on the pricing page.