tool-call-flow
Tool-Call Flow
Concept of the skill
A tool-call flow is the multi-turn protocol by which a language model uses external capabilities. The four phases are stable:
| Phase | Who acts | Output | Becomes |
|---|---|---|---|
| 1. Declaration | Runtime/provider/SDK | Tool catalog, schemas, grammar constraints, or a discovery/search surface | Model input for the next turn |
| 2. Request | Model | Structured tool-call intent, programmatic code that calls allowed tools, UI action request, or final answer | Assistant/model output in the transcript |
| 3. Execution | Runtime/provider/MCP server/sandbox/UI harness | Result of invoking the capability after validation and policy checks | Tool result, function output, screenshot, code result, or provider-hosted observation |
| 4. Continuation | Runtime/provider/SDK | Result paired to the request by ID, plus provider-required continuity artifacts | Next model input; the cycle repeats |
The cycle ends when the model emits a turn without tool-call requests. The final message's content is the answer.
The cycle's defining property is the separation of planning from execution. The model produces structured intent; the runtime carries it out. This is not a workaround for model limitations. It is a deliberate design choice that makes the system auditable, composable, and recoverable.
Coverage
This skill covers the protocol-level cycle by which a language model uses external capabilities: declaration, request, execution, continuation, ID pairing, model-visible state, vendor message shapes, strict schemas, grammar-constrained custom tools, MCP discovery and results, SDK-managed loops, hosted/server tools, tool search and deferred loading, programmatic tool calling, code execution with MCP, computer-use/browser-control loops, parallel and streaming tool calls, error encoding, untrusted tool output, runtime responsibilities, and the boundary between model-side intent and runtime-side execution.