LLM Function Calling Explained: Schemas and Permissions

LLM function calling is explained by the boundary between a structured request and an authorized action. A model can request a refund through a tool without having the authority to approve that refund. Function calling gives an application a structured request to interpret, while the application remains responsible for deciding whether and how the operation runs.

OpenAI’s function-calling documentation describes a loop between model requests, application execution and tool results. That loop is the useful starting point for separating generated arguments from a completed business operation.

The model proposes the call

A function definition describes the tool’s name, purpose and accepted inputs. For function tools, those inputs use a JSON schema. The application supplies the definitions with the model request so the model can select a tool and produce arguments.

The response can contain a tool call rather than a final answer. At that point, the application has a proposed operation. It has not acquired evidence that the operation succeeded.

For example, an account lookup tool might take an account identifier. The model can select the identifier from the conversation, but the application’s access checks must decide whether the current user can retrieve that account.

Execution is an application responsibility

The documented flow has five stages: send the model available tools, receive a tool call, execute the corresponding application code, send the result back, then receive the model’s next response or further calls.

OpenAI uses a call identifier to associate a returned result with its request. That association matters when a response contains multiple calls. A correct result attached to the wrong request can still give the model a misleading basis for its answer.

This is a mechanism, not a guarantee of end-to-end correctness. The application should retain the actual operation result rather than using the wording of the final answer as its system of record.

Schema conformity and permission are different checks

The guide describes strict mode for making function arguments conform to their schema. Its documented requirements include declaring all properties required and using additionalProperties: false for objects, with nullable types where an otherwise optional value is needed.

A matching schema can establish that an argument has the expected structure. It cannot establish that the user owns an account, that a refund falls within policy or that an external service accepted the request.

Those decisions belong in the application. A narrow function can make the boundary easier to review: an account lookup and a refund action need not share the same inputs or permission rule.

Return failures as failures

A tool may return an unavailable record, a rejected operation or a temporary service error. The application should communicate the actual result so the model can explain the constraint or take another allowed step.

Treat a retry as a new execution decision. Repeating a lookup and repeating a money-moving action have different consequences. The model’s desire to complete the task does not itself establish that a failed action is safe to repeat.

OpenAI also allows tool outputs to contain structured data or text. Choose a result that conveys what happened and enough identifying information to connect it to the attempted operation.

Check the full loop

Review the definition, input validation, user authorization, execution result and returned call association together. An integration that validates only the JSON leaves its most consequential decisions elsewhere and potentially unexamined.

The same distinction applies to the interface. “Requested,” “running” and “completed” should reflect the application’s observed state. A generated sentence saying an order was changed is not a substitute for the order service’s confirmation.

For a payment-specific review, see AI agent payment permissions.