PathweysAI Engineer Track · Ai Agents
Tools & Function Calling as Agent Primitive
Tools & Function Calling as Agent Primitive
Tools are what an agent can actually do, search something, query a database, send a message, run code, each declared with a name, a description of when to use it, and a schema for its arguments, and invoked through the model's own function-calling mechanism. An agent's usefulness and its risk both come directly from its tools: what it is given access to is what it is capable of, for better or worse.
Why this matters
Well-designed tools, with clear descriptions and a narrow, well-defined scope, make an agent choose correctly and act reliably. Vague or overly broad tools cause it to pick the wrong one, call it incorrectly, or, if a tool has real side effects, cause genuine damage when something goes wrong.
Tools as the agent primitive
Tools are an agent's effectors: the actual functions it can invoke, searching a knowledge base, querying a database, sending an email, each declared with a name, a description, and an argument schema, and triggered through the model's own function-calling mechanism rather than through free text. An agent is only ever as capable, and as dangerous, as the tools it has been given. Well-designed tools, with clear descriptions, narrow scope, and validated arguments, make an agent act reliably; poorly designed ones cause wrong tool selection, malformed calls, and in the worst case genuine security incidents. Tool design sits exactly where capability and safety meet: the description tells the model when to use a tool, the schema tells it what a valid call actually looks like, and the surrounding code is responsible for validating and executing whatever the model proposes.
Tools are the boundary between a model's reasoning and the real world it can affect. Design that boundary deliberately rather than as an afterthought.
Designing tools for an agent
Three rules make a tool reliable in practice. Describe it for the model, not for a database administrator: state when to use it, what it returns, and what side effects it has, written the way documentation for a new engineer would be written. Constrain its schema with specific types, enums for closed sets of values, and a required-fields list, so arguments come back valid rather than merely plausible. And validate every argument before executing anything, since the model's arguments are suggestions, not guarantees, no matter how confident the call looked. The failure modes trace directly back to skipping these: a vague description causes the wrong tool to be selected for the situation at hand, a schema missing required fields lets arguments come back empty when they should not, and skipping validation lets a malformed or unsafe call reach a real system unchecked.
The model decides which tool to call and with what arguments; your code validates before anything happens. That specific split between deciding and executing is where an agent's reliability actually lives.
Worked example
A search_kb tool described only as 'searches the knowledge base' gets called for questions it was never meant to handle, while the same tool redescribed as 'searches the internal product knowledge base for customer-facing product questions; returns the top five matching snippets' gets selected correctly and skipped correctly, purely because the description now tells the model exactly when to reach for it.
Practice
Design three to five tools for a real workflow and test them against twenty varied requests, observing selection accuracy directly. Record every description change made after observing a wrong tool selection, and confirm accuracy afterward.
Interview checks
- Why does a tool's description matter as much as its schema for reliability?
- What specifically goes wrong when an agent is given too many tools at once?
- Why can't a tool's arguments be trusted without validation, even when the call looks well-formed?
Common failure modes
- Vague tool descriptions that cause the wrong tool to be selected for a given request.
- Too many tools exposed at once, which measurably degrades selection accuracy as the tool count grows.
- Tools with real side effects exposed without any safeguards around their execution.
- Wrong granularity, either too fine, forcing many slow round-trips, or too coarse, creating one unwieldy tool that tries to do everything.
Resources
- Gorilla: Large Language Model Connected with Massive APIs — Covers the API-calling problem at scale, explaining concretely why tool selection degrades as the number of available tools grows.
- Anthropic Tool Use overview — The production tool-use model, including best practices for how a tool should actually be defined.
Expert signals
Writing tool descriptions for a model audience, when to use it, what it returns, its side effects, keeping the tool count small and tightly scoped, and validating every argument before executing it, while treating tools as a genuine security boundary rather than a convenience layer, is what separates a reliable agent from one that occasionally picks the wrong action with real consequences.
Confidence
high