What is function calling?
Function calling is the mechanism by which a model emits a structured request matching a signature declared to it in advance. The declaration names each parameter and the type it accepts, and the model returns arguments conforming to that shape. It is the implementation layer beneath tool calling, which is the same idea described from the agent's side.
Also called: Tool calling
Why a declared signature is the boundary of what a model may do
Function calling looks like plumbing until the first function writes to a system of record. At that point the signature is the only thing standing between a model's interpretation of a request and an irreversible change, because whatever the schema permits will eventually be attempted. Teams discover this through an argument the validator accepted and the downstream system could not, usually at the point where the transaction is half complete. The discipline is to treat the declaration as a contract and to place validation on the receiving side rather than trust in the caller.
- The schema is the enforceable limit on what the model can request.
- A permissive type lets an interpretation reach a system of record unchecked.
- Validation belongs on the receiving side, since the caller cannot be trusted.
- Declared functions are enumerable, so the capability surface is reviewable.
How function calling works
- Each available function is declared with a typed schema and a description.
- The model returns a function name together with arguments as structured data.
- Arguments are validated against the schema before any execution is attempted.
- Write operations require a confirmation step and an idempotency key.
- The result is returned to the model, including any validation failure.
- Every call is recorded with its arguments and its outcome.
How function calling is evaluated
Function calling is assessed on whether the right function was chosen and whether its arguments were correct. Measure the following on production traffic:
- accuracy of function selection against a labelled set of requests
- rate of arguments failing schema validation
- frequency of a required parameter omitted or invented
- duplicate executions detected per idempotency key
- proportion of calls with a complete record of arguments and outcome
Limitations, risks and common failure modes
- Loosely typed parameters accept a value the downstream system rejects.
- Descriptions written for humans are ambiguous to the model selecting between them.
- A retry after a timeout executes the same write a second time.
- Too many declared functions degrade selection accuracy across all of them.
- Arguments containing personal data are written into logs without redaction.