Function calling — sometimes called tool use — is the process by which a language model signals that it wants to invoke an external capability rather than answer with text alone. The model does not execute code itself. Instead, it emits a structured object that specifies: which function to call, and what arguments to pass. The surrounding application reads that object, runs the real function, and feeds the result back into the conversation.

This creates a precise division of labor. The model handles natural-language understanding and decision-making. The application handles execution. Neither side needs to trust the other with tasks it cannot safely perform.

The flow looks like this: the developer registers available tools by passing their schemas in the API request. When the model decides a tool is needed, it returns a special response type rather than a text completion. The application detects this, runs the tool, appends the result to the conversation history as a tool-role message, and calls the model again. The model then generates a natural-language response informed by the tool result.

Before structured function calling, the dominant pattern was prompt engineering: tell the model to respond in JSON, then parse the output. This broke in production for several interconnected reasons.

• Models would add prose before or after the JSON block, breaking parsers.
• Field names varied across rephrasings — search_query vs query vs q.
• Numeric types arrived as strings; required fields were omitted; enum values were hallucinated.
• Error handling required the application to re-prompt the model and hope for valid output on retry.
• There was no native signal distinguishing "I want to call a tool" from "here is my answer."

Schema-enforced function calling solves all of these by moving structural guarantees into the model's constrained decoding layer. The model is trained — and at inference time, constrained — to emit output that validates against the declared schema. The application no longer needs to guess what the model meant.

A minimal function call interaction has four distinct message types in the conversation history. Understanding each is essential for debugging agentic systems.

{
  "role": "user",
  "content": "What is the weather in Tokyo right now?"
}

// Model emits:
{
  "role": "assistant",
  "tool_calls": [{
    "id": "call_abc123",
    "type": "function",
    "function": {
      "name": "get_current_weather",
      "arguments": "{\"location\": \"Tokyo\", \"unit\": \"celsius\"}"
    }
  }]
}

// Application executes, then appends:
{
  "role": "tool",
  "tool_call_id": "call_abc123",
  "content": "{\"temperature\": 24, \"condition\": \"partly cloudy\"}"
}

// Model then returns:
{
  "role": "assistant",
  "content": "It's currently 24°C and partly cloudy in Tokyo."
}

Notice that arguments is a JSON-encoded string, not a nested object. This is a common source of bugs for developers new to function calling — the arguments must be parsed a second time on the application side.

A tool schema passed to the model is a JSON object with three top-level fields: name, description, and parameters. The parameters object follows the JSON Schema specification, with type, properties, and required as the core sub-fields. Here is a production-quality example:

{
  "name": "search_knowledge_base",
  "description": "Retrieve documents from the internal knowledge base. Use when the user asks about company policy, product specs, or historical decisions. Do NOT use for real-time data.",
  "parameters": {
    "type": "object",
    "properties": {
      "query": {
        "type": "string",
        "description": "Concise search phrase. Include entity names, dates, and product identifiers. Avoid filler words like 'please' or 'I need'."
      },
      "category": {
        "type": "string",
        "enum": ["policy", "product", "engineering", "finance"],
        "description": "Filter results to this document category. Omit if the category is unclear."
      },
      "max_results": {
        "type": "integer",
        "minimum": 1,
        "maximum": 20,
        "description": "Number of documents to return. Default to 5 unless the user explicitly requests more."
      }
    },
    "required": ["query"]
  }
}

Every field in this schema is doing work. The top-level description tells the model when to call the tool and — critically — when not to. The parameter descriptions tell the model how to construct valid inputs. The enum constraint on category prevents hallucinated values. The minimum/maximum on max_results prevents out-of-range integers.

The required array deserves careful thought. If a field is listed as required, the model will always attempt to populate it — even by inferring or hallucinating a value. If a field is optional, the model may omit it when uncertain, which is often safer than a wrong value.

• Required fields: Use only for parameters without which the function cannot execute meaningfully. User ID, action verb, and primary resource identifier are common required fields.
• Optional with enum: Use when the model should filter only if it has high confidence. Letting the model omit a filter is often better than picking the wrong category.
• Optional with default in description: Document the default explicitly in the description string so the model knows what behavior will result if it omits the field.
• Never required: confidence or uncertainty fields. The model cannot accurately self-assess confidence via structured output reliably enough to trust it in routing logic.

Anthropic's function calling documentation (2024) specifically recommends keeping the required array as small as possible and using description text to guide optional field population rather than schema enforcement — the model's language understanding is more flexible than JSON Schema constraints allow.

The highest-leverage optimization in tool schema design is description engineering. Unlike type constraints, descriptions operate on the model's language understanding layer — they can encode nuanced intent, negative examples, and disambiguation rules that no type system can express.

• Include negative examples: "Do NOT pass the user's raw message. Rephrase as a keyword query." dramatically reduces literal-utterance passthrough.
• Specify the caller's intent: "Use this tool when the user asks about past orders. Do not use for tracking live shipments — use track_shipment instead." This cross-tool disambiguation is only possible in description text.
• Embed format examples: For date fields, include the expected format string: "ISO 8601 format: YYYY-MM-DD. Example: 2024-03-15." Models comply reliably when the format is explicit.
• State units: "Temperature in Celsius, not Fahrenheit." Simple, but absent from most schemas encountered in the wild.

When a model receives a user message and a set of tool definitions, it must make a multi-class classification decision at each turn: respond with text, call exactly one tool, or call multiple tools in parallel. This decision is not based on hard rules — it emerges from the model's training on when tool use produces better outcomes than text alone.

The decision is shaped by several factors that designers can influence:

• Semantic match: How well the user's intent matches a tool's description. Dense, precise descriptions improve match quality.
• Tool count: More tools increase the chance of confusion between similar-sounding options. GitHub's data showed a roughly linear degradation with tool count past ~8-10 tools.
• Conversation context: Prior turns influence tool selection. If the user just asked about orders, a follow-up "and cancel it" will likely route to an order-cancellation tool without re-specifying the order ID.
• System prompt instruction: Explicit routing instructions in the system prompt ("Always prefer search_internal over search_web for product questions") can override ambiguous inference.

Most APIs expose a tool_choice parameter that controls selection behavior. Understanding the three modes is essential for production system design:

• auto (default): The model decides freely whether to call a tool or respond with text. Appropriate for general-purpose agents.
• required (or any): The model must call at least one tool. Use when you want to guarantee structured output — for example, in a classification pipeline where text responses are never valid.
• {"type": "function", "function": {"name": "..."} } (forced): The model must call this specific function. Use for structured extraction from a single document when the correct tool is known at call time.

Forced calling is a powerful technique for extraction tasks. If you know the user's message is a support ticket and you want to extract structured fields, forcing the extract_ticket_fields tool guarantees structured output without relying on the model's routing judgment. This is how many document processing pipelines achieve near-100% structured output rates.

OpenAI introduced parallel tool calling in November 2023. Instead of one tool call per turn, the model can emit multiple tool calls simultaneously in a single response. The application executes all of them — potentially concurrently — and returns all results before the model generates a final response.

Parallel calling is most valuable when the query decomposes into independent sub-tasks. "What's the weather in Tokyo and the stock price of Sony?" requires two unrelated lookups that can run simultaneously rather than sequentially. A two-turn sequential approach takes twice as long for the same output.

• The model emits an array of tool_calls objects in one response.
• Each has a unique id. The application returns one tool-role message per ID.
• The model waits for all results before synthesizing a response.
• If tasks are not independent, sequential calling is safer — later calls can adapt based on earlier results.

The distinction between tasks that should be parallel vs. sequential is a key architectural judgment. Code that executes in parallel when it should be sequential — for example, sending a payment before confirming an order exists — can produce irreversible errors in production.