A language model can describe an action in prose. A software system needs something stricter: a typed instruction that another machine can execute. Tool-call representation is the bridge between those two worlds.
The representation usually contains a tool identity plus structured arguments. That sounds simple until the consequences arrive. The wrong field type can fail safely. The wrong account ID can act on the wrong object. A syntactically valid call can still be semantically wrong. An authorised tool can still be invoked at the wrong moment. Tool use therefore turns representation design into operational governance.
This article extends the eduKateSingapore Representation and Tokenisation series from symbols and workflows into executable interfaces.
The Tool-Call Route
USER INTENT → LANGUAGE MODEL → TOOL SELECTION → SCHEMA-CONSTRAINED ARGUMENTS → VALIDATION → AUTHORITY / PERMISSION GATE → TOOL EXECUTION → RECEIPT / RESULT → MODEL INTERPRETATION → USER / WORLD RETURN
1. A Tool Call Is a Structured Claim About What Should Happen
When a model emits search(query="..." ) or a JSON object naming an operation and its parameters, it has moved beyond ordinary prose.
The output now claims that a particular capability should be invoked with particular data.
2. Tool Identity Is a Token of Capability
A tool name such as search, calculator, database_query or send_message points to a capability with a defined contract.
The name is therefore closer to an action type than an ordinary word.
3. Arguments Are Typed Slots
A search tool may require a query string. A reservation tool may require party size, date and time. A database function may require an integer identifier.
Argument names give values semantic roles that plain positional text may not preserve.
4. Schema Is the Grammar of the Action
A schema can declare required fields, allowed types, enumerated choices, nested objects and constraints.
The schema does for tool arguments what a formal grammar does for programming-language syntax.
5. Structured Outputs Reduce Surface Ambiguity
OpenAI’s Structured Outputs describes constraining model responses to developer-supplied JSON Schemas. In tool use, this means the generated arguments can be forced to match the declared structural contract.
This is a major representation improvement: the receiver no longer has to guess how prose maps to fields.
6. Schema Correctness Is Not Semantic Correctness
A call can perfectly satisfy the schema and still contain the wrong date, wrong customer ID or wrong amount.
OpenAI’s documentation explicitly distinguishes structural reliability from mistakes in field values. The schema protects form, not truth.
7. Valid JSON Is an Even Weaker Guarantee
A JSON object can be syntactically valid while missing required fields or using values outside the application’s allowed range.
Syntax, schema validity and semantic validity are three separate gates.
8. Tool Selection Is a Classification Problem
Before arguments can be generated, the system must decide which tool is appropriate.
“What is 17 × 23?” belongs naturally to a calculator. “What did this contract say?” belongs to document retrieval. Selecting the wrong receiver creates a representational mismatch before execution begins.
9. Similar Tool Names Create Routing Risk
customer.lookup and customer.delete may differ by one verb and have radically different consequences.
Tool descriptions and namespaces should make action scope unmistakable.
10. Read Tools and Write Tools Are Different Risk Classes
Searching a database observes state. Updating the database changes state.
Tool registries should encode this distinction rather than relying on the model to infer side effects from names.
11. Destructive Tools Need Stronger Boundaries
Delete, publish, transfer, cancel and send operations can have irreversible or externally visible effects.
The representation should carry enough identity, scope and approval context to prevent ambiguous execution.
12. Confirmation Is a Workflow Token, Not a Feeling
A system should be able to identify exactly what the user approved: which object, which action and which proposed parameters.
This connects tool calls to Workflow Tokenisation.
13. Approval Should Bind to an Action Object
“Approved” is unsafe if the proposed transfer amount changed after confirmation.
Strong systems bind approval to a stable representation of the exact action being authorised.
14. Defaults Are Hidden Arguments
If party size defaults to two or a region defaults to Singapore, an omitted field still changes execution.
Default values should be explicit in the tool contract and visible during audit.
15. Optional Fields Are Not Unimportant Fields
An optional seating preference may matter greatly to one user even if the reservation can technically proceed without it.
Schema optionality describes machine necessity, not human importance.
16. Enumerations Reduce Vocabulary Drift
If a status field permits only draft, approved and published, the model should not invent ready-ish.
Enumerated values create a controlled action vocabulary.
17. Units Must Travel With Quantities
An argument distance: 5 is incomplete if the tool expects metres but the user meant kilometres.
Structured arguments should preserve unit semantics explicitly.
18. Dates Need Timezone Context
A meeting at 9:00 means little without date and location or timezone when systems operate internationally.
Temporal ambiguity becomes operational error when it crosses a tool boundary.
19. Entity IDs Are Safer Than Ambiguous Names
A tool updating “Alex Lee” can target the wrong person if several records share the name.
Resolve names to canonical IDs before high-impact actions when possible.
20. Human Names Should Stay Visible Alongside IDs
An opaque database ID is machine-safe and human-hostile.
Good interfaces display the human-readable identity while executing against the canonical identifier.
21. Tool Arguments Can Contain References Rather Than Copies
A file tool may accept a file ID instead of embedding the entire file contents. A database tool may accept a row ID instead of repeating the row.
Reference tokens reduce context while preserving identity.
22. References Need Access Scope
A valid file ID does not mean the current user is authorised to access the file.
Identity and permission are distinct checks.
23. Authentication Says Who Is Acting
The same tool call can be legitimate for one authenticated user and forbidden for another.
User identity is part of executable context even when it is not one of the model-generated arguments.
24. Authorisation Says What That Identity May Do
Being logged in is not equivalent to having permission to delete, publish or transfer.
Permissions should be enforced by the tool or surrounding system, not trusted to model compliance alone.
25. Tool Execution Should Produce a Receipt
After a write, the system should return stable evidence: record ID, timestamp, status, resulting URL or another verifiable outcome.
“I tried” and “it happened” are different workflow states.
26. Receipts Are World-Return Tokens
A live page URL, transaction identifier or calendar event ID connects the model’s symbolic action back to external state.
Execution is complete only when the result can be observed.
27. Errors Need Typed Representations Too
Authentication failure, missing field, rate limit and not-found are different states requiring different next actions.
Free-form error strings are harder to route reliably than typed error objects.
28. Retryability Is Part of Error Meaning
A temporary timeout may justify a retry. A permission denial generally does not.
Tool responses should help the controller distinguish recoverable from terminal failures.
29. Retries Can Duplicate Side Effects
If a payment succeeds but its response times out, blindly retrying can create a second charge.
Idempotency keys or stable operation IDs protect the action representation across uncertain network state.
30. Parallel Tool Calls Need Independence
Two reads can often run together. Two writes that depend on each other’s results cannot safely be treated as independent.
Concurrency belongs to workflow structure, not merely performance optimisation.
31. Tool Outputs Can Become New Model Inputs
A search result, calculator answer or database row returns to the model as structured evidence.
The system alternates between language tokens and typed machine representations.
32. Tool Output Schemas Protect the Return Path
If the model knows which field contains status, value, currency or URL, it can interpret results more reliably than parsing arbitrary prose.
Structure benefits both action and observation.
33. A Tool Result Can Be Structurally Valid and Factually Stale
A database may return a correctly typed price recorded yesterday.
Freshness and provenance remain necessary above schema validation.
34. Tool Descriptions Are Part of Model Routing
The model often selects tools from natural-language descriptions plus schemas.
Vague descriptions create capability collisions; precise descriptions reduce routing entropy.
35. Tool Registries Need Versioning
If argument names or semantics change, historical calls and cached plans can become incompatible.
Tool version belongs with schema version.
36. Schema Migration Is an Interface Migration
Renaming customer to customer_id can improve clarity and break old clients.
Backward compatibility, adapters and explicit deprecation protect the executable contract.
37. Tool Use Is Representation Switching
A user speaks in natural language. The model maps intent into a typed action. The tool maps action into software state. The result returns as data and is translated back into explanation.
Every boundary can lose meaning.
38. The Strongest Systems Verify Before and After
Before execution: validate schema, identity, permissions and scope. After execution: verify the receipt and resulting state.
This converts a probabilistic proposal into an auditable action loop.
39. The Tool-Call Representation Audit
- What capability does the tool actually expose?
- Is it read-only, write-capable or destructive?
- What exact schema governs arguments?
- Which fields are required, optional or defaulted?
- Are types, enums, units and timezones explicit?
- Do human names resolve to canonical entity IDs?
- What authentication context applies?
- What authorisation gate applies?
- Does the current user approval bind to the exact action?
- Can structurally valid arguments still be semantically wrong?
- What validation occurs before execution?
- Are retries idempotent?
- What typed errors can return?
- What receipt proves execution?
- Can the result be checked against the external world?
40. What Students Should Remember
- Tool calls are structured action representations.
- Schemas constrain form, not truth.
- Tool selection and argument generation are separate problems.
- Read and write capabilities deserve different controls.
- Identity, permission and approval should be explicit.
- Typed errors improve recovery.
- Idempotency protects retries from duplicated side effects.
- A receipt closes the loop between model output and world state.
41. The Deep Principle
Tool calling is the point where representation acquires consequence. A string that once described an action becomes an object another machine may execute.
The safer the action must be, the less meaning should be left implicit. Good tool-call representation turns intent into typed, scoped, authorised and verifiable machine action.