What Is Function Calling?
Function calling is the mechanism by which an application declares typed tools in a request and receives back a structured reply naming one of them with its arguments filled in. The application executes the function. The reply only names it and supplies the arguments.
The round trip
A request carries tool definitions, each with a name, a description and a schema for its parameters — in current implementations, a JSON Schema. The reply contains either ordinary text or one or more tool calls, each a tool name and an argument object. The application validates the arguments, runs the function, and sends the result back in a further request, at which point the exchange continues with that result in context.
Two properties follow from that shape and are worth stating explicitly. Nothing is executed by the provider: a returned tool call is a request made to the application, and an application that runs it without validation has delegated its own authorisation decision to a text field. And each tool's description is read as part of the prompt, which makes tool descriptions prompt engineering rather than documentation.
| Field | What it does |
|---|---|
| Name | The identifier returned in a call. Stable by requirement; renaming it changes the interface. |
| Description | Read as part of the prompt, and the main determinant of when the tool is selected. |
| Parameter schema | The declared shape of the arguments, used for validation when they come back. |
| Required fields | Which parameters must be present; the rest arrive as omissions rather than errors. |
| Returned result | Sent back in a subsequent request, and counted against the context limit. |
The description field is the one most often written as an afterthought and the one that decides selection between two similar tools. It is prompt text with a docstring's appearance.
Validation is the application’s job
A schema declared in a request describes what is wanted, and structured-output modes that constrain generation to it exist in several implementations. Neither removes the need to validate on receipt: an argument can satisfy a schema and still be wrong, and a well-formed identifier for a record the caller has no business reading is schema-valid in every respect.
The rule that follows is the ordinary one for any external input. Validate the arguments, check authorisation against the caller rather than against the request, bound anything expensive, and require more than a name and an argument object before an irreversible operation runs. A tool list is an API surface, reached by a caller whose input can be influenced by whatever happens to be in the context.
How the Registry classifies a tool-definition task
Defining a typed tool schema for an inventory lookup and wiring it into an agent's tool list is filed as a code modification task in this registry's classification: what the task produces is source, and it is committed to a repository like any other change.
The Registry's canonical brief for this entry is filed as:
Define a typed tool schema for an inventory lookup and wire it into an agent tool list.
Submitted for assessment it is
classified as Code modification, and its wording is hashed once — to
5cb4acad17f40c21…, the first sixteen of sixty-four hexadecimal
characters — with the wording itself never stored. The hash is what the derivation
reads.
That class's own page is /tasks/code.
Classification is one of three inputs. The other two are the configuration submitted with the task, and the permanent chart derived from that configuration — fixed by the model name, the training cutoff and the temperature alone, and never reading the task at all. The same ascendant, ruling planet and harmony therefore appear on every assessment a given configuration receives, whatever it was asked to do. The derivation is published in full at /method.
What this page does not claim about function calling
Which implementations support which schema features, and what each one caps, are facts about those implementations and are stated in their own documentation rather than restated here.
The Registry does not run this task, does not inspect any system's output for it, and validates no assessment it issues against what afterwards happens. What it does is compute — from a published method, for one submitted task and one submitted configuration — a verdict and a recommended execution window. It computes neither on this page.
Questions about function calling
- What is function calling?
- Function calling is the mechanism by which an application declares typed tools in a request and receives back a structured reply naming one tool and supplying its arguments. The application validates the arguments and executes the function itself.
- Does the provider execute the function?
- No. The reply names a tool and supplies arguments; execution happens in the application. That boundary is also where authorisation belongs, since a returned call is a request rather than an instruction the application is obliged to carry out.
- What is the difference between function calling and structured output?
- Structured output constrains a reply to a schema. Function calling uses that capability to name a tool and supply its arguments, and adds the round trip in which the application returns the result. The first is a formatting guarantee; the second is a protocol.
- How many tools can be declared in one request?
- In practice the limit is the context: every definition is sent with every request, so a long list is a permanent cost. Selection degrades too, since with many similar tools the description field carries more of the decision. Implementations also impose their own caps, stated in their own documentation.
Related entries
Order an assessment for code modification tasks
The Registry issues a permanent, numbered task risk assessment for one submitted task and one submitted configuration. EUR 1.90 Standard, EUR 4.90 Extended, EUR 14.90 Full Chart, which adds the permanent chart. Assessments from EUR 1.90; machine-readable at /pricing.json.