Tool and Function Calling

Tool calling is the mechanism that turns an LLM from a text generator into something that can act: look up an order, query a database, run a calculation, hit an internal API, search the web. Strip away the branding and it is a small, precise protocol — the model is given a menu of named, schema-described capabilities and, instead of executing anything itself, returns a structured request to call one. Your code runs the actual function and feeds the result back in as the next turn's input. Every agent, every RAG-with-actions system, and every "assistant that does things" is built on this loop repeated in a cycle.

The mechanism itself is simple enough to learn in an afternoon. What separates a reliable tool-using system from a flaky one is almost entirely tool design: how narrow each tool is, how clearly its name and parameters are described, what shape its results take, and how failures are surfaced back to the model. Two systems can run the same underlying model and the same orchestration loop and differ wildly in reliability purely because one team wrote manage_data(action, payload) and the other wrote get_order(order_id) and cancel_order(order_id, reason). Interviewers who ask about tool calling are usually testing whether you know this — that the bottleneck on agent reliability is very often tool design, not model capability.

This subject covers the mechanics end to end, the schema-design judgment that interviewers probe hardest, tool-choice modes, parallel calls, error handling, the safety boundary, and a practical Anthropic-vs-OpenAI comparison. It plugs directly into agent-architectures-and-the-agentic-loop (the loop this machinery runs inside), mcp-and-tool-integration-protocols (the protocol-level standardization of "here are my tools" across servers), and case-study-coding-agent (a full worked example of tool set and permission-model design for one concrete agent).

The Mechanics: Definition, Structured Call, Execution, Result

Tool calling is a request-response contract layered on top of an ordinary LLM call. Four steps, repeated:

1. You provide tool definitions alongside the prompt. Each definition has a name, a natural-language description of what it does and when to use it, and a JSON-schema for its parameters (types, required fields, enums, descriptions per field). This is sent as structured metadata with the request — not pasted into the prompt as text.
2. The model decides whether to call a tool, and if so, which one and with what arguments. Critically, the model does not execute anything. It returns a structured object — tool name plus arguments matching the schema — as its response. If it decides text is a sufficient answer, it just replies normally.
3. Your harness executes the call. It parses the arguments (already schema-shaped, but you still validate — see below), runs the actual function, API call, or query, and captures the result or the error.
4. The result is returned to the model as the next turn's input. It gets appended to the conversation as a tool-result message (Anthropic) or a message with the matching tool_call_id (OpenAI), and the model's next generation sees it in context, exactly like it sees anything else you put there. The model then either calls another tool, or produces the final answer.

The point that trips people up in interviews: the model never has execute access to anything. It only ever emits a request shaped like {"name": "get_weather", "arguments": {"city": "Paris"}}. Every safety property of the system — what's allowed, what's rate-limited, what's logged — is a property of step 3, the harness, not of the model's behavior in step 2. This is the loop that agent-architectures-and-the-agentic-loop formalizes as observe → decide → act → observe, with tool calling supplying the "act."