What Is Function Calling? – Definition and How It Works

Learn what function calling is, how a model requests a tool, why the application executes it, and how to write schemas a model actually uses correctly.

Function calling lets a language model ask your application to run something. The model never executes anything itself — it emits a structured request naming a function and its arguments, and your code decides what to do with it. The same capability is often labelled tool calling; the terms are used interchangeably.

1. What Is Function Calling?

Function calling is a protocol for turning model output into a typed request rather than prose.

• Key idea: the model chooses what should happen; the application controls whether and how it happens.
• Mechanism: you supply function schemas; the model returns a name and a JSON argument object matching one of them.
• Goal: connect a text model to real capabilities — search, databases, calculations, actions.

Example of a Schema

{
  "name": "search_web",
  "description": "Search the live web and return ranked results. Use for anything time-sensitive.",
  "parameters": {
    "type": "object",
    "properties": {
      "query":     { "type": "string", "description": "The search query" },
      "max_results": { "type": "integer", "minimum": 1, "maximum": 20, "default": 10 }
    },
    "required": ["query"]
  }
}

2. How the Loop Works

1. The application sends the user's message together with the available function schemas.
2. The model replies either with text, or with a call: search_web({"query": "..."}).
3. The application validates the arguments and executes the function — this is the step the model cannot perform.
4. The result is appended to the conversation as a tool message.
5. The model reads the result and either answers or calls another function.

The loop repeats until the model produces a final answer or a limit is reached. Everything crossing that boundary is ordinary application code, subject to ordinary authorisation checks.

3. Why the Application Executes, Not the Model

This separation is a security boundary, not an implementation detail.

• The model may be influenced by untrusted content it has read, including retrieved web pages.
• A requested call is a suggestion; the application decides whether the current user is allowed to make it.
• Arguments must be validated against the schema before use, exactly as with any external input.

Treating a model's function call as pre-authorised is the most common serious mistake in agent design.

4. Writing Schemas Models Use Well

5. Limits Worth Knowing

• Selection is probabilistic. A model can call the wrong function, or answer from memory when it should have called one. Deterministic steps belong in code, not in a prompt.
• Arguments can be malformed. Schema validation is mandatory; so is a clear error path back to the model.
• Loops happen. Cap the number of iterations per request.
• Every call costs context. Definitions and results both consume the window.

6. Real-World Examples

• Live data lookup — an assistant calls a search function for anything time-sensitive rather than answering from training data.
• Structured extraction — a single function with a strict schema turns a messy page into typed fields, with validation rejecting bad output.
• Database queries — the model proposes parameters; the application runs a parameterised query it controls, never raw SQL from the model.
• Multi-step workflows — search, then fetch a specific result, then summarise, each step a separate call the application can log and authorise.

7. Common Misconceptions

• "The model runs the function." It emits a request. Execution, authorisation, and validation are entirely the application's job.
• "A returned call is safe to execute." It may be influenced by untrusted content the model has read; treat arguments as hostile input.
• "More tools make the model more capable." Selection accuracy falls as the catalogue grows, and every schema consumes context.
• "Failed calls mean a weak model." Vague descriptions and loose schemas cause most misfires; the fix is usually in the tool definition.

8. Summary

Function calling converts a text model into a component that can request actions in typed form, while leaving execution, authorisation, and validation in your application. It is the mechanism behind essentially every practical agent.

Design it as an API boundary rather than a prompting trick: clear descriptions, tight schemas, validated arguments, scoped permissions, and a capped loop.

Potential Related Glossary

• Data Structure
• Parsing
• Web Crawling
• Unstructured Data