Tool Call
Tool Call turns one external capability execution into an auditable name, input, progress, result, and recovery path. Its collapsed summary answers what is happening, which integration owns it, and its current state; potentially long input and output stay behind the disclosure.
Find permission boundary implementationssearch · rg "permission|policy" src1.8 sRunning
/workspace/uiCall ID call_8f42Output redacted{"query":"permission|policy","path":"src","limit":200}src/security/policy.ts:42: export function authorize(...) src/runtime/permission.ts:18: type PermissionDecision = ... tests/policy.spec.ts:71: expect(decision).toEqual(...)
The call failed. Review permissions and retry.
Product boundary
Tool Call is not a generic log container. It preserves the information a person needs to decide whether an execution is trustworthy without dumping provider-internal fields into the interface.
- Use an intent-level title such as “Read configuration,” not only
shell_command. - Distinguish preparing, awaiting approval, running, succeeded, denied, failed, timed out, and interrupted.
- Enter
awaitingbefore a risky operation and let the host render explicit approve and deny actions. - Separate input, output, and error. Long content keeps its own scroll boundary instead of expanding the task timeline indefinitely.
- Retry, stop, copy, and open-file actions emit events; networking, authorization, and auditing remain host responsibilities.
Controller
Prefer preparing, awaiting, running, succeeded, failed, denied, timed-out, and interrupted. The legacy queued, waiting, success, cancelled, and error states remain compatible.
Accessibility and security
The action name and state in the summary cannot rely on color or an icon alone. The runtime exposes running state through aria-busy; an approval flow moves focus to real buttons, and completion produces one polite status announcement. Remove tokens, cookies, secrets, and personal data before rendering. Copy only the already-redacted visible output.
