How AI Agents Use Tools: Function Calling Explained

Most function-calling tutorials are wrong about where the difficulty lives. They spend paragraphs on JSON schema syntax — required fields, type enums, nested objects — as if that were the hard part. It isn't. The schema syntax is the easy, mechanical bit. The hard part of AI agent function calling is writing a description clear enough that the model knows when to call the tool and what to put in the arguments. Get the syntax perfect and the description vague, and your agent will still misfire constantly.

Let me explain function calling from the one perspective those tutorials skip: the model's.

What Is AI Agent Function Calling?

Function calling is how a model asks your code to do something it can't do itself. The model can't check a database or hit an API — it can only produce text. Function calling is a convention where, instead of answering, the model emits a structured request — "call get_weather with city=Paris" — and your code runs the real function and hands the result back.

The single most important thing to understand: the model never runs your code. It generates text that describes a call. Your program reads that text, executes the actual function, and returns the output as more text the model can read. Function calling is structured text generation with a handshake, nothing more.

That reframing matters because it explains every failure mode. The model can request a tool that doesn't fit. It can invent an argument. It can call the right tool with wrong values. All of these are the model generating plausible-looking text, because that's the only thing it ever does — the "calling" is your code's job.

Once that clicks, function calling stops feeling magical and starts feeling like what it is: a disciplined way of getting structured requests out of a text generator, with your code as the part that actually acts.

Why It Matters

Function calling is the entire bridge between a model that can only talk and an agent that can act. Without it, you have a chatbot. With it, and a loop, you have an agent. Everything an agent does in the world flows through this one mechanism.

It also relocates where your engineering effort pays off. Because the model decides which tool to call based on the descriptions you write, those descriptions are your control surface. You don't program the model's behavior with code — you shape it with the text of your schemas. This is unfamiliar to engineers used to deterministic function calls, and it's exactly where beginners under-invest.

Here's how unfamiliar it really is. In normal code, if a function misbehaves, you fix the function. In function calling, if the model calls the wrong tool, you often fix the description of a different tool — the one it should have called, or the one it confused this with. Your bug reports point at behavior, but your fixes land in text. Engineers who don't internalize that spend days editing code when the problem was a sentence in a schema.

⚡ Pro tip: Think of tool descriptions as the API you expose to the model. You'd never ship a public API with a two-word doc; don't ship a tool to a model with one either.

How Function Calling Actually Works

Here's a complete tool definition and the flow around it.

schema = {
  ,[object Object],: ,[object Object],,
  ,[object Object],: ,[object Object],
                 ,[object Object],
                 ,[object Object],
                 ,[object Object],,
  ,[object Object],: {
    ,[object Object],: ,[object Object],,
    ,[object Object],: {
      ,[object Object],: {,[object Object],: ,[object Object],,
        ,[object Object],: ,[object Object],}
    },
    ,[object Object],: [,[object Object],]
  }
}

What this does: it tells the model three things it desperately needs — what the tool does, exactly when to reach for it, and when NOT to. The "Do NOT use for refunds" line prevents a whole class of wrong calls. The argument description with a format example ("ORD-12345") cuts down on malformed inputs.

The flow: the model reads the descriptions, decides get_order_status fits the user's question, emits a call with an order_id, your code runs the real lookup, and the result goes back into the model's context. The model then writes the human answer.

When several tools are available, the model reads all their descriptions and picks — which is why one tool's vague description can cause the wrong tool to fire. The model isn't matching keywords; it's making a judgment from the text you wrote. Two tools whose descriptions overlap get confused in proportion to how similar they read, no matter how different their code is.

Concrete stakes make this vivid. A fintech support agent that calls a refund tool when the user only asked about refund policy has now moved money over a misread description. A healthcare intake agent that picks the wrong lookup surfaces the wrong patient's record. A devops agent that chooses "restart service" instead of "check status" turns a question into an outage. In each case the code was fine — the description let the model choose wrong.

⚡ Pro tip: Put a format example directly in each argument's description. "The order ID, format ORD-12345" produces far fewer malformed arguments than "The order ID" alone, because the model copies the shape it sees.

Writing Schemas the Model Respects

The description is where you win or lose, so give it structure. A strong tool description answers four questions: what does this do, when should you use it, when should you not, and what does it return.

The "when not to use it" line is the one almost everyone omits, and it's the highest-value sentence in the whole schema. Models over-call tools that sound broadly relevant. An explicit boundary — "not for forecasts," "not for refunds" — is often the difference between an agent that picks the right tool and one that grabs the nearest plausible one.

Name your tools like you'd name functions in code a colleague has to read: get_order_status, not lookup or helper. And when two tools are similar, make their descriptions name the difference explicitly, because "get_customer" and "get_customer_orders" will get confused unless you say which is which.

A quick before-and-after. Weak: "Search the knowledge base." Strong: "Search internal help articles to answer how-to questions about the product. Use for feature and setup questions. Not for account-specific data or billing — use get_account for those. Returns the top three matching articles." The strong version is longer, and every extra clause is buying you a wrong call you'll never have to debug.

One more schema habit that pays off: mark only the truly required arguments as required, and give optional ones clear descriptions of when to include them. Over-marking fields as required forces the model to invent values it doesn't have, which is a direct cause of hallucinated arguments. If the tool can legitimately run without a field, don't demand it.

⚡ Pro tip: Mark a field required only if the tool genuinely can't run without it. Every over-required field is an invitation for the model to fabricate a value.

⚡ Pro tip: Read your tool set as if you were the model — descriptions only, no code. If you can't tell which tool to use for a given request, the model can't either, and now you know which description to fix.

Common Mistakes

⚠️ Common mistake: Trusting the model's arguments without validating them. The model generates arguments as text, which means it can produce values that are the wrong type, out of range, or entirely made up. Always validate arguments in your code before acting on them, and return a clear error the model can read and correct if they're bad — never pass unvalidated model output straight into a database query or an API that moves money.

A second frequent error is exposing too many tools at once. A model choosing among four sharp tools is reliable; the same model choosing among twenty overlapping ones starts guessing. If you have many tools, group them or expose only the relevant subset per task.

⚡ Pro tip: Cap the number of tools visible to the model at any one time. Somewhere past a handful, accuracy drops as the model struggles to keep the options straight — fewer, sharper tools beat a big catalog every time.

Conclusion

AI agent function calling is structured text generation with a handshake: the model asks, your code acts, the result returns. The schema syntax is trivial; the description is everything, because it's the only thing steering which tool the model picks and what it puts in the arguments. Write descriptions that say what, when, when-not, and what-returns — and validate every argument before you trust it.

Because those descriptions are the real control surface of every agent you build, they're worth managing like the assets they are. PromptABCD lets you store, version, and reuse tool descriptions and schemas across projects, so the get_order_status description you sharpened over three iterations doesn't get rewritten from scratch the next time you need it.