Function calling and structured outputs, MBA Training, MBA Training

python

from openai import OpenAI

client = OpenAI()

tools = [{
    "type": "function",
    "name": "get_weather",
    "description": "Get the current temperature for a city in Celsius.",
    "parameters": {
        "type": "object",
        "properties": {
            "city": {"type": "string", "description": "City name, e.g. 'Lisbon'"}
        },
        "required": ["city"],
        "additionalProperties": False
    }
}]

python

import json

def get_weather(city):
    # Pretend this hits a real API.
    return {"city": city, "temp_c": 19}

input_list = [{"role": "user", "content": "What's the weather in Lisbon?"}]

response = client.responses.create(
    model="gpt-4.1",
    tools=tools,
    input=input_list,
)

# Carry the model's output forward as part of the conversation.
input_list += response.output

for item in response.output:
    if item.type == "function_call":
        args = json.loads(item.arguments)
        result = get_weather(**args)
        input_list.append({
            "type": "function_call_output",
            "call_id": item.call_id,
            "output": json.dumps(result),
        })

final = client.responses.create(
    model="gpt-4.1",
    tools=tools,
    input=input_list,
)
print(final.output_text)

python

from pydantic import BaseModel

class CalendarEvent(BaseModel):
    name: str
    date: str
    participants: list[str]

response = client.responses.parse(
    model="gpt-4.1",
    input=[
        {"role": "system", "content": "Extract the event details."},
        {"role": "user", "content": "Standup with Ana and Rui on Friday."},
    ],
    text_format=CalendarEvent,
)

event = response.output_parsed
print(event.participants)  # ['Ana', 'Rui']

Errors, costs, and failure modes

Real systems break in specific ways. Plan for them.

The model hallucinates a tool that does not exist, or bad arguments. With strict tool schemas this is rare, but if a function genuinely fails, return an error *as the tool output* (for example {"error": "order not found"}) rather than throwing. The model can read that and recover, asking the user for a correct order id.
Refusals. Structured Outputs can still refuse on safety grounds. The SDK surfaces this so you check for a refusal field before trusting output_parsed. Handle it explicitly instead of treating a refusal as malformed data.
Truncation. If the model hits the output token limit mid-JSON, you get incomplete data even with strict mode, because the constraint guarantees *valid structure*, not *completion*. Check the response status for incomplete and raise your max_output_tokens for large objects.
Latency on first use of a new schema. The very first request with a novel strict schema may be slower while the API prepares the constraint. Repeated schemas are fast. Reuse schemas rather than generating them dynamically per request.
Tokens. Tool definitions and schemas live in the context window and count as input tokens on every call. Long, verbose schemas across many tools add up. Keep descriptions tight and only attach tools the model might plausibly need for this request.

Where this sits in the ecosystem

You have now seen the raw machinery. Higher-level OpenAI products are built on exactly these primitives:

GPT Actions in Custom GPTs are function calling driven by an OpenAPI spec. You describe your API once, and the GPT calls it through the same request/execute pattern, just managed by ChatGPT instead of your code.
The Agents SDK wraps the tool loop, retries, and handoffs so you stop writing the while loop by hand. When your tool orchestration gets complex (multiple agents, guardrails, tracing), graduate to it rather than maintaining bespoke loop code. See the Agents SDK docs.
Built-in tools like web search and file search are function calls the API runs server-side. You enable them in

Understanding the bare loop first means none of these feel like magic. They are conveniences over the contract you just learned.

Key Takeaways

Tool calling is a loop you own. The model *requests* a function; your code runs it, returns the output keyed by call_id, and calls the model again. Loop until no tool calls remain, with a hard iteration cap.
Use `strict: true` Structured Outputs for any answer your code parses. It guarantees the shape, eliminating brittle prompt-and-pray JSON. In Python, define a Pydantic model and read output_parsed.
Design schemas defensively. Treat all fields as required (use null unions for optional), constrain choices with enums, write field descriptions, and confirm your keywords are in the supported subset.
Return tool errors as data, and check for refusals and truncation. Let the model recover from failed calls; verify response status before trusting the payload.
Reach for the Agents SDK or GPT Actions when the loop grows. They are built on these exact primitives, so the mental model transfers directly.

tools

Function calling and structured outputs

Two mechanisms, two jobs

Defining a tool

The tool-calling loop

Practical rules for the loop

Structured Outputs: stop parsing prose

Schema design that actually works

Combining both: the realistic pattern

Errors, costs, and failure modes

Where this sits in the ecosystem

Key Takeaways

Function calling and structured outputs

Two mechanisms, two jobs

Defining a tool

The tool-calling loop

Practical rules for the loop

Structured Outputs: stop parsing prose

SchemaSchemaA schema is the formal blueprint that defines how data is structured, named, typed, and related within a database, file, or message.Voir la définition complète → design that actually works

Combining both: the realistic pattern

Errors, costs, and failure modes

Where this sits in the ecosystem

Key Takeaways

Schema design that actually works