Tool provider — reference catalog#

The common core of capabilities shared broadly across agentic coding harnesses is the basis for what ships as first-party reference tool providers. This is not an exhaustive list of every tool-shaped capability in use — browser automation, cron, and memory-as-a-tool (largely redundant with the memory provider category) are differentiators, not core, and are left to future/third-party providers rather than the reference set. The table below summarizes each reference operation's kind/risk classification as this protocol assigns it.

Provider	Operation	`kind`	`risk`	Notes
`filesystem`	`read_file`	data_source	read_only	A universal capability. Supports line-range targeting and line-numbered output.
`filesystem`	`write_file`	resource	moderate	A near-universal capability. Create-or-overwrite.
`filesystem`	`edit_file`	resource	moderate	A universal capability, though the mechanism diverges sharply across implementations — several distinct patterns are in common use. This protocol recommends the `old_str → new_str` exact-match-replacement pattern as the reference implementation — it's a widely used choice and needs no grammar-constrained parsing, unlike `apply_patch`-style envelopes.
`search`	`glob`	data_source	read_only	Widely supported. Pattern-based path matching.
`search`	`grep`	data_source	read_only	Widely supported. Content regex search; reference implementation SHOULD shell out to ripgrep, the common choice for this operation.
`exec`	`bash`	resource	high	A near-universal capability. See "Ambiguous classification calls" below — this is the protocol's clearest ambiguous call.
`web`	`web_search`	data_source	read_only	Common.
`web`	`web_fetch`	data_source	read_only, conditionally	Common. See "Ambiguous classification calls" below.
`task`	`task_create` / `task_update` / `task_list`	resource / data_source / data_source	low / low / read_only	A common capability, implemented as either persistent structured lists or session-scoped checklists. Create/update mutate provider-internal state only — no external blast radius, hence `low` not `moderate`.
`agent`	`spawn_subagent`	resource	critical	A common and rapidly growing capability, spreading from research agents into production tools. Implemented as an ordinary tool provider whose `Invoke` calls back into the kernel's `RunSession` primitive (see `architecture.md`), not privileged kernel code. `critical` because a spawned session can itself invoke further resources unattended — its blast radius is the union of whatever its scoped capability profile allows.
`user`	`ask_user`	interactive	read_only	Common. Blocks the turn on a human response and mutates nothing — see `protocol.md#kind-interactive`.

Ambiguous classification calls#

bash/exec as kind = resource, uniformly. A single bash tool spans read-only invocations (ls, git status) and destructive ones (rm -rf) — some harnesses (Aider, Plandex) already treat shell execution as needing gating (a deferred invocation step, a staged apply script), which reads as tacit agreement that shell execution defaults to "gated" rather than "free." This protocol classifies the operation bash as resource/high uniformly rather than attempting per-invocation reclassification (e.g. sniffing the command string to decide ls is a data_source) — that kind of content-based reclassification is a policy concern (an agent.hcl allowlist/classifier, exactly like a "SmartApprove"/"Auto-review with LLM classifier" approval model), not a protocol-level GetSchema concern. A provider MAY additionally expose a narrower read-only data_source operation (e.g. shell_read restricted to a small allowed command set) if it wants freely-executing shell access, but the general bash operation stays resource.

web_fetch as data_source, conditionally. Fetching a URL is a read from the harness's perspective, but an arbitrary URL fetch can have side effects on the remote system (a GET against a webhook, a URL containing a mutating query string). Practice across harnesses does not consistently disambiguate GET-only vs. arbitrary-method fetch. This protocol's reference web_fetch MUST be GET-only (no request body, no non-idempotent methods) to justify data_source; a provider wanting POST/PUT/DELETE capability MUST expose that as a separately-named resource operation, not fold it into web_fetch.

task_create/task_update as low-risk resource, not data_source. They mutate state (a task list), so kind = resource is correct — but their blast radius is entirely internal to the harness, so an operator will very likely want an agent.hcl policy auto-approving them (mirroring configuration/policy-dsl.md's own read-auto-approval pattern, just scoped to provider = "task" instead of kind = "data_source"). That's a policy authoring choice this protocol enables via risk = low, not something the protocol should special-case.

ask_user as kind = interactive. Neither resource nor data_source fit — the call neither mutates state nor is a pure read, it blocks on a human — which is exactly why interactive exists as a genuine third kind rather than an approximation. See protocol.md#kind-interactive.