What Is Function Calling?

What Is Function Calling?

Function calling is the OpenAI-style mechanism that lets a language model emit a strict JSON object naming a function and its arguments for runtime execution. The model receives each function’s JSON Schema in the request, and the response is constrained to a matching JSON payload. OpenAI’s tools parameter popularized the pattern; Anthropic, Google, and most modern model APIs now ship equivalents. Function calling is one implementation of broader tool-calling. In a FutureAGI trace, each call appears as a span with the function name, validated arguments, and returned result.

Why Function Calling Matters in Production LLM and Agent Systems

Function calling is the boundary between LLM creativity and deterministic execution. The model decides what to do; the function decides how. When that boundary is clean, agents are reliable. When it’s not, you get the canonical 2026 production bugs: argument names that almost match but don’t, types that almost match but don’t ("42" instead of 42), nested fields that go missing under load, and enum values the model invented that the function rejects.

Different roles see different surfaces. A backend engineer sees 422 errors on a downstream service because the LLM produced customer_id as a string when the API expects an int. An SRE watches retry storms after the model started emitting an extra unexpected field that the schema rejects. A QA engineer sees agent demos pass on Monday and fail on Friday because the model’s argument distribution shifted across deploys. A product reviewer signs off on a payment-handling function only to find the agent occasionally skips the confirmation_required field.

In 2026, structured-output and JSON-Schema-constrained decoding have made function calling much more reliable than it was in 2023 — but not perfect. Models still hallucinate function names, swap argument orders on function variants, and fail JSON Schema’s stricter constraints (regex patterns, enum membership, conditional if/then clauses). Production systems need explicit validation and explicit evaluation, not vibes.

How FutureAGI Handles Function Calling

FutureAGI’s approach is to evaluate function calls at three layers: schema validity, argument accuracy, and end-to-end intent. The traceAI integrations — traceAI-openai, traceAI-anthropic, traceAI-google-genai, traceAI-vertexai, traceAI-bedrock, traceAI-openai-agents, traceAI-langchain — capture every function-call attempt as an OpenTelemetry span with the function name, raw arguments JSON, parsed arguments, and validation outcome. Each span carries agent.trajectory.step so the call sits inside the broader trajectory.

On the eval side, three classes cover the surface. JSONValidation returns a boolean check against the function’s JSON Schema — surfaces invalid-JSON rate and schema-violation rate immediately. FunctionCallAccuracy is the comprehensive evaluator: name match, argument structure, type compliance, and semantic correctness against the user’s intent. Unlike JSON Schema validation alone, FunctionCallAccuracy checks whether the model chose the right function and values, not just whether the payload parses. EvaluateFunctionCalling is the cloud-template equivalent for online evaluation against live traces. Used together, they tell you whether failure is “model produced bad JSON” (rare in 2026), “model produced valid JSON with wrong values” (the common case), or “model picked the wrong function entirely” (a tool-selection bug).

Concretely: a fintech agent calls a transfer_funds(from_account, to_account, amount, currency) function. After a prompt change, JSONValidation stays at 100% — the JSON is always well-formed — but FunctionCallAccuracy drops from 0.94 to 0.79. Drilling in, FutureAGI shows the model is now occasionally swapping from_account and to_account on cross-currency transfers. The team rolls back the prompt edit and adds an EvaluateFunctionCalling regression eval to catch this on every future change. Without separating schema validity from argument accuracy, the team would have seen “function calls look fine” while sending money the wrong way.

How to Measure or Detect Function Calling

Function calling has three independent failure modes — instrument each:

• JSONValidation: returns a boolean for schema conformance against a JSON Schema; catches invalid JSON and structural violations.
• FunctionCallAccuracy: returns 0–1 for comprehensive function-call quality (name, structure, types, semantics).
• EvaluateFunctionCalling: cloud-template eval for live trace assessment.
• SchemaCompliance: returns 0–1 for structured-output schema compliance with optional partial credit.
• schema-violation rate (dashboard signal): % of function calls that fail JSON Schema validation per function name.
• agent.trajectory.step (OTel attribute): paired with span kind = function-call, gives per-function slicing.

Minimal Python:

from fi.evals import FunctionCallAccuracy, JSONValidation

func_acc = FunctionCallAccuracy().evaluate(
    input=user_query,
    output=model_function_call,
    expected=ground_truth_call,
)
print(func_acc.score, func_acc.reason)

Common mistakes

• Conflating function calling with tool calling. Function calling is one implementation; tool calling covers retrievers, code execution, sub-agents, MCP. Plan and evaluate both.
• Schema validation as the only check. Valid JSON with wrong values still ships bugs to production; pair JSONValidation with FunctionCallAccuracy.
• No per-function dashboards. Aggregate accuracy hides which one function is regressing; slice by name.
• Letting models invent function names. Without structured-output mode or function-name enums, the model occasionally hallucinates names — guard explicitly.
• Ignoring argument-order swaps on similar functions. Pair-named functions (from/to, source/target) regularly get swapped — add semantic evals, not just structural ones.