OpenAI Function Calling guide
Official reference for connecting models to application functions and validating the application-side execution path.
← Back to Compute College
Compute College
Tool design and function calling
Design narrow, typed tools that let a model request useful actions without hiding critical assumptions.
Plain-English definition
A tool is a bounded operation an AI system can call, such as searching a catalog, reading a record, or drafting an update. Function calling represents the request in a structured shape, but the application must validate arguments, authorize the action, execute it, and return a controlled result.
Memory trick: A tool is an API boundary, not a suggestion.
Why it matters
A broad tool gives a model too much authority and makes failures hard to inspect. Narrow schemas, explicit errors, and read/write separation reduce accidental actions and make tool use easier to evaluate.
- The design makes a hidden tradeoff measurable before it reaches users.
- A clear boundary reduces retries, unsafe actions, or unnecessary capacity.
- The operating choice should be tested against the workload rather than assumed from a demo.
Simple example
Instead of exposing `run_sql`, expose `find_open_orders` with typed customer and date fields. The server validates the fields, applies the caller’s authorization, limits rows, and returns only the data needed for the next decision.
- The example names the input, decision, and expected boundary.
- A deterministic or human checkpoint owns the part a model should not guess.
- The result can be measured with quality, latency, safety, and cost metrics.
Example figures are illustrative calculations, not current quoted market prices.
Current example
Primary reference
This source explains the method or risk boundary. It does not replace testing the actual model, data, provider, and workload conditions in production.
Source discipline: examples on this page are illustrative; measure the real workload before making a release or capacity decision.
Common mistake
A valid function-call shape says nothing about whether the action is safe. Schema validity does not establish authorization, freshness, or business correctness.
Practical takeaway
What you can do with this
Design one tool with a narrow purpose, typed arguments, authorization check, timeout, idempotency behavior, and explicit error results. Test malformed and unauthorized calls.
- Start with a narrow workflow and explicit failure boundary.
- Instrument the path before optimizing it.
- Review the design whenever model, tool, traffic, or policy changes.
Decision check: can the tool reject an invalid or unauthorized request without relying on the model to notice?
Compute College learning path
AI Engineering
Step 30 of 48: Tool design and function calling