# ACP tool calls and permission flow

## Metadata

| Field | Value |
|---|---|
| Institute | Molodetz Institute — Research & Retrieval Division |
| Subject | cap-protocol |
| Document type | Source Dossier |
| Tier | 1 |
| Source title | ACP Tool Calls |
| Source URL | https://agentclientprotocol.com/protocol/v1/tool-calls.md |
| Source type | specification |
| Source date (published) | Unknown, not stated (living docs) |
| Date researched | 2026-10-18 |
| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
| Research method | direct page fetch, read selectively (permission request/response, option kinds, statuses; content-block sections skimmed) |
| Confidence | High |
| Status | Active |

## Summary

Tool-call reporting (`tool_call` + `tool_call_update` keyed by `toolCallId`, statuses pending/in_progress/completed/failed) and the `session/request_permission` flow: agent offers options with kinds (allow_once/allow_always/reject_once/reject_always), client answers `selected` + optionId or `cancelled`.

## Key findings

- Permission option kinds map directly onto CAP's `allow_once`/`allow_always`/`deny` decisions (reject kinds collapse to deny).
- Client MAY auto-allow/reject per user settings: tai's orchestrator auto-answer policy has a spec-sanctioned hook here.
- Tool statuses are a 4-state lifecycle with no streaming-output state; output arrives via content on updates.

## Pros / strengths

- Small, closed vocabulary (4 kinds, 4 statuses, 2 outcomes) that translates to CAP events without loss.

## Cons / limitations / caveats

- Read selectively; diff/image/audio content-block variants skimmed, not synthesized.
- No risk-level concept: tai must derive CAP `risk_level` from tool identity/args heuristically.

## Relevance to tai

Permission/response translation table for the ACP driver and the auto-approval hook for research-driven answers.

## Changelog

| Date | Change |
|---|---|
| 2026-10-18 | Initial dossier created. |