What is function calling? (how your AI actually uses tools)

What it actually is

Function calling is the mechanism that lets an AI model use tools. A language model can only produce text. So when it needs something done in the world (reading a file, hitting an API, checking the weather), it produces a special kind of output: a structured request that names a tool and fills in the arguments. Something like “call get_weather with location: San Francisco”. The app hosting the model (Claude Code, Cursor, your own script) reads that request, runs the tool for real, and feeds the result back as a new message. The model reads the result and decides its next move. That request, execute, return cycle repeats until the job is done.

Think of an order ticket in a restaurant. The waiter never cooks. They write down exactly what table 4 wants, hand the ticket to the kitchen, and the kitchen sends the dish out. Your AI is the waiter, the tools are the kitchen, and the host app carries the tickets. The model’s entire ability to act comes down to writing precise tickets.

The name varies by vendor, which causes real confusion. OpenAI’s docs say “function calling (also known as tool calling)”. Anthropic’s docs call the same loop tool use. Same mechanism everywhere: the model emits a structured call, something outside the model executes it, and the result flows back in.

Why your AI just did this

Every coding agent is built on this loop. When Claude Code reads a file, edits it, or runs npm test, the sequence underneath is the same: the model emitted a tool call (Read, Edit, Bash) with arguments, the Claude Code app executed it on your machine, and the output went back into the conversation as a result message. One prompt from you can trigger dozens of these cycles, and that chain is what agentic coding means in practice.

It is also why permission prompts exist. By the time Claude Code asks you to approve a command, the model has already written the ticket. The app pauses before executing it and checks with you. The prompt can show you the exact command because that string sits in the tool call’s arguments, waiting to run.

One detail worth knowing: some tools run on the provider’s servers instead of your machine (Anthropic’s web search, for example). Even then, the model only writes the request. Execution always happens somewhere outside the model.

When you’ll run into it

The visible version is your agent’s transcript. Claude Code shows each tool call as it happens: the tool name, the arguments, then the result. Cursor’s agent runs on the same kind of toolbox; its docs list read files, edit files, and run shell commands among its tools. When your agent seems to pause mid-answer, it is usually waiting on a tool to finish.

The raw version appears if you build with a model API yourself. In Anthropic’s API, the response comes back with stop_reason: "tool_use" and a tool_use block carrying the tool’s name and input. Your code executes the call and replies with a tool_result block. You define each tool up front with a name, a description, and a JSON schema for its arguments.

You will also meet it through MCP. Connecting an MCP server (for Supabase, GitHub, a search engine) hands your agent a catalog of ready-made tools. The plumbing underneath each one is still function calling.

And it shows up on your bill. Tool definitions, tool calls, and tool results all count as tokens. A tool that returns a giant JSON blob from an API endpoint gets resent as input on every following turn, and the cost quietly compounds.

What to check

• Read the tool name and arguments in every permission prompt before approving; the string on screen is exactly what the app will execute
• Look at the actual tool result when something seems off, rather than the model’s summary of it; agents sometimes report a step as done when the result carried an error
• Keep tool results small if you build your own agent, since each result is resent as input tokens on later turns
• Write tool descriptions that spell out when the tool should be called; the model picks tools by reading those descriptions
• Treat anything a tool returns as untrusted input; a fetched web page can contain instructions aimed at your agent, which is the setup for prompt injection

Say it like a dev

Instead of: “my AI ran a command on my computer by itself” Say: “The model emitted a Bash tool call and Claude Code executed it. Can we require approval for Bash and auto-allow read-only tools?”

Instead of: “it says it checked the file but I think it’s lying” Say: “Show me the tool_result from the Read call. Did it return an error or empty content?”

Instead of: “can we just give the AI access to our database” Say: “Let’s expose one query tool with a strict input schema, so the model sends structured requests and our code executes them with limited permissions.”