THE CORE AIM OF VOCABULARY MASTERY · AI TOOL CALLING · REQUEST → VALIDATE → AUTHORISE → EXECUTE → OBSERVE
AI tool calling vocabulary explains the boundary between an AI model proposing a tool action and an application actually carrying it out. Important words include function calling, tool schema, argument, validation, authorisation, side effect, tool result, read-only, write action, approval, idempotency and audit trail. The most practical distinction is simple: generating a request to use a tool is not the same as successfully executing that tool.
The core aim is action-boundary literacy: a learner should identify what the model asked to happen, what the software validated, which identity and permissions were used, whether the external operation completed, and what observable evidence came back. This matters whenever AI works with browsers, school records, files, maps, calendars, email or publishing platforms.
This guide belongs to the Vocabulary Hub and Core Aim of Vocabulary Mastery Learning Hub. It builds on AI Agents Vocabulary for the agent loop and AI Policy Enforcement Vocabulary for enforceable permissions. Unlike those broader pages, this one concentrates on the exact passage from model request to tool execution and result.
Central proposition: An AI-produced tool call is a proposal containing arguments. A trustworthy application decides whether it may execute, validates the arguments, controls side effects and checks the returned result.
The 60-second AI tool calling router
- Discover: tool inventory, name, description and capability.
- Express: call, parameter, argument and schema.
- Check: type validation, authentication, authorisation and risk level.
- Act: dispatch, execution, side effect and timeouts.
- Observe: response, error, status, trace and reconciliation.
- Recover: approval, retry, idempotency and escalation.
Essential tool calling vocabulary
| Term | Plain-English meaning | Why it matters |
|---|---|---|
| Tool | An application capability that a model may request. | It can query information or change something. |
| Function call | A structured request for an operation, often with arguments. | A request is not proof of execution. |
| Tool schema | A specification of the tool name and accepted inputs. | The model and application need compatible expectations. |
| Parameter | A named field an operation accepts. | It identifies the type of input required. |
| Argument | A specific value supplied for a parameter. | Wrong arguments can target the wrong record. |
| JSON schema | A structured way to specify fields, types and constraints. | It helps reject malformed requests. |
| Dispatch | The application routing a request to its implementation. | Only authorised requests should reach the action. |
| Authentication | Establishing which account or actor is making a request. | Identity is separate from permission. |
| Authorisation | Deciding whether that actor may perform this action. | A valid user may still lack access. |
| Read-only operation | A tool that does not intentionally modify the managed resource. | It may have different risk from a write. |
| Write action | An operation that changes external state. | It may need additional approval and verification. |
| Side effect | A consequence outside the model’s text, such as a sent email. | Text generation and real-world action differ. |
| Tool result | The information or status returned after execution. | The model should use it rather than assume success. |
| Timeout | A limit after which the caller stops waiting. | A timeout does not guarantee the action failed. |
| Idempotency | Protection against unwanted duplicate effects on repetition. | Essential for safe retries of writes. |
| Audit trail | A record of action requests, approvals and outcomes. | It supports review and error diagnosis. |
Four distinct stages: proposal, validation, execution and confirmation
1. Proposal
The model chooses a named tool and proposes arguments. In natural language it may appear to say, “Search the curriculum library for Primary 6 topics.” Under the hood, the request could name a retrieval tool and provide a search query. The model has not yet read the result, because the application still needs to process the request.
2. Validation and authorisation
Software checks whether the input has the right structure and whether the authenticated actor may use the tool for that target. For consequential operations, this can include a human approval gate. Validation checks the shape of the request; authorisation checks the right to perform it. They solve different problems.
3. Execution
The application calls its own function, connected service or remote server. Execution may read data, change an existing record, create a post, send a message or fail with an error. A call can be rejected, time out or succeed only partially. Real actions occur in this stage, not when the model merely writes that it intends to act.
4. Observation and confirmation
The tool returns a result such as a matched document, generated ID, status or error. A robust workflow reads the result and, for important writes, verifies the new external state. The correct reporting language is “the operation returned a created post ID” or “the request was rejected”, not a confident success claim unsupported by the tool response.
A worked example: a parent asks an AI assistant to arrange a consultation
Suppose a parent asks an eduKate learning assistant about available consultation slots. The assistant may use a calendar read tool to check available time windows. Showing a possible slot is different from booking it. To create an event, the application may require the parent’s confirmation, validate the selected date, prevent duplicate bookings and then call a calendar write tool.
- Read: check availability, recording which calendar was queried and when.
- Present: explain the exact proposed slot, timezone and participants.
- Approve: obtain user confirmation for the actual booking rather than treating a speculative suggestion as authorisation.
- Write: call the booking operation with validated participants and slot identifiers.
- Verify: inspect the returned event ID or re-read the booking as necessary.
- Report: say that booking succeeded only after the connected service confirms it.
The same boundary applies to WordPress. Drafting an educational article and publishing it are different actions. A model that produced the full article has not thereby created a WordPress post. When the publishing tool returns a post ID and published URL, the assistant can report the verified result. If it only returns an error or an editable draft, that is what must be reported.
Tool descriptions and schemas cannot enforce permissions by themselves
A schema can require a numeric record ID or restrict an input to an approved format. It cannot by itself establish that the current user owns the record or that a proposed action is permitted. A tool description that says “read only” is informative but should not be the entire security boundary. Effective controls belong in the application, tool server, service permissions and approval workflow.
A familiar example is the difference between asking a chatbot not to send messages and withholding the email-sending capability entirely. Strong systems use the second kind of boundary wherever appropriate. They also limit the tool’s scope to the minimum data and operations needed for the task.
Tool risk: read, write, delete and external transmission
| Operation | Example | Control to consider |
|---|---|---|
| Read | Retrieve a public syllabus excerpt. | Source provenance and correct result interpretation. |
| Read sensitive material | View an authorised student progress record. | Identity, purpose, scope, access logging. |
| Write | Create a draft lesson plan. | Valid inputs and destination review. |
| Publish or send | Publish a web page or send an email. | Explicit approval and post-action confirmation. |
| Destructive action | Remove a record or replace published content. | Narrow permissions, review and recovery safeguards. |
| External transmission | Send content to another organisation or API. | Data classification, permitted recipients and disclosure control. |
Why tool results are data, not new instructions
A search result, retrieved webpage or file can contain text that attempts to direct the model. Such material may be useful evidence, but it should not gain authority to override the actual user request or the application’s operating rules. Separating tool-result data from executable instructions is a core defence against prompt injection. The executing application should enforce permissions even if the model misinterprets a retrieved sentence.
Retrying a tool: why status matters
Suppose a post-creation request times out. The assistant cannot safely infer that the post was not created; the response could have been lost after WordPress saved it. A safe retry begins by checking the destination for the intended slug or returned object ID. Otherwise, repeating the action might create duplicates. Distinguish transport failure, operation rejection, partial success and confirmed completion before selecting the next step.
A practice exercise: classify the action
- Consider a tool that returns a public page title and URL. Identify the tool input, result and whether a side effect should occur.
- Consider a tool that publishes a draft. Identify which actor must be authorised, which inputs require validation and what status proves publication.
- Explain the difference between a model-generated JSON request and a tool-produced confirmation.
- Suppose an email tool times out. Explain why an immediate blind retry can be unsafe, and name one way to check the outcome first.
- Rewrite the claim “the AI booked it” so that it correctly distinguishes proposed action, approval and confirmed booking.
Common tool calling mistakes
- “The model called it, so it happened”: execution occurs in the application and requires a result.
- “The JSON is valid, so the action is allowed”: valid formatting does not grant permission.
- “Read-only means risk-free”: sensitive read access still needs controls.
- “The tool timed out, so nothing changed”: verify the destination before retrying.
- “A source result may issue commands”: treat untrusted source content as data.
- “A tool annotation replaces authorisation”: enforce privileges in the actual system.
- “A message saying done is proof”: use returned identifiers and independent checks.
Frequently asked questions
What is AI tool calling?
It is a pattern in which a model requests that software execute a defined external capability, often using structured parameters and receiving a tool result.
Does function calling give the model unlimited access to a device or account?
No. Access depends on which tools the application exposes, their permissions and the controls enforced around execution.
What is the difference between a tool call and an API request?
A model tool call is a request to the host application. The host may fulfil it through local code, an API request or another connection; they are related but not identical steps.
Why do tool calls need an audit trail?
An audit trail helps reveal which operation was proposed, validated, authorised and actually completed, particularly when an external change must be investigated.
Can a tool result contain incorrect information?
Yes. Results can be stale, incomplete, misconfigured or adversarial. The model and application still need to check relevance, provenance and reliability.
References and connected learning
- OpenAI Agents SDK — Tools (tool descriptions, schemas and execution).
- OpenAI Agents SDK — Guardrails (input and tool-level checks).
- Model Context Protocol — Tool Annotations as Risk Vocabulary (risk hints and limits).
- AI Policy Enforcement Vocabulary (enforceable action permissions).
- AI Human Oversight Vocabulary (approval and intervention).
The AI tool calling vocabulary standard
The learner has mastered this topic when they can identify a proposed call, validate its arguments, name the required authority, distinguish reading from changing external state, interpret the tool result and explain what evidence confirms success. Technical vocabulary has done its job when it prevents a system from mistaking intent for action.