Tool Calling / Function Calling

This is the framing post for tool calling, and the cover names the gap it closes: a language model, on its own, cannot reach the real world. It can't see today's weather, query your database, or send an email — it can only produce text. Tool calling is the bridge from that text to real action.

The headline frames tool calling as how an LLM 'reaches the real world' deliberately, because the entire mental shift is realizing the model stops being a closed box that only emits prose and becomes a component that can ask your software to do things on its behalf.

Tool calling is best defined by the contract it sets up between you and the model. You describe a set of functions — each with a name and a schema for its arguments. When the model decides one of them would help, it doesn't answer in prose; it returns structured JSON naming the tool and the arguments to use. Your code executes the real function and hands the result back.

The key phrase is 'the model decides; your code acts.' This division of labor is the foundation for everything else in the post. The model brings the judgment about what to call; your runtime brings the actual capability to do it.

This slide isolates the single most misunderstood point about tool calling: the model never runs your function. It only emits an intent — a structured request that says 'I would like get_weather called with these arguments.' Nothing happens until your code chooses to act on that request.

That boundary is not a technicality; it's the entire safety and control story. Because execution lives in your code, you decide what's actually allowed to run, you can validate every argument first, and you can refuse or gate any call. The model proposes; your code disposes. Every later post leans on this distinction.

This comparison contrasts plain text generation with tool calling so the difference is concrete. A plain generation guesses an answer from the model's frozen memory, can't reach live data, has no way to check itself, and produces prose. Tool calling instead asks your code to act, reaches APIs, databases, and files, grounds the answer in real results, and produces structured JSON.

The practical reading is that tool calling isn't a smarter model — it's the same model given a structured way to ask for help. You can add it to almost any capable LLM without retraining, which is why it spread across every provider so quickly.

Naming the three moving parts gives the reader a durable schema for the whole topic. The schema is how you describe each tool to the model. The call is the structured request the model emits when it wants that tool. The result is what your code produces by running the real function and feeds back.

This three-part breakdown is worth memorizing because every tool-calling interaction, in every SDK, is some arrangement of these three pieces. When you later read about 'function definitions,' 'tool_use blocks,' or 'tool result messages,' you can map them straight back to schema, call, and result.

The flow diagram lays out the four handoffs in order so the reader sees tool calling as a relay, not a single event. You define the tool schemas. The model emits a tool call. Your code runs the function. The model answers using the result. The two 'Model' nodes at the start and end make visible that the model is involved twice — once to decide, once to answer.

Seeing it as a left-to-right flow reinforces that there are two distinct systems cooperating: the model, which only ever produces text and structured requests, and your code, which does everything that actually touches the world.

This slide explains why the output being structured matters so much. A tool call is not a sentence like 'maybe check the weather in Tokyo' — it's JSON that conforms to the schema you provided. That structure is precisely what makes it executable: your code can parse it deterministically, validate that the types are right, and call the real function with confidence.

The contrast worth holding onto is with the old, fragile approach of asking a model to 'please reply in JSON' inside prose and then scraping it out. Tool calling makes the structured output a first-class, schema-validated part of the protocol rather than something you hope the model remembers to do.

This first code slide shows the literal shape of a tool call so the abstraction becomes concrete. When tools are available and the model decides one fits, it returns an object with a name and an arguments map instead of prose. Your code parses that object and invokes the matching real function with those arguments.

The slide is intentionally minimal and not tied to one SDK, because the point is the shape, not the API surface. Every provider wraps this same idea in slightly different field names, but underneath it's always: a name, some arguments, and your code turning that into a real function call. Post 4 turns this exact shape into runnable code.

This slide untangles vocabulary that trips people up. A function is the actual code that runs. A tool is that function once it's exposed to the model, together with the schema describing it. An API is frequently what the tool calls under the hood — many tools are thin wrappers around an HTTP API. And crucially, 'tool calling' and 'function calling' are two names for the exact same feature.

Clearing this up early prevents confusion later, when different providers and articles use the terms interchangeably. OpenAI historically said 'function calling,' Anthropic says 'tool use,' and the wider community says 'tool calling' — but they all describe this one mechanism.

The mental-model slide compresses the post into rules to keep. The model proposes and your code disposes — the model only ever asks. A tool is a function plus a schema describing it. Calls are JSON rather than prose, which is exactly what makes them runnable. And tools give the model reach beyond whatever was in its training data.

That last point is the bridge to post 2. Everything powerful about tool calling — fresh data, real actions, structured output — flows from the model being able to reach past its frozen knowledge and ask your systems to act, which is precisely the 'why it matters' the next post unpacks.

The CTA closes the concept post and points to motivation. We've established what tool calling is, that it's a request rather than an execution, the three moving parts, the contrast with plain generation, and the vocabulary.

Day 78's teaser asks the natural follow-up: if tool calling is just the model asking your code to run a function, why was it such a turning point? Post 2 answers by showing the three hard problems it solves at once — stale knowledge, lack of agency, and messy output — and why nearly every modern AI system is built on top of it.