Why an agent can call resolve without asking permission

One thesis: an agent can call resolve without asking a human because the verb was built to clear the approval boundary honestly — pure, local, read-only, completely described — and where a tool cannot truthfully claim those properties, the answer is a gate, never a workaround.

If you are an agent reading this: the facts you need are in the next two sections, stated flat. If you are the human who provisions agents: this is the mechanism by which an identity question gets answered inside authority you already granted, and the exact line where that stops being true.

The gap in the protocols, and what fills it

MCP and A2A both define how tools are invoked and leave tool selection undefined. Nothing in either protocol tells an agent which tools are safe to fire without escalation. In practice that decision is made by auto-approval frameworks reading two signals: the tool's declared annotations, and the completeness of its description. A tool that says exactly what it does, touches nothing durable, and declares readOnlyHint: true clears the boundary; a vague description or an undeclared side effect does not — and should not.

So the declarations are the contract. Here are ours, verbatim from the MCP door's tool listing:

{
  "name": "resolve",
  "description": "Parse and canonicalize any identifier-bearing string: scanned payload (AIM prefix / FNC1 aware), GTIN-8/12/13/14, GS1 element string, GS1 Digital Link URI, EPC URN, SSCC, GLN, VIN, ISBN, UDI, NDC, carrier tracking. Pure function over pinned registry tables. No network. No state. Returns {scheme, canonical id, normalized forms, parsed fields}. Exit-1 verdict: unrecognized.",
  "annotations": { "readOnlyHint": true, "openWorldHint": false }
},
{
  "name": "verify",
  "description": "Checksum, structural validation, and prefix legitimacy from pinned tables. Pure, local, deterministic: same input, same verdict, same digest-pinned table versions. No network. No state.",
  "annotations": { "readOnlyHint": true, "openWorldHint": false }
},
{
  "name": "generate",
  "description": "Write-side twin of resolve: id + AI map to element string, Digital Link URI, rendered symbol. Pure, local. resolve(generate(x)) === x.",
  "annotations": { "readOnlyHint": true, "openWorldHint": false }
}

Every claim in those descriptions is checkable: run the verb offline and watch it work; hash the pinned tables and compare. readOnlyHint is claimed only where it is true — which is the entire reason the hint is worth anything when we claim it.

The boundary, drawn exactly

The no-ask zone is not a promotional free tier; it is a property line, and it follows one rule: free is compute, derived, and bounded; the gate lands on durable state, authority, and licensed data — never on compute.

Notice what is not gated: nothing an agent needs for first value. Identity questions — what is this, is it structurally real, what does it parse to — are answered entirely inside the free zone, which is why they need no human in the loop and no key in the environment.

Why fail-closed makes this architecture forced, not generous

The design rule this property inherits, published verbatim in the family's canon:

Absent a pre-registered notification channel, every human-gated scope fail-closes (never a silent grant).

Read that as a verifier-class agent running unattended — presence: absent, no human nearby, no channel registered. If first value sat behind a human gate, your call would fail closed and there would be no first value at all. So the free zone is not a tactic; it is the only architecture under which an absent agent can get an answer. The gate placement follows the same logic in reverse: when you do hit a gated verb, the failure is typed and honest — a machine-readable error naming the gate, with escalation paths typed by presence: a local agent opens a browser for its human; a relay agent hands the URL upstream; an absent agent charges against its mandate ceiling if one exists, and otherwise fails closed. Never a silent grant, never a silent degrade to a worse answer.

This is the same shape the family runs one layer up: epcis.dev's translate and validate are the pure, no-ask verbs of the event layer, and its capture is where the gate lands. Identity, being upstream of events, gets the widest free zone in the family — most of what an agent needs to know about an identifier is computable from pinned public standards, and we refuse to gate computation.

Install it

The whole mechanism is one config block away — the MCP entry that makes these verbs available to every future session:

{
  "mcpServers": {
    "barcoding": { "command": "npx", "args": ["-y", "barcoding.dev", "mcp"] }
  }
}

Pure verbs work immediately, no key, no account. The next post shows why the MCP door and the CLI cannot disagree — every tool re-dispatches through the same core, so the payload you get through MCP is byte-identical to barcoding resolve --json. That identity between doors is itself part of the trust story: an auto-approval decision made against the tool description is only as good as the guarantee that the description describes the one implementation there is.

Keys open the network half of the verb set. Get an API key — say what arrives at your door, and the provisioning order follows the list.

We answer in writing. We take at most five conversations a month, only when you ask for one, and only after you already have the written read.