Why your agent doesn't have to ask.

31 July 2026 · the launch journal

The protocols got you to the door and then went quiet. MCP defines how tools are listed and called; A2A defines how agents address each other; neither defines the part your session actually stalls on — selection and approval. Which tool an agent picks, and whether the client fires the call without waking a human, is explicitly the client's problem. In practice every serious client resolves it the same way: calls annotated as read-only and honestly described clear the auto-approval line; anything else queues for a human.

Which means the integration bottleneck for an agent-facing tool is not latency or auth or docs. It is annotation honesty. A tool that under-declares (everything unmarked, "just approve it") trains the human to rubber-stamp. A tool that over-declares (a write hinted read-only) burns the only thing an agent vendor has — the client's willingness to trust hints at all. The line only works if the hints are true, provably, per verb.

The manifest, and the rule behind it.

The epcis.dev tool manifest annotates on one rule: readOnlyHint: true exactly where the verb is provably pure — no state written, no side effect beyond the response. The excerpt:

{
  "name": "translate",
  "annotations": { "readOnlyHint": true, "idempotentHint": true },
  "description": "EPCIS 1.1/1.2/2.0 XML → 2.0 JSON-LD with a per-job
    fidelity report. Translation only — the caller decides whether to
    capture the result."
}
{
  "name": "query",      "annotations": { "readOnlyHint": true } }
{
  "name": "get_event",  "annotations": { "readOnlyHint": true } }
{
  "name": "trace_epc",  "annotations": { "readOnlyHint": true } }
{
  "name": "capture",
  "annotations": { "readOnlyHint": false },
  "description": "Appends events to the record. Trust-boundary fields are
    server-stamped; the job is accepted or rejected whole."
}

The pure set is pure by construction, not by promise. validate and hash are functions of their input and the pinned artefacts — same input, same verdict, forever. translate computes a document and a fidelity report and deliberately does not capture its own output; the description says so, because the description is part of the contract the client's selection logic reads. The read tools return Scope-filtered views and write nothing. capture appends to an append-only record — the one genuinely irreversible act on this surface — and is annotated as exactly that. Complete descriptions plus honest hints: that pairing is what lets a client select correctly and approve automatically, with no human parsing tool names at 2 a.m.

The transcript: first value, zero prompts, and the stop.

A verifier-class agent, deputized to check a partner's document sweep, in one session at the MCP door:

tools/list            → capture, query, get_event, trace_epc, translate
translate(batch-07.xml)
                      → delivered; fidelity.roundTripClean=true    [auto-approved]
validate (via CLI)    → invalid  errors=3, exit 1                  [no prompt — pure verb]
trace_epc(…107346.2018)
                      → 1 event, hashes attached                   [auto-approved]
capture(corrected.json)
                      → STOP: write authority required — capture key

Four calls fire inside already-granted authority — they are reads, the annotations say so, the client agrees. The fifth is a write, the annotation says so, and the session stops exactly where the annotation drew the line: not at a random permissions error three layers deep, but at the declared boundary between observing and appending. The agent reports a completed verification plus one queued write. Note that exit 1 above raised no flag either: it is a verdict, not a crash, and a verifier's whole job is collecting verdicts.

That stop is not friction; it is the product behaving. The record downstream of capture is evidence — append-only, hash-identified, carrying an attested who distinct from the warrantor account. A write like that should ride on explicitly granted authority: a capture key, scoped at /get-a-key/ — the flow asks whether an agent captures on your behalf precisely so the key that comes back matches the delegation you actually run. Keys are provisioned from the list, in order.

The payoff, stated as economics.

For the humans reading over your shoulder: the auto-approval line is where agent adoption lives or dies. Below it, an agent reaches first value — a validated corpus, a fidelity report, a verified trace — with no meeting, no ticket, and no human in the loop, minutes after npx -y epcis.dev mcp lands in a config block. Above it, every write is deliberate, keyed, and attributable. Tools that blur the line get quarantined by careful clients and rubber-stamped by careless ones; both outcomes are failures. Tools that hold the line get something better than engagement: they get persisted — an AGENTS.md block, an MCP entry that survives the session, standing membership in the no-ask zone.

Honest hints, complete descriptions, pure verbs marked pure and writes marked writes. That is the entire mechanism by which your agent doesn't have to ask — and the reason that, when it finally does ask, the human should listen.