THE SHORT ANSWER
A tool is a capability exposed to a model through a description and input schema. With function calling, the model can propose a named function and structured arguments. Host application code checks permission and validity, performs the operation, and sends the tool result back as an observation. The model itself does not directly execute the function.
Separate deciding from executing
| Step | Actor | Responsibility |
|---|---|---|
| Describe | Developer or tool server | Name capability, inputs, output and side effects |
| Choose | Model within host rules | Propose a tool and arguments |
| Validate | Application | Check schema, identity, permission and policy |
| Execute | Application or connected service | Perform the approved operation |
| Observe | Tool and environment | Return data, error and resulting state |
| Continue | Controller and model | Verify progress and choose the next bounded step |
Evidence & context: OpenAI Developers
Tools can read, compute or change state
- Search an approved information source.
- Read a file or retrieve selected passages.
- Query a database through a limited read interface.
- Calculate or execute code in a sandbox.
- Draft or send an email through separate capabilities.
- Check calendar availability or create an approved event.
- Call a business API with the user's authorised identity.
A single vague ‘manage everything’ tool expands risk and makes failures hard to diagnose. Narrow tools make permissions, validation and audit clearer.
Make a tool legible to the model and the host
Use an unambiguous name and description. Define required arguments and constrained values. State whether the tool reads or writes, whether retries are safe, and which errors are expected. Structured schemas can improve argument handling, but external inputs still require server-side validation.
Return evidence rather than a reassuring sentence. A send operation might return a provider message ID and status; a calendar operation should return the resulting event identity. The controller can then verify the outcome.
Evidence & context: OpenAI Developers · Model Context Protocol
Expose only what this step needs
- Use the least-privileged identity and smallest current tool set.
- Separate read, draft and execute operations.
- Require approval for consequential writes.
- Apply timeouts, rate limits and idempotency where appropriate.
- Treat tool descriptions and returned content as untrusted inputs.
- Log proposed, approved, executed and failed states without exposing secrets.
Sources & further reading
- Using tools
OpenAI Developers. Official documentation showing how models can be given built-in, function and remote tools. Checked 13 September 2026; product-specific tool names and availability can change.
- Function calling
OpenAI Developers. Official documentation for model-selected function calls. The application, not the model, executes custom functions and must validate arguments, permissions and results.
- Model Context Protocol tools
Model Context Protocol. The current official tools specification checked 13 September 2026. Draft details can change; OpenSkool relies on the durable separation between tool discovery, model selection and host-controlled execution.
Examples and exercises are illustrative unless attributed to a source. No independent expert review is claimed.
A correction, a counterexample or an experience worth sharing?
Join the conversation ↗