Module 1 · Lesson 6

Function Calling Explained for AI Agents

Function calling lets a model request a structured operation, but your application still owns validation, execution, permissions and side effects.

Updated August 2026 · Tools · Structured actions

The core idea

Instead of asking a model to invent text that looks like an API request, you give it a tool definition with a structured schema. The model can then choose that tool and provide arguments that match the schema.

Tool: get_weather
Arguments:
{
  "city": "Lahore"
}

The runtime receives this request, executes your function and sends the result back to the model. The model then continues with the new information.

Function calling is a protocol between model and application

The schema is the contract. It tells the model what the function does and what arguments are expected. The implementation remains normal code.

def get_order_status(order_id: str) -> dict:
    # authenticate, validate, query database
    return {"order_id": order_id, "status": "shipped"}

In OpenAI's Agents SDK, Python functions can be exposed as function tools with automatic schema generation and Pydantic-powered validation.

The five-step flow

1. Your application sends the model instructions plus tool definitions.
2. The model chooses whether to answer directly or request a tool.
3. The runtime validates the requested arguments.
4. Your application executes the tool.
5. The tool result is returned to the model as context for the next turn.

Schema design matters

A vague schema makes tool use harder. Prefer explicit types and constrained values where possible.

Weak schema

{"action": "string", "payload": "object"}

Better schema

{
  "order_id": "string",
  "reason": "string",
  "notify_customer": "boolean"
}

Separate unrelated actions into separate tools. This improves clarity and makes authorization easier.

Function calling does not guarantee correct arguments

Structured output reduces ambiguity but does not make the model infallible. Always validate IDs, ranges, enum values, ownership and business rules before execution.

Read tools and write tools should be treated differently

Read-only tools such as search and lookup are generally lower risk. Write tools such as refunds, deletes, email sending or account changes deserve stronger controls.

• Require explicit user confirmation for destructive actions.
• Use idempotency keys for retryable writes.
• Audit important operations.
• Keep transaction rules in code.
• Consider separate agents or tool sets for read and write capabilities.

Error handling

Tools should distinguish expected domain errors from infrastructure failures. An expected result might be order_not_found. A network timeout is different and may be safely retried by code.

{
  "ok": false,
  "error": {
    "type": "order_not_found",
    "message": "No order exists for that ID."
  }
}

Structured failures give the model better information than a long stack trace and reduce the chance that sensitive internals leak into context.

Function calling vs MCP

Function calling explains how a model requests tools. MCP solves a different layer: it standardizes how clients discover and interact with external tool/resource/prompt providers. An MCP client can expose MCP tools to a model, which may then use the same underlying tool-calling mechanism.

That distinction becomes important later in this course: function calling is a model/application interaction pattern; MCP is an interoperability protocol for connecting AI applications to external capabilities.

Function tools in a framework

A framework can remove boilerplate around schema generation, execution loops, errors and tracing. OpenAI's current Agents SDK can wrap Python functions as tools and trace function calls as part of an agent run.

Official references