Does function calling mean the model runs arbitrary code?

No. In a typical defined-function setup, it requests available operations; the application controls their implementation and execution.

Can one request require several functions?

Yes. A workflow may involve dependent or independent calls, with orchestration and error handling appropriate to the task.

Does a strict input schema guarantee the right answer?

No. It can constrain structure, but the arguments, tool choice, source data, and final interpretation can still be wrong.

AI Glossary / Generative AI and language / Intermediate

Function Calling with LLMs

Definition

Function Calling with LLMs is a way for a language model to request the use of defined software functions through structured outputs. A model identifies a function and supplies arguments that an application can inspect and execute. The result can then be returned to the model for further reasoning or a user-facing answer. Generating a function call is distinct from executing it: the surrounding application or service performs the actual operation.

What it means

An ordinary text response can describe how to check an order without actually checking anything. Function calling connects the conversational system to a defined capability, such as looking up an order or calculating a price. The developer describes the available functions and their expected inputs. The model uses those descriptions to propose an appropriate call. This can make interactions more useful, but the model's proposed arguments still need to match the user's intent, the application's rules, and the real system's state.

How it works

The application supplies function names, descriptions, and input schemas with the conversation. When appropriate, the model returns a structured request containing a function name and arguments. Application code validates the request, checks authorization and business conditions, then invokes the relevant implementation. It sends the result back in the expected tool-result format, linked to the request where the interface requires it. The model can produce an answer or request another tool. Some software development kits automate parts of this loop, but execution remains a distinct system action.

Three practical examples

Order lookup: retrieve the status of an authenticated customer's order and explain the returned status without inventing missing delivery details.
Calculation: pass quantities and approved price inputs to a deterministic calculator, then present the computed total clearly.
Appointment handling: search available times, clarify the selected slot, and invoke a booking operation only when the workflow's authorization and availability conditions are satisfied.

Think of it this way

Think of a receptionist filling out a structured service request for a specialist team. The request identifies the job and relevant details, but the specialist must still check and perform it. The analogy explains the handoff; in software, schemas, permissions, error handling, and transaction behavior need explicit implementation rather than relying on ordinary human judgment.

Worked example

A fictional customer asks for the cost of three items priced at 12 currency units each, with delivery costing five. The application exposes a calculation function accepting quantity, unit_price, and delivery_fee. The model proposes quantity = 3, unit_price = 12, and delivery_fee = 5. After validating the values against approved inputs, the application calculates 3 times 12 plus 5 = 41 and returns the total. The assistant can now explain that the total is 41 under those stated assumptions.
Suppose the user then asks to place the order. Repeating the calculation does not create an order, and a sentence saying “ordered” is not evidence that one exists. A separate order-creation function would need an authorized customer, confirmed items, current availability, and any required workflow checks. Its successful result should include an actual order identifier. If the request times out after submission, the application must determine whether creation already happened before retrying, using a suitable idempotency or status-check mechanism. Otherwise, a plausible retry could create duplicate orders. The example distinguishes correct arithmetic, a proposed call, a completed operation, and evidence of completion.

Illustrative case study

A fictional service desk introduces a function for checking subscription status. Early tests reveal that users sometimes provide an account name shared by several organizations. The team changes the workflow so the model asks for the needed disambiguation and the application uses the authenticated account context. It also tests unknown accounts and service errors. The assistant reports what the lookup actually returned, including uncertainty, instead of treating a well-formed call as proof that the requested record was found.

Common misconceptions and mistakes

Valid JSON is not the same as a valid business action. A schema can require an integer while still allowing the wrong customer's identifier. A function name in prose does not establish that the function ran. Tool results can contain incomplete, stale, or untrusted content, and should not automatically override higher-priority instructions or access controls. Repeated calls are not always harmless. Parallel execution is appropriate only when operations and dependencies permit it, especially for actions that change external state.

Business use

Define narrow, understandable functions with clear inputs, outputs, and failure behavior. Separate read operations from actions that change records or send communications. Enforce permissions in application code rather than relying solely on model wording. Log call identifiers, validated arguments, outcomes, and relevant versions while protecting sensitive data. Evaluate whether the assistant chooses the right tool, supplies correct arguments, handles errors, and accurately reports results. End-to-end task completion matters more than the number of successful-looking calls.

Check your understanding

The model returns a well-formed create_order request, but the application rejects it for insufficient permission. Was the order placed?

Answer: No. A proposed call is not a completed action. The assistant should report the actual failure and follow the authorized workflow rather than claiming success.

Related terms

Orchestration
Agent
Prompt injection
Tool use
function schema
structured output
API
argument validation
authentication
authorization
tool result
idempotency

Learn next

Draw a four-stage flow: model request, application validation, function execution, and returned result. Test a read-only function with valid, missing, ambiguous, and incorrect inputs before considering state-changing operations. Study API error handling and idempotency next, then evaluate the entire conversation to ensure that claims of completion match the system's actual outcomes.

Sources

Google AI for Developers, Function calling with the Gemini API: https://ai.google.dev/gemini-api/docs/function-calling Anthropic, Tool use with Claude: https://platform.claude.com/docs/claude/docs/tool-use

Previous: Function approximator Next: Function transformation