What is Function Calling?

Function Calling is a model interface that returns a structured proposal naming a tool and its arguments; an application or provider runtime must still decide whether and how to execute it.

Quick Facts

Full NameLLM Function Calling
Created2023 by OpenAI
SpecificationOfficial Specification

How It Works

Request, execute, and return loop

The application sends user context plus a selected tool catalog. The model returns a tool name, call ID, and arguments; the runtime resolves the registered implementation, validates the request, executes it, and returns a result tied to the same call ID. The model may then answer or request another tool. Preserve ordered assistant calls and tool results because providers use different wire formats even though the control loop is similar.

What a schema guarantees

A JSON Schema can constrain types, required fields, enums, ranges, nesting, and extra properties. Strict provider modes can improve conformance to the supported schema subset. They do not prove that an order belongs to the caller, a date is operationally available, a quoted price is current, or the requested effect is permitted. Run application validation after parsing and derive identity, tenant, roles, and policy from trusted runtime context rather than model arguments.

Authorization and side effects

Expose narrow business operations instead of generic shell, SQL, or arbitrary HTTP tools. Authorize the exact resource and effect immediately before execution. Consequential writes need preview or confirmation, an idempotency key, timeout, audit record, and an unknown-outcome reconciliation path. Parallel calls are safe only when their dependencies and effects are independent; a model returning calls together is not a concurrency guarantee.

Evaluation and observability

Measure tool selection, argument validity, missing-information behavior, authorization denials, result grounding, stop decisions, repeated calls, latency, cost, and final task success on representative trajectories. Log the model and tool-set version, call ID, decision outcome, duration, normalized error class, and redacted result metadata. Treat tool output as untrusted content because retrieved text can redirect later model behavior.

Key Characteristics

  • Returns structured tool proposals rather than directly executing application code
  • Uses names, descriptions, and schemas to expose a bounded capability catalog
  • Requires a runtime-owned request, execution, result, and continuation loop
  • Separates structural validation from identity, authorization, and business validation
  • Needs idempotency, confirmation, deadlines, and reconciliation for side effects
  • Supports trajectory-level testing of selection, arguments, results, and termination

Common Use Cases

  1. Reading current account, inventory, weather, or search data through scoped services
  2. Previewing and confirming refunds, bookings, messages, or other consequential writes
  3. Producing typed arguments for application-owned workflow steps
  4. Connecting an agent runtime to provider-native, custom, or MCP-backed tools
  5. Evaluating tool selection and argument construction with recorded test cases

Example

loading...
Loading code...

Frequently Asked Questions

Does function calling execute a function inside the model?

Usually no. For a client-defined tool, the model emits a structured request and the application decides whether to run it. Some providers also offer server-executed tools, but execution still occurs in a provider runtime rather than inside the language model. Keep the execution owner explicit because it determines credentials, policy, logging, and failure handling.

Does strict schema conformance make a tool call safe?

No. A strict schema can reject malformed shapes and unsupported values within the provider's supported subset. It cannot prove ownership, consent, current business state, semantic truth, or authorization. The runtime must validate those properties with trusted context and the authoritative system immediately before execution.

How is function calling different from structured output and MCP?

Structured output constrains a model response to a data shape and does not imply an executable operation. Function calling represents a model-facing request to use a named capability. MCP standardizes discovery and invocation of remote tools and resources. An application can expose an MCP tool through function calling, but it still owns policy and execution.

When can multiple tool calls run in parallel?

Run calls concurrently only when they are independent and their reads, writes, quotas, and ordering do not conflict. Calls that share mutable state, depend on earlier output, consume limited capacity, or have side effects need deterministic scheduling. Preserve every call ID so results cannot be attached to the wrong request.

How should function calling be evaluated in production?

Use representative complete tasks and score tool selection, argument correctness, clarification when fields are missing, authorization behavior, final outcome, repeated calls, stop decisions, latency, and cost. Include invalid, adversarial, stale-state, timeout, partial-failure, and unknown-write-outcome cases; schema-valid happy paths alone are insufficient.

Related Tools

Related Terms

Related Articles