AI Agentics · Tools

AI agent tools, tool use & function calling

Tools are how an agent acts on the world. This guide explains tool use and function calling end to end — defining a tool, the call lifecycle, the categories of tools that matter, the Model Context Protocol (MCP), and how to keep autonomous tool use safe.

  • 11 min read
  • Hands-on
  • Updated 2026

A language model on its own can only produce text. AI agent tools are what give it hands: functions the agent can call to fetch fresh data, change state, or trigger real-world actions. When an agent looks up an order, runs a SQL query, posts to Slack, or executes a snippet of code, it is exercising tool use — the single capability that separates an agent from a chatbot.

The plumbing that makes this work is function calling (also called tool calling). You describe each tool to the model with a name, a plain-English description, and a typed parameter schema. The model never runs anything itself — instead it emits a structured request naming the tool and its arguments. Your runtime validates those arguments, executes the matching handler, and returns the result so the model can keep reasoning toward the goal. It is the same loop that powers every LLM agent.

Beyond the mechanics, this page covers the practical decisions that make tools reliable in production: which categories of tools to expose, how the Model Context Protocol (MCP) standardizes integrations so the same tool works across frameworks, and the permission model you need before letting an autonomous agent touch anything that matters.

The mechanics

The tool call lifecycle

A single tool call is a five-stage round trip between the model and your runtime. Understanding it is the key to debugging any agent.

Model decidesPicks a tool & arguments
Validate argsCheck against JSON schema
Execute toolRun the handler / API
Return resultFeed output back in
Model continuesReason or finish
One turn of tool use: the model proposes a call, your runtime validates and executes it, then the result re-enters the model's context.

The critical detail: the model only proposes a call. The two stages in the middle — validation and execution — happen entirely in your code, which is exactly where you enforce safety. Validate that arguments match the schema, reject anything out of bounds, and decide whether the action needs a human approval before the handler ever runs. Return errors as structured tool results too: a good agent reads "row not found" or "permission denied" and re-plans instead of crashing.

Anatomy of a tool

Defining a tool: name, description, schema, handler

A tool is just a typed function plus the metadata the model needs to call it correctly. The description and schema are part of the prompt — write them like documentation for the model.

tools/get-weather.tstypescript
1export const getWeather = {2  name: "get_weather",  // stable, snake_case id3  description:4    "Get the current weather for a city. Use when5     the user asks about conditions or temperature.",6  parameters: {  // JSON Schema7    type: "object",8    properties: {9      city: { type: "string",10        description: "City name, e.g. Tokyo" },11      units: { type: "string",12        enum: ["celsius", "fahrenheit"] },13    },14    required: ["city"],15  },16  async handler({ city, units }) {  // runs in your code17    const data = await fetchForecast(city, units);18    return { tempC: data.temp, sky: data.sky };19  },20};
Name + description tell the model when to call; the JSON-schema parameters tell it how. The handler does the work.

Every tool definition has four parts, and each earns its place:

  • Name — a stable identifier (snake_case is conventional) the model returns when it wants to call the tool.
  • Description — natural-language guidance on when to use it. This is the highest-leverage field: vague descriptions cause the model to skip or misuse the tool.
  • Parameters — a JSON Schema that defines arguments, types, enums, and which are required. The model uses it to generate valid, structured arguments.
  • Handler — your actual function. It runs in your runtime, can call any API or database, and returns a result the model reads on the next turn.

Keep handlers small and return concise, structured output. Treat the name and description as part of the prompt — they are read by the model on every turn, so clarity here directly improves reliability.

The toolbox

Categories of AI agent tools

Most production tools fall into a handful of families. Mix and match the ones your agent's job actually requires — and resist adding tools it will rarely use.

Search & retrieval

Semantic search over a vector store, RAG retrieval, and keyword lookup. Grounds answers in your knowledge base so the agent cites real sources instead of guessing.

Data & databases

Query and update SQL or NoSQL stores, read from a warehouse, or call internal data services. Often read-only by default, with writes gated behind approvals.

Communication

Send email, post to Slack or Teams, open a ticket, or notify a user. Lets the agent close the loop with humans and other systems instead of just thinking.

Code execution

Run code, shell commands, or notebooks in a sandbox. Powerful for data analysis and automation — and the category that most demands isolation and limits.

Web & browser

Fetch URLs, scrape pages, or drive a headless browser to navigate and fill forms. The gateway to the open web — and to untrusted content, so validate aggressively.

Custom APIs

Wrap any REST, GraphQL, or internal service as a tool: payments, CRM, calendars, billing. This is where most real business value lives for an agent.

Retrieval tools deserve special attention — pairing them with agent memory is what lets an agent stay grounded over long tasks. To wire up the rest, the integrations library and tool API reference have ready-made connectors for the most common services.

Standard interfaces

MCP: a universal interface for tools

Model Context Protocol

One protocol, every integration

Without a standard, every agent reinvents the same glue: bespoke auth, bespoke schemas, bespoke result formats for each tool. The Model Context Protocol (MCP) replaces that with one open client–server interface between agents and the systems they use.

An MCP server exposes tools, data resources, and prompts; any MCP-compatible agent connects, discovers what's available, and calls it — no custom code per integration. The same GitHub, Postgres, or filesystem server works across different agents and frameworks.

  • Tool discovery — agents list available tools at runtime
  • Uniform transport for tools, resources, and prompts
  • Decouples the agent from any single integration
  • Reusable servers shared across teams and frameworks
See available integrations
Agent (MCP client)
Reasoning modelTool selectionLoop
MCP protocol
DiscoveryTool callsResourcesPrompts
MCP servers
GitHubPostgresSlackFilesystem
Systems & data
APIsDatabasesSaaS apps
MCP sits between the agent and your systems, turning many bespoke integrations into one uniform interface.
Guardrails

Tool safety & permissions

Every tool you grant is a new way for an agent to cause harm — accidentally or via prompt injection. Treat the permission model as a first-class part of the design.

Tools are an attack surface

An autonomous agent that can run code, hit your database, and read untrusted web content is one well-crafted prompt injection away from a bad day. The risk is rarely a single tool — it's an unscoped tool combined with adversarial input. Never grant broad write access "to be safe." Grant the minimum, require approval for anything irreversible, and assume any content the agent reads may be hostile.

  • Least-privilege scopingGive each tool the narrowest credentials and permissions it needs — read-only by default, no wildcard scopes.
  • Human-in-the-loop approvalsGate irreversible or high-impact actions (payments, deletes, emails) behind explicit confirmation.
  • Sandboxing & isolationRun code execution and browser tools in disposable, network-restricted sandboxes with CPU and memory limits.
  • Argument validationValidate every argument against the JSON schema and your own rules before the handler runs.
  • Rate limits & budgetsCap calls per run, set spend ceilings, and add timeouts so a looping agent can't run away.
  • Audit loggingTrace every tool call, its arguments, and its result so you can debug, replay, and prove what happened.
5–15

Tools per agent

focused beats sprawling

100%

Calls logged

for audit & replay

0

Wildcard scopes

least privilege only

2x

Approval gate

on irreversible actions

FAQ

AI agent tools, answered

AI agent tools are functions an agent can call to act on the world beyond generating text — searching a knowledge base, querying a database, sending a message, running code, or hitting any API. Each tool has a name, a description, and a typed parameter schema (usually JSON Schema) so the model knows when and how to invoke it. Tool use is what turns a language model from something that only talks into something that gets work done.

Get started

Give your agent the right tools

Connect data, code, and APIs with safe, scoped tool use — and ship an agent that actually gets work done. Free to start, no credit card required.