A tool call is a model-initiated request to run a named function with structured arguments. The model does not execute anything itself — it emits an intent, the platform resolves and executes it, and the result is fed back into the ReAct loop as an observation.
The lifecycle
model emits intent -> permission resolution -> execute -> observation
|
allow / ask / deny
Every tool call passes through permission resolution before it runs. The outcome is one of three: allow, ask a human, or deny. See permission mode for how that resolution is decided.
Where tools come from
- HTTP tools you define explicitly, with a schema and endpoint
- MCP servers, contributing their whole catalog at once
- Built-in platform tools, provided by the runtime
Read-only built-in tools are never gated — they always run. Everything else is subject to the permission ladder.
Session injection
Tool arguments can carry per-property session injection: certain fields are populated by the platform at call time rather than by the model. Tenant identifiers are the canonical case. The model never sees them, so it cannot leak them, hallucinate them, or be manipulated into substituting another tenant's value.
Tool calls and conversation history
Tool calls do not appear in persisted session history. A conversation stores the user's message and the final answer for each turn — nothing else. However many tool calls happened internally to produce that answer, none are recorded there. To see them, read the execution trace instead. This is a frequent source of confusion when debugging: the session looks empty of activity that definitely occurred.