A language model on its own knows neither today's stock levels nor free slots in the calendar. With function calling, it can request this information specifically: the application describes to the model which functions exist, and the model decides when it needs one of them and with which values. This turns a text generator into a building block that works together with databases, line-of-business applications, and APIs. Function calling is the technical foundation for AI agents and for standards such as the Model Context Protocol.
How does function calling work?
Using Anthropic's documentation for Claude as an example, a call proceeds in five steps:
- Describe the tool: The application passes a name, description, and an input schema in JSON Schema format, for example for a function "query order status" with the required field order number.
- The model decides: Based on the request and the description, the model decides whether it needs the tool. If so, it returns a structured call with the arguments.
- Execution by the application: Your own software checks the arguments, calls the real function, and receives a result.
- Return the result: The application sends the result to the model as a tool result.
- Answer: On this basis, the model formulates the answer or calls the next tool.
Anthropic distinguishes between tools that run in your own application and server tools such as web search or code execution, which the provider executes itself. A setting can force a specific tool to be used. A strict mode ensures that calls match the stored schema exactly. Other providers use similar methods under the name function calling.
Typical use cases
- A customer service assistant queries the order status in the inventory management system instead of guessing it.
- An internal assistant suggests free time slots and creates a meeting after confirmation.
- An application extracts invoice data from incoming emails and passes it to accounting as structured fields.
- An agent collects device data for a ticket, searches for similar cases, and drafts a proposed solution.
Risks
- Too much freedom to act: The OWASP Top 10 for LLM applications list "excessive agency" as a separate risk. According to OWASP, the causes are too many functions, overly broad permissions, or too much autonomy.
- Unchecked output: The arguments of a call come from the model and must be treated like user input. If they are passed into database queries or commands without checks, classic vulnerabilities arise.
- Manipulation via results: Tool results such as web pages or emails can contain hidden instructions, see prompt injection.
- Costs and loops: Every tool description and every result consumes tokens. Without limits, agents can get stuck in loops.
How companies implement function calling securely
- Few, narrowly scoped tools: Prefer "read order status" to general database access. Avoid open-ended tools such as arbitrary shell commands.
- The user's rights instead of a master key: Run tools in the context of the signed-in person and assign rights according to least privilege, read-only at first.
- Approval before impact: Execute actions that write, delete, or send only after confirmation by a person, see human in the loop.
- Checks in the application: Validate arguments against the schema and business rules, use parameterized queries, and check permissions on the server side, not in the prompt.
- Limits and logging: Limit the number of calls, runtime, and costs, and log every call with its arguments and result.
- Precise descriptions: A clear tool description largely determines whether the model uses the tool correctly. Verify this with fixed test cases.
How it differs
An API is a system's interface; function calling is the model's ability to address it specifically. The Model Context Protocol standardizes how tools are provided to many AI applications at once. Robotic process automation follows hard-coded workflows, whereas with function calling the model decides on the next step.