What Is Function Calling / Tool Use?

Function calling is the bridge from text-generation to action. The model decides which function to call, with which arguments, and your code executes it. Once you see this loop, agents stop being mysterious.

The core idea

Function calling lets the model emit a structured request to invoke an external function, instead of just emitting text. You define the available functions; the model picks one (or none) and produces the arguments; your code executes the call and returns the result; the model continues with the result in context.

Concretely, instead of the model saying “I’ll search for that for you,” it emits something like:

{"name": "search_database", "arguments": {"query": "open incidents", "limit": 10}}

Your code recognises this as a tool call, runs the function, and feeds the result back into the conversation. The model sees the result and writes a response based on it.

How the model decides to call a tool

Behind the scenes, function calling is still next-token prediction. The model has been fine-tuned to recognise contexts where a tool call is expected, and to emit the JSON schema-conforming output structure when it should call.

The decision happens at the model’s end. Three things influence it:

• Tool descriptions: each tool has a description that tells the model when to use it. Vague descriptions = unreliable calling.
• The user’s message: clear action verbs (“find”, “create”, “send”) trigger tool calling more reliably than vague requests.
• The system prompt: explicit guidance like “always check the database before answering questions about pricing” nudges the model toward using a tool when it should.

Schema definitions: the part you write

For each tool you expose, you provide:

• Name: snake_case verb-noun. “search_documents”, “send_email”, “create_ticket”.
• Description: when to use, what it does. Keep it under 200 characters and concrete.
• Parameters: a JSON schema with each parameter, its type, description, and whether it’s required.

Example for a search tool:

{
 "name": "search_runbooks",
 "description": "Search SRE runbooks by keyword. Use when an incident requires a known mitigation.",
 "parameters": {
 "type": "object",
 "properties": {
 "query": {"type": "string", "description": "Free-text query"},
 "service": {"type": "string", "description": "Optional service filter"}
 },
 "required": ["query"]
 }
}

The descriptions matter. The model can’t see your code; it can only see what you wrote in the schema. Treat tool schemas like API documentation aimed at a smart-but-impatient junior engineer.

Multi-step tool chains

A single tool call is rare in production. The interesting workflows chain tools.

Example: “Why is the API slow?”

1. Model calls get_recent_metrics(service="api") → returns elevated latency.
2. Model sees the result, calls get_recent_deploys(service="api", hours=2) → returns a deploy 30 minutes ago.
3. Model calls get_deploy_diff(deploy_id="...") → returns the changed files.
4. Model writes the answer with all three pieces of context.

This loop, tool call, observe, tool call, observe, is the heart of every agent. The model is doing planning under the hood: each step’s decision depends on the previous step’s output.

Four common mistakes

1. Too many tools. Above 20 tools, model accuracy drops. The model has to pick from a longer list and the descriptions blur. Group related tools or use a router.
2. Vague descriptions. “Helps with database stuff” is useless. “Run a read-only SQL query against the production analytics warehouse. Use for ad-hoc data questions, never for live customer queries” is useful.
3. No error handling. Tools fail. Network blips, timeouts, validation errors. Return a structured error to the model so it can react (“the search timed out, try a narrower query”) rather than crashing the conversation.
4. Forgetting to return the result. The model emits the tool call; your code runs it; you must put the result back into the conversation as a tool-result message. Skip this and the model thinks the call hangs.

Where this is heading: Model Context Protocol

The Model Context Protocol (MCP), introduced by Anthropic in late 2024, is becoming a standard for exposing tools to models. Instead of every framework reinventing tool definitions, you describe a tool once in MCP format and any compatible model can use it.

For developers, this means:

• Tool definitions become portable across model providers.
• Public servers expose useful tools (filesystem, databases, GitHub, browser) that you connect to instead of writing.
• Auth and permission scoping have a standard shape.

By the end of 2025, most agent frameworks will speak MCP. Building tools to that interface today saves a migration tomorrow.