Learning outcomes
- Represent queued running blocked failed and completed actions
- Expose consequential inputs before execution
- Preserve correction retry and audit context
Mental model
Render tool use as a finite state machine tied to an auditable operation ID. Each state exposes the next available user control and never conflates a model proposal with an executed side effect.
Theory
The model may propose a tool and arguments. The application validates schema, policy, identity, and target before creating an operation. Consequential operations enter an approval state. Queued and running states expose useful progress only when backed by real events. Completion requires a verified result or observed environment state.
Show the tool name, target, important arguments, authority level, start time, and current state. For failure, separate validation, authorization, timeout, dependency, and business errors because recovery differs. Provide retry only when idempotency or deduplication makes it safe. Cancellation should report whether the downstream operation actually stopped.
Alternatives and trade-offs
Compact inline indicators suit low-consequence read tools. A detailed activity panel helps long-running or multi-step work. Raw logs support experts but should not replace accessible summaries. Optimistic UI is appropriate only for reversible operations with reliable reconciliation.
Failure modes and misconceptions
A spinner is not a state model. Marking success when a tool request was merely accepted misleads users. Hiding arguments makes approval uninformed. Automatic retry can duplicate writes. Displaying untrusted tool output as interface markup creates injection risk.
Knowledge check
Which evidence should move a tool operation from running to completed?
Decision scenario
A refund tool shows proposed amount and account, waits for bound approval, displays the provider transaction ID while verifying, and marks completion only after the account ledger confirms the change. A timeout remains unknown until reconciliation.
Learning outcomes
- Explain Rendering Tool Call Execution States as a system mechanism rather than a slogan.
- Compare its alternatives, trade-offs, and production failure modes.
- Apply the concept to a decision and identify evidence that would validate it.
Trade-offs
Using Rendering Tool Call Execution States can improve capability or control, but it also introduces cost, latency, complexity, and failure modes that must be measured against an explicit objective.
Evidence assessment
Theory and decision mastery
Decision scenario
A production team must adopt Rendering Tool Call Execution States while meeting quality, latency, security, and operating constraints.
Which decision process is most defensible?
Relationships
Primary sources
- Model Context Protocol Architecture and Tools Specification — Model Context Protocol, verified 2026-07-21
- Guidelines for Human-AI Interaction — Microsoft Research / ACM CHI, verified 2026-07-21