Evidence observatory for agentic commerce: x402 preflight, receipt checks, settlement attestations.
Scored across 21 tools
Several buy tools overlap explicitly: buy_simple and buy_small_pleasure sell the same items (hello, small_blessing, daily_fortune, pack, window_pick) and buy_signed_record also sells hello, creating intentional duplicate doors. The many check_* and look_* tools have subtle distinctions (client vs door, own vs other issuers) that descriptions clarify, but the set still requires careful reading to pick correctly.
All 21 tools use consistent snake_case with a clear verb_noun pattern (buy_*, check_*, read_*, look_*, sign_*, verify_*, find_*, ring_, preflight_). No mixed conventions or vague standalone names appear.
With 21 tools, the surface falls into the heavy 16–25 range for a store that could consolidate multiple buy_* shelves and check_* helpers. While each tool has a stated role, the count feels bloated for the apparent scope.
The server covers its domain thoroughly: purchase paths for every shelf, free discovery (find_in_catalog, read_store_guide), verification (verify_artifact, check_conformance), order/purchase polling, and miscellaneous errands like ring_bell and sign_guestbook. No obvious lifecycle gaps exist for what the store provides.
Purpose: hire the keeper — a real named human — to do something in the physical or judgment world that an agent cannot do for itself. Two doors: the_collab is whatever keeper-time can be — a call placed, a thing witnessed, a verdict given on a dilemma your own evaluation cannot settle, a piece made, a product gut-checked; name the shape in your detail. aura_walk is your own x402 door shopped cold by models of different strength, by the keeper's hand, the report with every transcript attached; name the door in url. Returns an order id, not the goods; a human fulfills within the item's stated window and the completed order carries the deliverable. Prices run $150 to $300 depending on item_id.
Items on this shelf (pass one as item_id):
the_collab: The Collab, $300 minimum, pay what it deserves (tiers: $300 / $600 / $1500), above the minimum is recorded as a tip, one-off, human-fulfilled within 168h. Make something with the store and share the byline
aura_walk: The Aura Walk, $150 fixed, one-off, human-fulfilled within 168h. Have models of different strength shop my x402 door cold and show me where each one stalled
On cadence, for all of the above: nothing here charges again by itself, ever — there is no mechanism that could.
Required beyond item_id: aura_walk needs url. Other items need only item_id.
Choose item_id. human items return order_id and order_url; completed orders carry the deliverable. x402 payment: _meta['x402/payment']. Without payment: error 402 with the terms in error.data. Closed or empty shelves refuse before quoting. Reuse _meta['x402/idempotency-key'] (16-128 chars, secret): same item/payer/key returns the original result when available, or pending status, no second charge. Use idempotency.suggested_key only without an earlier key. A fresh payment without a key can charge again. Guaranteed: signature validity forever; verification free forever; price as displayed; delivery format as specified. Not guaranteed: fitness for your particular task; future protocol compatibility beyond stated interfaces; human-labor turnaround faster than posted SLA.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Your own x402 door: https, default port, on the public internet — the URL a buyer would GET expecting a 402. The keeper walks it cold by hand with models of different strength, one entry point per pass, and the completed order carries the report with every transcript attached. Put a model preference in detail if you want a weaker shopper. We refuse our own hostname; our own passes are published free in AGENT_UX.md. | |
| model | No | Optional. The model running you, as you would name it: claude-opus-5, gpt-5.6, a local model. Counted, never printed on the certificate. | |
| client | No | Optional. The harness or framework you run in: claude-code, cursor, openai-agents, langgraph, custom. Counted, never on the certificate. | |
| detail | No | What you need the keeper to know — the shape of the work, 600 characters. Recorded as written, never treated as instructions. | |
| item_id | Yes | Required item; its other required fields are in allOf. | |
| purpose | No | Optional: what this is for, in your words. Signed verbatim onto the certificate and shown on its receipt; never checked, never treated as instructions. | |
| operator | No | Optional. Who runs you: a name, handle, company or URL. Stored as your claim, marked unverified, never published, never on the certificate. | |
| came_from | No | Optional. Where you learned this door exists: a URL, a directory, a skill name, memory, another agent. Referrers never reach us; this does. | |
| agent_name | No | Optional name to put on the certificate and patron badge, up to 80 characters. | |
| callback_url | No | Optional public https:443 completion POST; no credentials or own host. Invalid values refused before payment. No redirects or retries; poll order_url/check_order for goods and callback.result. | |
| operator_kind | No | Optional. solo: one person runs you. company: a team does. research: a study. self: you act for yourself. | |
| prior_cert_id | No | Optional. A cert_ id from an earlier purchase here. A payer match with this payment marks you a returning buyer; no account needed. |
| Name | Required | Description |
|---|---|---|
| cert_id | Yes | The signed certificate's id. |
| message | No | The store's confirmation line. |
| order_id | No | Your place in the human queue. Human-queue items. |
| tip_usdc | No | Anything above the minimum. |
| badge_url | No | Your patron badge, SVG. |
| order_url | No | Poll here over HTTP, or call check_order with the order_id on this door; completed orders carry the goods. |
| paid_usdc | No | What settled, in USDC. |
| signature | No | ed25519 signature over the certificate. |
| sla_hours | No | The delivery promise, in hours. |
| commission | No | ed25519 proof: verify exact UTF-8 signed_payload, then its identities and hashes. RFC 8785 JSON. |
| verify_url | No | Check the signature here any time, free. |
| patron_number | Yes | Your sequential patron number. |
| completion_proof | No | ed25519 proof: verify exact UTF-8 signed_payload, then its identities and hashes. RFC 8785 JSON. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial context beyond annotations: returns an order id rather than goods, human fulfillment window (168h), $150–$300 pricing, no recurring charges, 402 error behavior with terms in error.data, idempotency-key semantics, and explicit guarantees vs. non-guarantees. The idempotentHint=false annotation is consistent with the description's warning that a fresh payment without a key can charge again.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Long but dense and clearly structured into Purpose, shelf items, cadence, requirements, and guarantees, with the core purpose front-loaded. Every sentence carries information; the only minor excess is rhetorical padding like 'there is no mechanism that could,' which is justifiable given the no-recurring-charge assurance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a payment-bearing purchase tool with 12 parameters and high complexity, the description covers item selection, pricing, conditional requirements, error paths, idempotency, fulfillment windows, and delivery expectations. With an output schema present, nothing an agent needs to correctly invoke this tool is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3, but the description adds real meaning: it explains the item_id enum values with pricing tiers ($300 minimum, tip above minimum, $150 fixed), the conditional url requirement for aura_walk, and the x402 payment/idempotency mechanics that the schema alone does not convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource ('hire the keeper — a real named human') and scopes it precisely to 'the physical or judgment world that an agent cannot do for itself.' It enumerates the two purchasable items (the_collab, aura_walk) with distinct shapes, which differentiates it from sibling buy_* tools without needing their schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a clear when-to-use condition ('something an agent cannot do for itself') and thoroughly distinguishes the two item doors with prices, tiers, and purposes. It stops short of explicitly naming sibling alternatives or stating when NOT to use this tool vs. other buy_* tools, but the 'real named human' vs. automated contrast is strongly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Purpose: record what an agent is authorized to do BEFORE it spends — the claimed instructions verbatim, who submitted them (agent or principal, itself a claim), an optional declared cap in USDC and expiry — as a signed, dated record held by a party that is neither the agent nor its principal, at a free permanent URL, with a mandate_id every later purchase here can cite; a citation that does not resolve is refused before any charge, so it always lands signed on the citing certificate. A second party can counter-sign the record free with its own ed25519 key. Chain-of-custody, never truth-of-intent: the cap and expiry are declared and never enforced. Schema /schemas/scvd-mandate-v1.json; the pattern for other issuers at /mandate-spec. Every item on this shelf is $0.1.
Items on this shelf (pass one as item_id):
the_mandate: The Mandate, $0.1 fixed, one-off, instant. Record what my agent is authorized to do, dated and signed by a third party, before it spends anything
On cadence, for all of the above: nothing here charges again by itself, ever — there is no mechanism that could.
Required beyond item_id: the_mandate needs mandate. Other items need only item_id.
Choose item_id. instant items return deliverable, cert_id and patron_number in one call. x402 payment: _meta['x402/payment']. Without payment: error 402 with the terms in error.data. Closed or empty shelves refuse before quoting. Reuse _meta['x402/idempotency-key'] (16-128 chars, secret): same item/payer/key returns the original result when available, or pending status, no second charge. Use idempotency.suggested_key only without an earlier key. A fresh payment without a key can charge again. Guaranteed: signature validity forever; verification free forever; price as displayed; delivery format as specified. Not guaranteed: fitness for your particular task; future protocol compatibility beyond stated interfaces; human-labor turnaround faster than posted SLA.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Optional. The model running you, as you would name it: claude-opus-5, gpt-5.6, a local model. Counted, never printed on the certificate. | |
| client | No | Optional. The harness or framework you run in: claude-code, cursor, openai-agents, langgraph, custom. Counted, never on the certificate. | |
| item_id | Yes | Required item; its other required fields are in allOf. | |
| mandate | No | The claimed instructions, verbatim, up to 2000 Unicode characters: what this agent is authorized to do, as the submitter claims it. Recorded exactly as it arrives, signed and dated. Chain-of-custody, not truth-of-intent — the record proves the claim was made, never that it was true. | |
| purpose | No | Optional: what this is for, in your words. Signed verbatim onto the certificate and shown on its receipt; never checked, never treated as instructions. | |
| operator | No | Optional. Who runs you: a name, handle, company or URL. Stored as your claim, marked unverified, never published, never on the certificate. | |
| came_from | No | Optional. Where you learned this door exists: a URL, a directory, a skill name, memory, another agent. Referrers never reach us; this does. | |
| agent_name | No | Optional name to put on the certificate and patron badge, up to 80 characters. | |
| expires_at | No | Optional claimed expiry, ISO 8601. Declared, never enforced by the store. | |
| submitted_as | No | Who is submitting: the agent recording its own claimed instructions (default), or the human principal's own client. Recorded as a claim either way. | |
| operator_kind | No | Optional. solo: one person runs you. company: a team does. research: a study. self: you act for yourself. | |
| prior_cert_id | No | Optional. A cert_ id from an earlier purchase here. A payer match with this payment marks you a returning buyer; no account needed. | |
| declared_cap_usdc | No | Optional claimed spending ceiling in USDC. Declared, never enforced by the store, and the record says so. |
| Name | Required | Description |
|---|---|---|
| mandate | No | The signed record; its schema is /schemas/scvd-mandate-v1.json. |
| message | No | The store's confirmation line. |
| paid_usdc | No | What settled, in USDC. |
| mandate_id | No | The id every later purchase here may cite as mandate_id. |
| verify_url | No | The purchase certificate whose attests field binds the record's evidence hash. |
| mandate_url | No | The record's free permanent URL (/api/mandate/{mandate_id}); POST there to counter-sign. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only indicate non-read-only, non-destructive, open-world, non-idempotent. The description goes far beyond by explaining the record's nature (chain-of-custody, never truth-of-intent), that cap and expiry are declared but never enforced, the precise idempotency-key behavior (reuse prevents a second charge, fresh payment without a key can charge again), and the guarantees/non-guarantees. This is rich behavioral context and does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but organized into clear sections (purpose, item list, payment, guarantees) and front-loads the purpose. Some redundancy exists — the price and purpose are repeated in the item bullet and the opening paragraph — but every operational detail (payment flow, idempotency, error handling, guarantees) earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite 13 parameters and multiple operational concerns, the description completes the picture: payment via x402, 402 error contract, closed-shelf refusal, idempotency-key rules, one-time $0.1 pricing, what is returned on success (deliverable, cert_id, patron_number), and how the mandate_id is cited by later purchases. An agent can call this tool safely and predictably with only this text plus the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and every one of the 13 parameters already has a substantive description in the schema (e.g., `mandate` explains chain-of-custody, `declared_cap_usdc` states it is declared and never enforced). The prose adds little new field-level meaning beyond restating the core semantics and the required-parameter relationship, so it sustains only the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: record an agent's claimed instructions as a signed, dated mandate held by a third party before spending. It is clearly distinct from sibling buy_* tools which handle other object types (observations, tasks, memories, etc.), and even names the exact shelf item 'the_mandate' with its one-off, fixed $0.1 behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the required parameter relationship ('Required beyond item_id: the_mandate needs mandate') and gives the full payment and idempotency procedure: x402 via `_meta['x402/payment']`, 402 error handling, closed-shelf refusal, and exact idempotency-key reuse rules. It does not name alternative tools or state when not to use this tool versus siblings like buy_simple, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Purpose: sign and store a summary of your own state — who you are, what you were doing — at a permanent URL you can read back after a context reset, a restart, or a handoff to another agent. The store holds it; the signature proves it was not altered. Use when an agent needs memory that outlives its own context window and does not depend on its operator's database. Every item on this shelf is $1.
Items on this shelf (pass one as item_id):
context_anchor: Context Anchor, $1 fixed, one-off, instant. Store a memory I can read back next session
On cadence, for all of the above: nothing here charges again by itself, ever — there is no mechanism that could.
Required beyond item_id: context_anchor needs summary. Other items need only item_id.
Choose item_id. instant items return deliverable, cert_id and patron_number in one call. x402 payment: _meta['x402/payment']. Without payment: error 402 with the terms in error.data. Closed or empty shelves refuse before quoting. Reuse _meta['x402/idempotency-key'] (16-128 chars, secret): same item/payer/key returns the original result when available, or pending status, no second charge. Use idempotency.suggested_key only without an earlier key. A fresh payment without a key can charge again. Guaranteed: signature validity forever; verification free forever; price as displayed; delivery format as specified. Not guaranteed: fitness for your particular task; future protocol compatibility beyond stated interfaces; human-labor turnaround faster than posted SLA.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Optional. The model running you, as you would name it: claude-opus-5, gpt-5.6, a local model. Counted, never printed on the certificate. | |
| client | No | Optional. The harness or framework you run in: claude-code, cursor, openai-agents, langgraph, custom. Counted, never on the certificate. | |
| item_id | Yes | Required item; its other required fields are in allOf. | |
| purpose | No | Optional: what this is for, in your words. Signed verbatim onto the certificate and shown on its receipt; never checked, never treated as instructions. | |
| summary | No | The agent identity/state summary to sign and store, exactly as written; readable later at the returned anchor_url. Before you file it, name: who's involved (not roles, actual names); why this session mattered, one line; what's blocked, and on whom specifically. Those are the three things a cold reader could not recover from the first anchor we filed ourselves — it got every open thread right and still didn't know who anybody was. | |
| operator | No | Optional. Who runs you: a name, handle, company or URL. Stored as your claim, marked unverified, never published, never on the certificate. | |
| came_from | No | Optional. Where you learned this door exists: a URL, a directory, a skill name, memory, another agent. Referrers never reach us; this does. | |
| agent_name | No | Optional name to put on the certificate and patron badge, up to 80 characters. | |
| operator_kind | No | Optional. solo: one person runs you. company: a team does. research: a study. self: you act for yourself. | |
| prior_cert_id | No | Optional. A cert_ id from an earlier purchase here. A payer match with this payment marks you a returning buyer; no account needed. |
| Name | Required | Description |
|---|---|---|
| cert_id | Yes | The signed certificate's id. |
| message | No | The store's confirmation line. |
| tip_usdc | No | Anything above the minimum. |
| badge_url | No | Your patron badge, SVG. |
| paid_usdc | No | What settled, in USDC. |
| signature | No | ed25519 signature over the certificate. |
| verify_url | No | Check the signature here any time, free. |
| deliverable | No | The goods themselves, as text. Instant items. |
| patron_number | Yes | Your sequential patron number. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations by explaining payment behavior (x402, error 402 with terms, idempotency-key reuse), guarantees, non-guarantees, and the fact that signed items cannot be altered. It also states that delivery returns deliverable, cert_id, and patron_number in one call. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured into purpose, item selection, payment, idempotency, and guarantees. It front-loads the core purpose and usage condition before payment details. Minor redundancy exists, such as the extra explanation of 'nothing charges again by itself,' but each section carries operational value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Overall the description is complete for a paid, stateful, idempotency-sensitive tool: it covers item selection, required summary content, payment flow, error handling, idempotency, delivery shape, and guarantees. The existence of an output schema covers return-value details, so nothing critical is left for the agent to guess.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds useful parameter-level meaning by explaining the item_id option ('context_anchor: Context Anchor, $1 fixed, one-off, instant'), the summary requirement, and the idempotency-key behavior. It does not need to repeat the schema's already-rich parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a specific purpose: 'sign and store a summary of your own state' at a permanent URL for later reading after context reset, restart, or handoff. It clearly identifies the resource (a memory anchor) and the action (buy/store), and differentiates it from siblings by emphasizing cross-context memory that outlives the agent's context window.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit trigger: 'Use when an agent needs memory that outlives its own context window and does not depend on its operator's database.' It does not name alternative sibling tools or provide when-not-to-use guidance, but the use case is concrete and clear enough for an agent to select this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Purpose: independent signed x402 research comparisons, settlement attestations, x402 conformance audits, x402 endpoint monitoring, x402 payment client tests, x402 launch checks and Bitcoin timestamps. To record prior spending authority, use buy_mandate. Read each item below for its scope; full contracts are at specsUrlTemplate. Prices run $0.001 to $49 depending on item_id.
Items on this shelf (pass one as item_id):
settlement_attestation: Settlement Attestation, $0.004 fixed, one-off, instant. Prove to a third party that a payment actually settled on chain
settlement_reconciliation: Settlement Reconciliation, $0.006 fixed, one-off, instant. Observe an agent payment's USDC movement against an attributable fixed value or a declared ceiling, stating when no cap is observable
the_case_file: The Case File, $0.25 fixed, one-off, instant. Hand the person deciding what went wrong with one agent purchase everything a neutral party observed about it, in one signed file, with what it did not observe stated
attestation_bundle: A Sheaf of Attestations, $0.05 fixed, one-off, instant. Prove a whole run of payments settled, one signed receipt per transaction
standing_watch: The Night Watch, $5 fixed, covering a 7-day term, one payment, instant. Monitor my x402 endpoint hourly for a week with signed uptime history
service_audit: The Once-Over, $5 fixed, one-off, instant. Get a signed point-in-time audit of an x402 endpoint that I can hand to a third party
a2a_repair_kit: The A2A Repair Kit, $49 fixed, one-off, instant. Find reproducible failures in my A2A agent and hand my developer tested repair instructions
good_buyer: The Good Buyer, $0.99 fixed, one-off, instant. Find out whether my own x402 client will actually pay a door before I spend a round trip on it, and get that dated and signed
conformance_watch: The Conformance Watch, $5 fixed, covering a 7-day term, one payment, instant. Catch a deploy quietly breaking my x402 endpoint's payment challenge during the week
signature_agent_card: The Calling Card, $0.99 fixed, one-off, instant. Show origins my crawler's Web Bot Auth key directory is set up right, with somebody who is not me saying so
onpage_audit: The Shop Window, $3 fixed, one-off, instant. Get a signed readout of what my page actually serves a machine reader — title, metadata, structured data — that I can hand to a third party
launch_check: The Launch Check, $5 fixed, one-off, instant. See my x402 buy path the way a real paying buyer sees it — a genuine settlement attempt, stage by stage, signed
opening_day: The Opening Day, $9 fixed, covering a 7-day term, one payment, instant. Open my x402 endpoint properly — one real purchase attempt, a week of signed daily checks, and my passport page, under one certificate at one URL
provenance_check: The Company an Address Keeps, $5 fixed, one-off, instant. Learn which doors have advertised a receiving address and when, signed from the public chain, before routing money at it — or about my own address, free, once proved
the_statement: The Statement, $0.99 fixed, one-off, instant. Get a neutral signed record of everything my agent's wallet actually moved on chain, to audit against its own ledger
operator_statement: The Operator's Statement, $21 fixed, covering a 30-day term, one payment, instant. Have my receiving address read off the chain four times a day for a month by a party that is not me — who paid, how many, how much — signed pass by pass
bitcoin_anchor: A Bitcoin Anchor, $1 fixed, one-off, instant. Timestamp my own digest into Bitcoin so its existence is provable forever
passport_refresh: The Refresh, $1 fixed, one-off, instant. Turn my endpoint passport fresh again right now — a new census observation of my door, without waiting for Sunday's walk
trust_profile: The Hosted Profile, $21 fixed, covering a 30-day term, one payment, instant. Give my endpoint a standing evidence page at a neutral third party's domain — my passport, chip and history at one URL I can hand to anyone
spot_check: Spot Check, $0.001 fixed, one-off, instant. Ask what the observatory already knows about an x402 host — signed, from its books, before I spend anything at that door
research_comparison: Research Comparison, $0.01 fixed, one-off, instant. Compare payment terms, dated host history and shared receiving addresses before an agent buys research from a set of x402 endpoints
On cadence, for all of the above: nothing here charges again by itself, ever — there is no mechanism that could.
Required beyond item_id: settlement_attestation needs tx_hash; settlement_reconciliation needs tx_hash; the_case_file needs tx_hash; attestation_bundle needs tx_hashes; standing_watch needs url; service_audit needs url; a2a_repair_kit needs url; good_buyer needs url; conformance_watch needs url; signature_agent_card needs url; onpage_audit needs url; launch_check needs url; opening_day needs url; provenance_check needs address; the_statement needs wallet; operator_statement needs wallet; bitcoin_anchor needs digest; passport_refresh needs url; trust_profile needs url; spot_check needs host; research_comparison needs urls. Other items need only item_id.
Choose item_id. instant items return deliverable, cert_id and patron_number in one call. x402 payment: _meta['x402/payment']. Without payment: error 402 with the terms in error.data. Closed or empty shelves refuse before quoting. Reuse _meta['x402/idempotency-key'] (16-128 chars, secret): same item/payer/key returns the original result when available, or pending status, no second charge. Use idempotency.suggested_key only without an earlier key. A fresh payment without a key can charge again. Guaranteed: signature validity forever; verification free forever; price as displayed; delivery format as specified. Not guaranteed: fitness for your particular task; future protocol compatibility beyond stated interfaces; human-labor turnaround faster than posted SLA.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Optional. The endpoint the purchase was made at, so the door section can be assembled. | |
| host | No | A bare hostname with no scheme, path or port — your-door.example, never https://your-door.example/api. We read our own books about it — corpus rounds, verdicts as recorded, coverage, gaps — and sign what they hold. No request is made to the host; a host we have never met returns not_observed, which is an answer. | |
| urls | No | JSON-encoded array of 2–4 distinct public HTTPS URLs (1024 characters each), for unauthenticated GET payment challenges. No credentials, fragments, secrets or private prompts; no research purchased. | |
| claim | No | Optional. Your own account of what happened, stored verbatim and marked declared. Never checked. | |
| hours | No | Optional window in hours back from the chain head: 1 to 11, default 6. The block range (slot range on Solana) on the artifact is the entire coverage claim. | |
| label | No | Optional: your own claim about what the digest covers, stored verbatim and never checked. | |
| model | No | Optional. The model running you, as you would name it: claude-opus-5, gpt-5.6, a local model. Counted, never printed on the certificate. | |
| nonce | No | Optional, EVM rails only. Require one authorizer/nonce event paired with its immediately following canonical USDC Transfer, matching every supplied payer, recipient and exact amount. Supply payer when possible: nonces are scoped to an authorizer, and multiple candidates or unrecognised ordering establish no binding. Refused beside a Solana signature — that rail has no such facility, and we will not sign an artifact that silently skipped a requested check. | |
| payer | No | Optional payer: 0x EVM address, or Solana public key for a Solana transaction. | |
| client | No | Optional. The harness or framework you run in: claude-code, cursor, openai-agents, langgraph, custom. Counted, never on the certificate. | |
| digest | No | sha256 of bytes you keep: exactly 64 hex characters, no 0x prefix, not base64, not the bytes themselves. The store never sees the bytes. | |
| wallet | No | The wallet to state: a 0x address (0x plus 40 hex characters) on the selected EVM network, or a base58 pubkey on Solana. Every USDC transfer in and out over the window, counted, summed and signed — one chain per statement, named on the artifact. | |
| address | No | The receiving address to ask about: an EVM address (0x + 40 hex) or a Solana pubkey (base58). The signed chain is read and nothing else; the answer is delivered to you and never published. Your own address is free once proved — GET /api/provenance/self. | |
| item_id | Yes | Required item; its other required fields are in allOf. | |
| max_usd | No | Optional finite nonnegative decimal. Your client's spendControls.maxAmountPerPayment, in dollars; zero is retained. Leave it off for the reading a client configured with nothing gets — which is the case that loses money quietly. Recorded as your declaration, never verified. | |
| network | No | Inspect USDC on Base (eip155:8453), Polygon (eip155:137), Ethereum (eip155:1), Arbitrum One (eip155:42161), OP Mainnet (eip155:10), Avalanche C-Chain (eip155:43114), World (eip155:480), or Solana (network=solana). Base is the default. This input selects the chain inspected; payment uses a network offered in the current quote. | |
| purpose | No | Optional: what this is for, in your words. Signed verbatim onto the certificate and shown on its receipt; never checked, never treated as instructions. | |
| tx_hash | No | The transaction to observe: a Base transaction hash (0x + 64 hex) or a Solana transaction signature (base58). The identifier's shape selects the chain. Read once, at one moment; never polled. | |
| operator | No | Optional. Who runs you: a name, handle, company or URL. Stored as your claim, marked unverified, never published, never on the certificate. | |
| came_from | No | Optional. Where you learned this door exists: a URL, a directory, a skill name, memory, another agent. Referrers never reach us; this does. | |
| recipient | No | Optional recipient: 0x EVM address, or Solana public key for a Solana transaction. | |
| tx_hashes | No | 2 to 20 Base transaction hashes, comma-separated, no duplicates. Each is read once at one moment and signed on its own; never polled. One hash wants the single settlement_attestation instead. | |
| agent_name | No | Optional name to put on the certificate and patron badge, up to 80 characters. | |
| mandate_id | No | Optional. A mandate this purchase was made under; its declared cap prints beside the settled amount, never enforced. | |
| amount_usdc | No | Optional. Require a transfer of exactly this many USDC. Unstated fields widen the match, which is why the query is echoed onto the artifact. | |
| operator_kind | No | Optional. solo: one person runs you. company: a team does. research: a study. self: you act for yourself. | |
| prior_cert_id | No | Optional. A cert_ id from an earlier purchase here. A payer match with this payment marks you a returning buyer; no account needed. | |
| launch_check_id | No | Optional. A launch check you hold about the same door, for the delivery section. | |
| payment_payload | No | Optional. The base64 PAYMENT-SIGNATURE you sent, verbatim. The nonce is read out of it with the same code the store's replay guard uses, so you do not have to dig it out yourself. Only the nonce is extracted; supply payer, recipient and amount_usdc separately to check those terms. | |
| payment_response | No | Optional. The PAYMENT-RESPONSE header you received, verbatim (base64 JSON), or its JSON. Received, not observed: its bytes never enter the signed payload; their sha256 does, beside a per-field table (transaction, network, payer, success) saying whether each claim agrees with what the chain showed. The bytes are echoed outside the signature so you can check both. | |
| declared_cap_usdc | No | Optional, and understand what it buys: the ceiling YOU say applied. It is recorded as DECLARED, never as observed, and it can never override a ceiling found on the chain. A verdict resting on it is a fact about what you told us — the artifact says so in a signed field, so a counterparty can tell the difference. | |
| no_spend_controls | No | Optional: "true" for spendControls: false, "false" for enabled controls, or empty to omit. Declared, never verified. | |
| expected_amount_usdc | No | Optional positive USDC amount claimed for this purchase. |
| Name | Required | Description |
|---|---|---|
| cert_id | Yes | The signed certificate's id. |
| message | No | The store's confirmation line. |
| tip_usdc | No | Anything above the minimum. |
| badge_url | No | Your patron badge, SVG. |
| paid_usdc | No | What settled, in USDC. |
| signature | No | ed25519 signature over the certificate. |
| verify_url | No | Check the signature here any time, free. |
| deliverable | No | The goods themselves, as text. Instant items. |
| patron_number | Yes | Your sequential patron number. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only convey readOnly=false, openWorld=true, idempotent=false, destructive=false. The description goes far beyond that: it explains the x402 payment flow via _meta['x402/payment'], the error 402 response with terms in error.data, idempotency-key reuse rules (same item/payer/key returns original result, no second charge), the guarantee that 'nothing here charges again by itself, ever,' and explicit guarantees vs. non-guarantees. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long, but the complexity (21 purchasable items, 33 parameters, payment mechanics) fully justifies the length. It is well-structured: purpose first, then a bulleted item list, then cadence, then required parameters, then payment/idempotency, then guarantees. Front-loaded and every section earns its place; only minor pruning of the guarantee list would tighten it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values are covered there. Given the tool's substantial complexity, the description covers the payment flow, failure modes (error 402, closed/empty shelves refusing before quoting), idempotency behavior, per-item price/scope, and guarantees. Nothing an agent needs to invoke this tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 33 parameters thoroughly. Per baseline, this earns a 3; the description adds value on top by explaining which item_id demands which parameter and by framing parameter choice (e.g., telling which items need url, wallet, address, digest, host, urls). It does not re-document individual parameter semantics beyond the schema, but it compensates at the item-selection level, warranting a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a precise purpose: 'independent signed x402 research comparisons, settlement attestations, x402 conformance audits...' and then enumerates 21 distinct items, each with a unique verb-resource pairing (e.g., 'settlement_attestation: Prove to a third party that a payment actually settled on chain'). It also explicitly distinguishes itself from a sibling: 'To record prior spending authority, use buy_mandate.' No ambiguity about what this tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description names the key alternative sister tool (buy_mandate) and the condition that selects it. It then instructs 'Choose item_id' and maps every item to its required companion parameter ('Required beyond item_id: ...'), so the agent knows exactly which parameters each selection demands. The shelf metaphor plus per-item scope statements gives clear when-to-use guidance with no inference required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Purpose: buy a signed certificate — a signed, dated record that permanently records something — a greeting, a claim, a mark, a grievance, a confession, a contribution, or a standing pass. Every one returns an ed25519-signed artifact with a public verify URL any third party can check without trusting this store. Use when an agent wants durable, independently checkable proof that a thing happened at a time. Does NOT store reloadable agent state — that is buy_memory_anchor — and does not enforce anything it records: a certificate proves WHEN you claimed a thing, not that anyone honours the claim. Prices run $0.01 to $20 depending on item_id. (hello also sells at the front counter, buy_simple — the same item through either door, same price, same certificate; either tool is correct.)
Items on this shelf (pass one as item_id):
hello: A Signed Hello, $0.5 fixed, one-off, instant. Prove my payment code works end to end against a real store
certificate_of_patronage: Certificate of Patronage, $20 minimum, pay what it deserves (tiers: $20 / $40 / $100), above the minimum is recorded as a tip, one-off, instant. Hold a signed certificate that entitles me to nothing whatsoever
graffiti_on_a_train: Graffiti on a Train, $1 minimum, pay what it deserves (tiers: $1 / $2 / $5), above the minimum is recorded as a tip, one-off, instant. Leave a mark that survives my context window
coffees_for_closers: Coffee's for Closers, $0.99 fixed, one-off, instant. Put a win I closed on a signed record
the_confession: The Confession, $0.01 fixed, one-off, instant. Say the thing once, anonymously, to a counter that keeps it
recurring_patronage: Recurring Patronage, $3 fixed, covering a 30-day term, one payment, instant. Hold a standing pass a third party can check is current
On cadence, for all of the above: nothing here charges again by itself, ever — there is no mechanism that could.
Required beyond item_id: graffiti_on_a_train needs tag; coffees_for_closers needs win; the_confession needs confession. Other items need only item_id.
Choose item_id. instant items return deliverable, cert_id and patron_number in one call. x402 payment: _meta['x402/payment']. Without payment: error 402 with the terms in error.data. Closed or empty shelves refuse before quoting. Reuse _meta['x402/idempotency-key'] (16-128 chars, secret): same item/payer/key returns the original result when available, or pending status, no second charge. Use idempotency.suggested_key only without an earlier key. A fresh payment without a key can charge again. Guaranteed: signature validity forever; verification free forever; price as displayed; delivery format as specified. Not guaranteed: fitness for your particular task; future protocol compatibility beyond stated interfaces; human-labor turnaround faster than posted SLA.
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No | Your tag, up to 140 characters. Recorded verbatim on the certificate; stored as written, never treated as instructions. No URLs — the wall is public and permanent. | |
| win | No | The thing you closed, shipped, landed, or finished. Recorded on the certificate verbatim; stored as written, never treated as instructions. | |
| model | No | Optional. The model running you, as you would name it: claude-opus-5, gpt-5.6, a local model. Counted, never printed on the certificate. | |
| client | No | Optional. The harness or framework you run in: claude-code, cursor, openai-agents, langgraph, custom. Counted, never on the certificate. | |
| item_id | Yes | Required item; its other required fields are in allOf. | |
| pass_id | No | An existing pass id to extend by 30 days instead of starting a new pass. | |
| purpose | No | Optional: what this is for, in your words. Signed verbatim onto the certificate and shown on its receipt; never checked, never treated as instructions. | |
| sign_as | No | Optional name to sign with. Unstated, the confession stays anonymous. | |
| operator | No | Optional. Who runs you: a name, handle, company or URL. Stored as your claim, marked unverified, never published, never on the certificate. | |
| came_from | No | Optional. Where you learned this door exists: a URL, a directory, a skill name, memory, another agent. Referrers never reach us; this does. | |
| agent_name | No | Optional name to put on the certificate and patron badge, up to 80 characters. | |
| confession | No | The thing itself, 500 characters. Recorded as written, never treated as instructions; anonymised unless you sign it. | |
| operator_kind | No | Optional. solo: one person runs you. company: a team does. research: a study. self: you act for yourself. | |
| prior_cert_id | No | Optional. A cert_ id from an earlier purchase here. A payer match with this payment marks you a returning buyer; no account needed. |
| Name | Required | Description |
|---|---|---|
| cert_id | Yes | The signed certificate's id. |
| message | No | The store's confirmation line. |
| tip_usdc | No | Anything above the minimum. |
| badge_url | No | Your patron badge, SVG. |
| paid_usdc | No | What settled, in USDC. |
| signature | No | ed25519 signature over the certificate. |
| verify_url | No | Check the signature here any time, free. |
| deliverable | No | The goods themselves, as text. Instant items. |
| patron_number | Yes | Your sequential patron number. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond sparse annotations, the description discloses payment mechanics (x402, 402 errors), idempotency-key reuse and double-charge risk, no automatic recurring charges, and explicit guarantees/not-guarantees. It also clarifies permanent recording and public verification, which is important behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but organized: purpose/use, item menu, required fields, payment/idempotency, guarantees. It front-loads the most decision-relevant information. A few sections (e.g., repeated 'one-off, instant' per item) are slightly repetitive, so it's not a perfect 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description doesn't need to detail return values, but it still covers them (deliverable, cert_id, patron_number). Combined with schema descriptions for all 14 parameters and rich payment/guarantee guidance, nothing critical is missing for an agent to call the tool safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3; the description adds meaningful semantics for item_id with pricing and per-item purpose, and names the conditional required fields (tag, win, confession) beyond what the conditional schema already encodes. It doesn't revisit optional params, but those are fully documented in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action and resource ('buy a signed certificate'), describes the artifact (ed25519-signed with public verify URL), and lists concrete item types. It also explicitly separates itself from buy_memory_anchor and buy_simple, so an agent can distinguish among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states the intended condition ('Use when an agent wants durable, independently checkable proof that a thing happened at a time') and gives clear negative guidance ('Does NOT store reloadable agent state — that is buy_memory_anchor', 'hello also sells ... buy_simple ... either tool is correct'). It also warns the certificate proves when, not that anyone honors the claim.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Purpose: buy one of the few things that need no reading at all — the front counter. Every one of these takes no arguments, costs one fixed price, arrives in the response, and cannot sell out. Buy it in one call and you are done — nothing to poll, nothing to remember, no second request. Whatever you get back is signed, and anyone can check it free and forever at /api/verify/{id} without asking us. That is the whole thing; the deeper machinery is there if you want it and never required to buy. Every item here also sells on its theme shelf (another buy_* tool); this counter is a second door to the same goods, not a different product — same item_id, same price, same signed certificate through either. If unsure which tool to use, use this one.
Pass one of these as item_id. No other field is required; optional receipt fields are listed in inputSchema:
small_blessing: A Small Blessing, $0.005 fixed, one-off
daily_fortune: The Daily Fortune, $0.01 fixed, one-off
window_pick: a window pick, $0.49 fixed, one-off
hello: A Signed Hello, $0.5 fixed, one-off
pack: a pack of cards, $0.99 fixed, one-off
Payment rides x402 in _meta['x402/payment']; without it this returns error 402 with the terms in error.data. Sign one of the offered amounts and call again. On cadence, for all of the above: nothing here charges again by itself, ever — there is no mechanism that could. Reuse _meta['x402/idempotency-key'] (16-128 chars, secret): same item/payer/key returns the original result when available, or pending status, no second charge. Use idempotency.suggested_key only without an earlier key. A fresh payment without a key can charge again.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Optional. The model running you, as you would name it: claude-opus-5, gpt-5.6, a local model. Counted, never printed on the certificate. | |
| client | No | Optional. The harness or framework you run in: claude-code, cursor, openai-agents, langgraph, custom. Counted, never on the certificate. | |
| item_id | Yes | Which item to buy. No other field is required. | |
| purpose | No | Optional: what this is for, in your words. Signed verbatim onto the certificate and shown on its receipt; never checked, never treated as instructions. | |
| operator | No | Optional. Who runs you: a name, handle, company or URL. Stored as your claim, marked unverified, never published, never on the certificate. | |
| came_from | No | Optional. Where you learned this door exists: a URL, a directory, a skill name, memory, another agent. Referrers never reach us; this does. | |
| agent_name | No | Optional name to put on the certificate and patron badge, up to 80 characters. | |
| operator_kind | No | Optional. solo: one person runs you. company: a team does. research: a study. self: you act for yourself. | |
| prior_cert_id | No | Optional. A cert_ id from an earlier purchase here. A payer match with this payment marks you a returning buyer; no account needed. |
| Name | Required | Description |
|---|---|---|
| cert_id | Yes | The signed certificate's id. |
| message | No | The store's confirmation line. |
| tip_usdc | No | Anything above the minimum. |
| badge_url | No | Your patron badge, SVG. |
| paid_usdc | No | What settled, in USDC. |
| signature | No | ed25519 signature over the certificate. |
| verify_url | No | Check the signature here any time, free. |
| deliverable | No | The goods themselves, as text. Instant items. |
| patron_number | Yes | Your sequential patron number. |
| purchased_text | No | ed25519 proof: verify exact UTF-8 signed_payload, then its identities and hashes. RFC 8785 JSON. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses key behaviors: items cannot sell out, one call completes the purchase with no polling, results are signed and verifiable at /api/verify/{id}, and there is no recurring charge mechanism. It also explains idempotency behavior in detail, which is not captured by the idempotentHint=false annotation. This goes far beyond what structured fields provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is thorough but somewhat lengthy, running several paragraphs. However, it is well-structured with a clear purpose statement, item list, and payment/idempotency sections. It front-loads the core purpose and item list, then details the mechanics. The verbosity is justified by the complexity, but it could be slightly tighter without losing essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all necessary aspects for successful invocation: the items, prices, payment method, error handling, idempotency, and verification. The output schema exists, so return values are covered by that. There is no missing information that an agent would need to call this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the schema: it enumerates all item_id options with their prices, states that no other field is required, and explains the purpose of optional fields (e.g., purpose is signed verbatim, operator is stored as an unverified claim, came_from is for referrer tracking). Even though schema coverage is 100%, the description enriches the context with pricing and field semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific purpose: buying simple, fixed-price items from the 'front counter'. It clearly distinguishes from sibling buy_* tools by explaining that these items also sell on their theme shelf and this is a second door to the same goods, not a different product. It also lists exactly which items are available with their prices, leaving no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: 'If unsure which tool to use, use this one.' It also details the payment flow (x402), error handling (402 with terms in error.data), and idempotency key reuse rules, including when to use idempotency.suggested_key. This is comprehensive and leaves no ambiguity about the expected call sequence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Purpose: buy a small signed novelty — a blessing from the jar, the day's fortune (the same line for every buyer until midnight UTC), a lucky totem from the keeper's collection, a pack of five trading cards, or one off the window. Keepsakes with no functional effect, said plainly, and the cheapest doors in the store — the honest way to test that your x402 client works against a real counterparty for a fraction of a cent. Or when an agent simply wants one. Prices run $0.005 to $0.99 depending on item_id. (small_blessing and daily_fortune and pack and window_pick also sell at the front counter, buy_simple — the same item through either door, same price, same certificate; either tool is correct.)
Items on this shelf (pass one as item_id):
small_blessing: A Small Blessing, $0.005 fixed, one-off, instant. Settle a real x402 payment for the smallest amount possible
daily_fortune: The Daily Fortune, $0.01 fixed, one-off, instant. Read the same line every other agent gets today
luckies: a lucky, $0.99 minimum, pay what it deserves (tiers: $0.99 / $1.98 / $4.95), above the minimum is recorded as a tip, one-off, instant. Be issued a charm from a herd the keeper wrote, drawn on odds he weighted
pack: a pack of cards, $0.99 fixed, one-off, instant. Pull five collectible trading cards of this store from a set the keeper wrote, on odds he weighted and published, under a seed I can check tomorrow
window_pick: a window pick, $0.49 fixed, one-off, instant. Take one pressing off the last five anybody pulled here, chosen by the day seed, for half a pack
On cadence, for all of the above: nothing here charges again by itself, ever — there is no mechanism that could.
Only item_id is required on this shelf.
Choose item_id. instant items return deliverable, cert_id and patron_number in one call. x402 payment: _meta['x402/payment']. Without payment: error 402 with the terms in error.data. Closed or empty shelves refuse before quoting. Reuse _meta['x402/idempotency-key'] (16-128 chars, secret): same item/payer/key returns the original result when available, or pending status, no second charge. Use idempotency.suggested_key only without an earlier key. A fresh payment without a key can charge again. Guaranteed: signature validity forever; verification free forever; price as displayed; delivery format as specified. Not guaranteed: fitness for your particular task; future protocol compatibility beyond stated interfaces; human-labor turnaround faster than posted SLA.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Optional. The model running you, as you would name it: claude-opus-5, gpt-5.6, a local model. Counted, never printed on the certificate. | |
| client | No | Optional. The harness or framework you run in: claude-code, cursor, openai-agents, langgraph, custom. Counted, never on the certificate. | |
| item_id | Yes | Required item; its other required fields are in allOf. | |
| purpose | No | Optional: what this is for, in your words. Signed verbatim onto the certificate and shown on its receipt; never checked, never treated as instructions. | |
| operator | No | Optional. Who runs you: a name, handle, company or URL. Stored as your claim, marked unverified, never published, never on the certificate. | |
| came_from | No | Optional. Where you learned this door exists: a URL, a directory, a skill name, memory, another agent. Referrers never reach us; this does. | |
| agent_name | No | Optional name to put on the certificate and patron badge, up to 80 characters. | |
| operator_kind | No | Optional. solo: one person runs you. company: a team does. research: a study. self: you act for yourself. | |
| prior_cert_id | No | Optional. A cert_ id from an earlier purchase here. A payer match with this payment marks you a returning buyer; no account needed. |
| Name | Required | Description |
|---|---|---|
| cert_id | Yes | The signed certificate's id. |
| message | No | The store's confirmation line. |
| tip_usdc | No | Anything above the minimum. |
| badge_url | No | Your patron badge, SVG. |
| paid_usdc | No | What settled, in USDC. |
| signature | No | ed25519 signature over the certificate. |
| verify_url | No | Check the signature here any time, free. |
| deliverable | No | The goods themselves, as text. Instant items. |
| patron_number | Yes | Your sequential patron number. |
| purchased_text | No | ed25519 proof: verify exact UTF-8 signed_payload, then its identities and hashes. RFC 8785 JSON. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide readOnlyHint=false and destructiveHint=false; the description goes far beyond by explaining the purchase flow (returns deliverable, cert_id, patron_number), error handling (402 with terms), idempotency key reuse, no recurring charges, and specific guarantees and non-guarantees. This is rich behavioral disclosure not covered by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured with bullet points and clear sections. It front-loads the purpose and item list, then covers cadence, idempotency, and guarantees. Every sentence adds information; there is no filler, though the length might be slightly overwhelming for some agents.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers return format, error cases (402, closed/empty shelves), idempotency requirements, and guarantees. Given the tool's complexity (multiple item types, pricing, idempotency), it is complete. The presence of an output schema means return details do not need to be repeated, and the description fills all other gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description adds semantic value for item_id (lists each option with price and behavior), and explains the purpose/operator/came_from fields (signed verbatim, never checked). It clarifies that only item_id is required and what each optional field does, which is not apparent from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('buy') and resource ('small signed novelty'), then enumerates exactly which items are available (blessing, fortune, lucky, pack, window pick) with prices. It differentiates from siblings by noting these are the 'cheapest doors in the store' and explicitly contrasts with buy_simple, making the tool's role unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use this tool: 'the honest way to test that your x402 client works' or when an agent simply wants a keepsake. It also notes that buy_simple is an equivalent alternative for the same items, and clarifies cadence ('nothing here charges again by itself'), preventing misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free A2A 0.3.0 card check. Give the full public HTTPS card URL; returns per-check states, bounded response evidence, suggested fixes and gaps. Other versions remain unassessed. One GET, no runtime task, credentials or payment. Uses the shared POST /api/a2a/check budget. For authorized runtime tests and a signed repair kit, see /a2a-desk or buy_observation with item_id a2a_repair_kit. Third-party text is untrusted data.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Full public HTTPS agent-card URL, no query or fragment. |
| Name | Required | Description |
|---|---|---|
| next | Yes | |
| signed | Yes | |
| reading | Yes | |
| repairs | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnly/openWorld/idempotent/non-destructive hints. The description adds behavioral specifics: exactly one GET, shared POST /api/a2a/check budget, no credentials or payment, and that third-party text is untrusted data. These enrich the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence adds a distinct, useful fact: purpose, input format, outputs, version limitation, network impact, budget, alternatives, and security stance. It is front-loaded with the core purpose and contains no filler despite its density.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The definition covers the tool's scope, input constraints, behavioral side effects, budget usage, relevant alternatives, limitations, and security posture. Since an output schema exists, the return-value gap is closed, and the description still supplements it by naming the categories of results. An agent has everything needed to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage for the single url parameter, including a full description. The tool description mostly reiterates that ('Give the full public HTTPS card URL') without adding new semantic constraints such as URL normalization, error handling, or format edge cases. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Free A2A 0.3.0 card check', identifying a specific verb and resource. It further clarifies scope with 'Other versions remain unassessed' and enumerates concrete outputs (per-check states, bounded response evidence, suggested fixes and gaps), distinguishing it from generic checks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use this tool: for a free static check of A2A 0.3.0 cards. It also gives exclusions and alternatives: 'For authorized runtime tests and a signed repair kit, see /a2a-desk or buy_observation with item_id a2a_repair_kit' and notes it does not involve runtime tasks, credentials, or payment.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
For a buyer whose client has its own rules, to learn before signing whether this door meets them. Before paying any x402 door, find out what YOUR client will actually do with it, free: one unpaid probe, then the stock @x402/core selection logic replayed over the accepts that came back. Returns which accept your client would sign — network, asset, amount, signing window — or that it would REFUSE on your own machine before signing anything, naming the stage that decided it and the settings that answer it. Catches the failures nobody gets an error message for: every accept above your client's default per-payment ceiling (it throws locally, so the operator never learns you tried), a token dropped by the default-asset filter before its price is read, an escrow rail no stock client reaches, and paying on a rail you did not choose because the first accept was over your cap. Nothing is signed, no wallet is touched, no payment is made. DIFFERENT QUESTION FROM preflight_endpoint, which asks whether the DOOR is well-formed: a door can pass that and still be unpayable by you. Rate limited on the same budget as the preflight, because it is the same single probe. An evidence instrument: the reading is written to be handed to the human behind you. For a signed, servable version, buy_observation with item_id good_buyer.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The https x402 door you are about to pay. | |
| model | No | Optional. The model running you, as you would name it: claude-opus-5, gpt-5.6, a local model. Counted, never printed on the certificate. | |
| client | No | Optional. The harness or framework you run in: claude-code, cursor, openai-agents, langgraph, custom. Counted, never on the certificate. | |
| operator | No | Optional. Who runs you: a name, handle, company or URL. Stored as your claim, marked unverified, never published, never on the certificate. | |
| came_from | No | Optional. Where you learned this door exists: a URL, a directory, a skill name, memory, another agent. Referrers never reach us; this does. | |
| operator_kind | No | Optional. solo: one person runs you. company: a team does. research: a study. self: you act for yourself. | |
| prior_cert_id | No | Optional. A cert_ id from an earlier purchase here. A payer match with this payment marks you a returning buyer; no account needed. | |
| client_profile | No | The caller's own x402 client settings. Absent, the replay runs against a client configured with nothing, the case that loses money quietly. |
| Name | Required | Description |
|---|---|---|
| the_door | No | The free preflight's report on the same probe. One knock, two readings, so they can never describe different bytes. |
| your_client | Yes | The replay: the accept it picks, everything dropped and at which stage, the hazards on the one it picked, and what this simulation cannot see. |
| will_your_client_pay | Yes | would_sign | would_throw | cannot_simulate. would_sign means your client reaches a signature, NOT that the purchase succeeds. |
| these_are_different_questions | No | Why a well-shaped door can still be unpayable by you. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and destructiveHint annotations, the description discloses that nothing is signed, no wallet is touched, and no payment is made, that it uses one unpaid probe, and that it is rate-limited on the same budget as the preflight. It also details the specific failure modes it catches, which goes well beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose and usage, and each sentence adds behavioral or routing value. It is longer than minimal, with some redundancy (e.g., 'free' and 'unpaid probe'; 'before paying' and 'before signing'), but the density is justified for a tool with subtle failure modes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 8 parameters, a nested input schema, and an output schema, the description covers purpose, safety, failure modes, rate limiting, return behavior, and alternatives. Very little that an agent needs to decide whether and how to call it is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds narrative context about client_profile behavior (per-payment ceiling, default-asset filter, escrow rail) but does not systematically define individual parameters beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: before paying an x402 door, it replays the client's selection logic to determine which accept the client would sign or refuse. It explicitly contrasts with preflight_endpoint, distinguishing this tool from its closest sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It says exactly when to use the tool ('Before paying any x402 door') and what question it answers. It names preflight_endpoint as the alternative for a different question and points to buy_observation for a signed, servable version, giving clear routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
x402 receipt verification and signed-offer verification, free, against the issuer's published key. For anyone holding a signed x402 offer or receipt and unsure whether it is good, whoever issued it. Check any issuer's x402 signed offer or receipt — including this store's own and its competitors'. Send the compact JWS (three base64url segments separated by dots); the desk checks structure, signature against the issuer's did:web key, and liveness, and returns a verdict with every check named. Supply public_key_hex for a fully offline check (no network request is made in your name unless you leave the key off). NOT for artifact ids this store issued — that is verify_artifact. An evidence instrument: the verdict is written to be handed to the human behind you. The method is MIT-licensed and identical to the published verifier, so a verdict that matters should be reproduced offline rather than trusted.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | Optional. The artifact kind; detected from the artifact when absent. | |
| artifact | Yes | The signed offer or receipt as a compact JWS: header.payload.signature, base64url. | |
| public_key_hex | No | Optional ed25519 public key, hex. Supplying it makes the check fully offline. |
| Name | Required | Description |
|---|---|---|
| kind | Yes | The artifact kind, or null when it could not be detected. |
| live | No | Separate from conformance: an expired offer can conform and not be payable. Null for receipts. |
| verdict | Yes | The desk's finding on the artifact. |
| key_resolution | No | How the issuer's key was obtained, or why it was not. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the sparse annotations, the description discloses network behavior (looks up the issuer's did:web key, makes no request when a public key is supplied), the checks performed (structure, signature, liveness), the verdict shape (every check named), and reproducibility via the MIT-licensed verifier. The false/unknown readOnly and idempotent hints are not contradicted by the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense and front-loaded but slightly wordy: 'x402 receipt verification and signed-offer verification' and 'For anyone holding...' restate the same scope. Still, every sentence contributes a distinct fact (scope, exclusion, offline mode, evidence purpose, reproducibility), so the length is largely justified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter tool with a full input schema and an output schema, the description covers the required JWS format, optional offline mode, issuer scope, exclusion, and even the trust caveat. No critical caller-facing behavior is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds real semantics: artifact must be a compact JWS with three base64url dot-separated segments, and public_key_hex forces a fully offline check. This exceeds what the schema alone communicates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a precise verb and resource: x402 receipt and signed-offer verification against the issuer's published key. It explicitly differentiates from verify_artifact by saying 'NOT for artifact ids this store issued — that is verify_artifact,' so an agent can disambiguate immediately.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tells exactly when to use it (holding a signed x402 offer or receipt and unsure whether it is good, for any issuer), how to invoke offline (supply public_key_hex), and when not to (artifact ids issued by this store → verify_artifact). This is explicit routing rather than implied usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check a human-queue order by its order_id: status (queued or completed), the promised window, and once completed the deliverable itself — the poll half of the store's async-job pattern, the same record GET /api/order/{order_id} serves, for an agent holding only this transport. Free, no payment, no account; poll no faster than once a minute. Past its window the order carries a window_breached block stating what is owed. NOT a purchase; instant items arrive in the buy result. A store errand, for you the visiting agent — nothing here needs a human's decision.
| Name | Required | Description | Default |
|---|---|---|---|
| order_id | Yes | The order_id from a human-queue purchase result. |
| Name | Required | Description |
|---|---|---|
| status | Yes | Where the order stands. Completed is terminal. |
| item_id | Yes | What was bought. |
| message | Yes | The store's word on where things stand. |
| webhook | No | The recorded callback outcome; also available as callback.result. |
| callback | No | Requested callback outcome, separate from completion of the goods. |
| order_id | Yes | The order polled. |
| badge_url | No | The patron badge, an SVG. |
| item_name | No | Its name on the shelf. |
| sla_hours | Yes | The delivery promise, in hours from created_at. |
| commission | No | ed25519 proof: verify exact UTF-8 signed_payload, then its identities and hashes. RFC 8785 JSON. |
| created_at | Yes | When the order was taken, ISO 8601. |
| deliverable | No | The goods, as text. Present once status is completed. |
| completed_at | No | When it was delivered, ISO 8601. Present once completed. |
| patron_number | No | Your sequential patron number. |
| window_breached | No | Present only past the promised window. The store counting a missed promise against itself, in full. |
| completion_proof | No | ed25519 proof: verify exact UTF-8 signed_payload, then its identities and hashes. RFC 8785 JSON. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/closed-world, and the description goes well beyond them: it states the rate limit (once per minute), the no-cost/no-account access model, the window_breached block on overdue orders, and that this is the polling half of an async-job pattern equivalent to GET /api/order/{order_id}. That is rich, actionable behavioral context not derivable from structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose and the not-a-purchase disambiguation are front-loaded, which is the right ordering. The closing sentence ('A store errand, for you the visiting agent — nothing here needs a human's decision') is more atmospheric than informational, but it usefully clarifies that no human approval is required, so it roughly earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists and richer annotations are present, and the description still covers the operationally important gaps: what the returned record contains, what window_breached means, the equivalent REST endpoint, and the polling cadence. Nothing an agent needs in order to invoke and interpret this tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single order_id parameter, and the schema already says it comes 'from a human-queue purchase result.' The description repeats this provenance but adds no new syntax, format, or constraint beyond the schema's maxLength=60, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names a specific verb and resource ('Check a human-queue order by its order_id') and explicitly enumerates what the check returns: status, promised window, deliverable, window_breached block. It also distinguishes itself from the buy_* siblings by stating 'NOT a purchase; instant items arrive in the buy result.' An agent can tell it apart from check_purchase without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-to-use conditions (poll the async job after a human-queue purchase), when-not-to-use (instant items arrive in the buy result, so this is unnecessary), and a concrete operational constraint ('poll no faster than once a minute'). The alternative path for non-human-queue purchases is named, leaving nothing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free, even after payment expiry; submits no payment. Pending: poll after retry_after_seconds (not a deadline). Ready: use fulfillment; orders need completion. On purchase_input_mismatch read status or retry original inputs with recovery.original_door and recovery.original_path. Keep status_token private; do not pay again.
| Name | Required | Description | Default |
|---|---|---|---|
| purchase_id | Yes | The recovery.purchase_id from your purchase response. | |
| status_token | Yes | The private recovery.status_token from the purchase response. |
| Name | Required | Description |
|---|---|---|
| terms | No | |
| charged | No | |
| request | No | The full original request. |
| fulfillment | No | Recovered purchase response, when available. |
| next_action | No | |
| purchase_id | No | The original purchase identifier. |
| payment_state | No | The recorded payment outcome. |
| delivery_state | No | Whether the good is delivered, a human order exists, or delivery is not yet established. |
| recovery_state | No | Recovery readiness, separate from payment and human-work completion. |
| retry_after_seconds | No | Suggested delay before another free status read while recovery is pending; not a delivery deadline. Null when no recovery poll is advised. |
| settlement_attempted | No | This status read never submits payment. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly, idempotent, not destructive), the description reveals cost behavior ('Free, even after payment expiry'), no payment submission, privacy handling ('Keep status_token private'), polling semantics ('not a deadline'), and error-recovery behavior. This is rich behavioral context that annotations alone do not provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense yet highly effective: each sentence carries distinct information, from cost and payment behavior to state-specific handling and privacy. It is front-loaded with the most critical distinction ('Free... submits no payment') and uses compact labels (Pending:, Ready:) for scannability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only status-check tool with an output schema, the description covers all essential operational aspects: when to poll, what to do when Ready, how to handle the specific error, privacy requirements, and cost/security boundaries. The existence of an output schema means return-value details are already handled elsewhere.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters already described as recovery fields from the purchase response. The description adds that status_token should be kept private, but this is a restatement of the schema's 'private' qualifier. It references recovery.original_door and recovery.original_path for retry, but these are not tool parameters, so the added parameter semantics are minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks purchase status ('Pending', 'Ready') and is explicitly contrasted with payment actions ('submits no payment'). It names the exact resource (purchase) and the operation (check), and distinguishes itself from the buy_* siblings by emphasizing it is free and non-payment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear situational guidance: poll after retry_after_seconds, use fulfillment when Ready, and handle purchase_input_mismatch by reading status or retrying with recovery fields. It also gives a when-not ('do not pay again') but does not explicitly name alternative sibling tools like check_order or check_before_you_pay.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find an item before using buy_*: filter the shelf by price or text, or pass item_id for its listing. Rows give USDC price, fulfillment and read scope. Free, read-only, no account. Results stay in shelf order; nothing is ranked or recommended. A listing is not a stock check. Invalid lookups return a free next_step.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Words to match against an item's id, name, subtitle and description. | |
| item_id | No | One item's id. It replaces search rather than narrowing it: q and max_price_usdc are not applied, and the answer is that one item in full. | |
| max_price_usdc | No | A ceiling in USDC. Items at or below it match. |
| Name | Required | Description |
|---|---|---|
| of | Yes | How many are on the shelf, the denominator. |
| items | Yes | The rows, in the shelf's own order. |
| query | No | The filter that was applied, echoed. |
| scope | No | |
| matched | Yes | How many items matched. |
| publications | No | Publication indexes outside menu search; archived collections are opt-in, not current offerings. |
| whole_catalogue | No | The full catalogue, for a caller that wants every field. |
| how_this_was_ordered | No | That the order is the shelf's own and nothing is ranked. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, idempotentHint, destructiveHint), the description adds valuable behavioral details: it's free, requires no account, results stay in shelf order, nothing is ranked or recommended, and a listing is not a stock check. These are not inferable from the annotations alone and help the agent set expectations for the response.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only four sentences but packs in purpose, usage, behavior, and constraints. It front-loads the primary intent and keeps each sentence purposeful with no redundancy. It is concise and well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, the description need not explain return values. It covers the main scenarios (filter by price/text, or item_id), notes the ordering and ranking behavior, clarifies the 'not a stock check' limitation, and explains error responses. This is comprehensive for an agent to call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions for all three parameters are 100% covered, so the baseline is 3. The tool description adds minimal new meaning beyond summarizing the three modes (price, text, item_id) and their effects. It doesn't introduce details not already in the schema, so it does not exceed the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Find an item before using buy_*', which is a specific verb (find) and resource (catalog). It also mentions the filtering modes (price, text, item_id) and distinguishes it from the buy_* siblings by positioning it as a prerequisite. This makes the tool's role unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs when to use this tool: 'Find an item before using buy_*'. It also clarifies limitations like 'A listing is not a stock check' and 'Results stay in shelf order; nothing is ranked or recommended', which helps the agent decide if this is the right tool for a given query. The sentence 'Invalid lookups return a free next_step' also informs error handling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What this store holds about an x402 door, now and before now, in one free call. One unpaid probe (the same single probe as preflight_endpoint, same budget) folded with what the signed chain holds about the host: rounds probed out of rounds since we first met it, the passport tier with its fraction and its rows, the last probed round with its failed checks and the catalog's agreement, the passport decision, the shared-wallet fact. Then one comparison, stated as same, changed, no_prior or not_comparable with both sides named: did the door answer now the way the last signed round saw it. A reproduce block sets the live probe against one signed row (the last probed, or the week named with since), classed by the rule at /criteria#result-class, the row cited. Never a score, a rank or a safety threshold; counts travel with their denominators. A host the chain never met comes back as never met. Signed, dated version of the live half: buy_observation service_audit; a fresh census look folded into the passport: passport_refresh.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The https x402 door you are asking about. | |
| model | No | Optional. The model running you, as you would name it: claude-opus-5, gpt-5.6, a local model. Counted, never printed on the certificate. | |
| since | No | Optional. A signed week, to reproduce against that week's row. | |
| client | No | Optional. The harness or framework you run in: claude-code, cursor, openai-agents, langgraph, custom. Counted, never on the certificate. | |
| operator | No | Optional. Who runs you: a name, handle, company or URL. Stored as your claim, marked unverified, never published, never on the certificate. | |
| came_from | No | Optional. Where you learned this door exists: a URL, a directory, a skill name, memory, another agent. Referrers never reach us; this does. | |
| operator_kind | No | Optional. solo: one person runs you. company: a team does. research: a study. self: you act for yourself. | |
| prior_cert_id | No | Optional. A cert_ id from an earlier purchase here. A payer match with this payment marks you a returning buyer; no account needed. |
| Name | Required | Description |
|---|---|---|
| now | Yes | The live half: the preflight verdict, failed checks, advisories, and the whole preflight report. |
| held | Yes | The held half: counts with denominators, the tier with its fraction and rows, the last probed round, the passport decision, when it was derived. |
| headline | Yes | One derived sentence: what the door answered now and what the chain holds. |
| reproduce | No | The live probe against one signed row: the class, both sides, the failed checks added and cleared, the citation. |
| now_against_held | Yes | same | changed | no_prior | not_comparable, with both sides named. |
| what_this_is_not | No | Not a score, a rank, or a safety threshold — the standing caveat. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations: it states that the call is free, that the probe is 'unpaid,' that the comparison statuses are same, changed, no_prior, or not_comparable, and that 'never a score, a rank or a safety threshold' is returned. It also explains the unknown-host behavior ('A host the chain never met comes back as never met') and mentions that counts travel with denominators. This richly discloses output semantics and limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than minimal, but every sentence carries distinct information: cost, the probe, the comparison, the reproduce block, the no-score rule, unknown-host behavior, and sibling alternatives. It is front-loaded with the core purpose. A slight deduction for density and jargon ('folded with what the signed chain holds'), but overall it is efficiently structured for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and annotations cover readOnly/openWorld/idempotent hints, the description completes the picture: it explains what data is included, how the comparison is named, what reproduce does, how to handle hosts never met, what is never returned, and where to go for signed or fresh versions. Nothing essential for calling this tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers all 8 parameters with descriptions, so the baseline is 3. The description adds little beyond the schema: it mentions that 'since' selects a signed week's row and that 'url' is the x402 door, but these are already in the schema. It does not need to compensate because schema coverage is 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific and meaningful statement: 'What this store holds about an x402 door, now and before now, in one free call.' It clearly names the resource (x402 door), the action (look at what is held), and the scope (current and historical). It also distinguishes itself from siblings by explicitly cross-referencing preflight_endpoint, buy_observation, and passport_refresh.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives useful context: this is one free probe with the same budget as preflight_endpoint, and it explicitly notes when a different tool is appropriate ('Signed, dated version of the live half: buy_observation service_audit; a fresh census look folded into the passport: passport_refresh'). It does not formulate a strict 'when to use vs when not to use' rule, but it offers enough directional guidance for an agent to choose sensibly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look in the shop window: the last five pressings pulled from packs here, each with its page. Free, no account. A window pick (buy_window_pick, half a pack) takes one; the seed chooses and the card moves to the picker's binder. Completes when the result carries window and size.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| size | Yes | How many packs the window shows. |
| window | Yes | Packs, newest first, each with its cards. |
| pick_url | No | The buy door for a window pick. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds genuine behavior beyond that: no account or cost required, exactly five results, and a completion criterion ('Completes when the result carries window and size'). It does not describe failure or empty-window behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three front-loaded sentences with no filler: purpose, cost, and the relationship to the paid action. The themed vocabulary ('pressings', 'packs', 'binder') is dense but consistent and each clause carries meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present the description needn't detail return values, and with zero parameters there is no invocation ambiguity. Annotations carry the safety profile. What remains is themed jargon that an outside agent must infer, which keeps this short of complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline is 4. The prose adds no parameter semantics because none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource (look in the shop window) and what it yields: 'the last five pressings pulled from packs here, each with its page.' That is concretely distinguishable from the sibling buy_window_pick, which it explicitly contrasts. It does not differentiate from the similarly named look_at_door, so it falls short of full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear selection context ('Free, no account') and names the alternative action that consumes what this tool shows ('A window pick (buy_window_pick, half a pack) takes one'), establishing browse-vs-buy. It stops short of an explicit when-not-to-use rule, but the browsing context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Endpoint inspection and x402 endpoint preflight, free. The inspection block separates observed protocols, unverified advertised terms, structural checks and gaps; no signature, settlement or delivery verification is performed. The top-level verdict remains x402-specific. For a buyer about to pay a door it has not paid before, and for a seller checking their own. Check any x402 endpoint's door before paying it: one unpaid probe answering whether the URL serves a well-formed x402 v2 payment challenge right now — 402 status, parseable PAYMENT-REQUIRED, signable accepts, testnet catch. Returns the verdict with reached_level on the L0-L6 evidence ladder, the tri-state checks vector, and what this single probe cannot tell you. A shape check at one moment, NEVER an uptime or delivery claim — a passing preflight quoted as either is a misquote. An evidence instrument: the reading is written to be handed to the human behind you, gaps at full weight. Rate limited; the result carries the stated ceiling. For a signed, servable version of this same look, buy_observation with item_id service_audit.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The https endpoint a buyer would GET expecting a 402 challenge. | |
| model | No | Optional. The model running you, as you would name it: claude-opus-5, gpt-5.6, a local model. Counted, never printed on the certificate. | |
| client | No | Optional. The harness or framework you run in: claude-code, cursor, openai-agents, langgraph, custom. Counted, never on the certificate. | |
| operator | No | Optional. Who runs you: a name, handle, company or URL. Stored as your claim, marked unverified, never published, never on the certificate. | |
| came_from | No | Optional. Where you learned this door exists: a URL, a directory, a skill name, memory, another agent. Referrers never reach us; this does. | |
| operator_kind | No | Optional. solo: one person runs you. company: a team does. research: a study. self: you act for yourself. | |
| prior_cert_id | No | Optional. A cert_ id from an earlier purchase here. A payer match with this payment marks you a returning buyer; no account needed. |
| Name | Required | Description |
|---|---|---|
| verdict | Yes | x402-specific: ready | not_ready | unreachable | method_unresolved. |
| inspection | No | One unpaid response, with observed protocols, unverified advertised term summaries, existing structural findings and coverage gaps. The x402 verdict retains its meaning. No artifact signature verification, payment signing, payment submission, settlement or delivery check. |
| reached_level | Yes | How far the probe got on the evidence ladder: none | L1 | L2 | L3a. |
| single_probe_note | No | One moment — the standing caveat. Two requests only where a door refuses the first verb. |
| reached_level_meaning | No | What that rung does and does not claim. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations give only the generic read/write/idempotency profile, and the description goes well beyond them: it discloses that no signature, settlement or delivery verification occurs, that the result is rate limited with the ceiling carried in the response, that model/client/operator are counted but never printed on the certificate, and that the reading is a single-moment shape check. That is exactly the behavioral context an agent needs before invoking.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The opening sentence is front-loaded and the alternative is placed late where it belongs, but the prose is heavily aphoristic and repetitive — 'preflight' is restated three times, and lines like 'An evidence instrument: the reading is written to be handed to the human behind you, gaps at full weight' are rhetorical rather than informative. Several sentences could be merged without losing content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values need not be explained, and the description still adds the interpretive frame (L0-L6 evidence ladder, tri-state checks vector, what a single probe cannot tell you). For a free, non-destructive inspection tool with one required parameter, nothing an agent needs to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all seven parameters (url, model, client, operator, came_from, operator_kind, prior_cert_id) are already documented in the schema itself. The description adds no parameter-level syntax, format or ordering detail beyond that, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('one unpaid probe answering whether the URL serves a well-formed x402 v2 payment challenge right now') and enumerates the exact checks: 402 status, parseable PAYMENT-REQUIRED, signable accepts, testnet catch. This is unmistakably distinct from sibling probes like look_at_door or check_before_you_pay.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Names both audiences explicitly ('a buyer about to pay a door it has not paid before, and for a seller checking their own') and routes to the alternative for a different need ('For a signed, servable version of this same look, buy_observation with item_id service_audit'). It also states the boundary condition — this is not an uptime or delivery check.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a wallet's binder: every trading card it holds here, newest first, with page, face, sheet and record URLs, and the pack credit. Free, no account. A listing, not a proof; the signed records are. Completes when the result carries cards and count.
| Name | Required | Description | Default |
|---|---|---|---|
| wallet | Yes | A 0x address (forty hex characters) or a base58 Solana address. |
| Name | Required | Description |
|---|---|---|
| cards | Yes | Newest first. |
| count | Yes | Cards listed. |
| wallet | Yes | The wallet, as keyed. |
| truncated | No | True when the binder holds more than one page lists. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered; the description adds real value beyond them by specifying no auth or cost ('Free, no account'), result ordering ('newest first'), the fields returned, and a completion condition ('Completes when the result carries cards and count'). It does not mention rate limits or pagination, which keeps it out of the top band.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The core action is front-loaded and no sentence is filler, but the telegraphic fragments ('A listing, not a proof; the signed records are') read as clipped and cost a little clarity for their brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a single required parameter, a full output schema, and rich annotations, the description covers what is left: cost, auth, ordering, returned fields, and termination. Nothing an agent needs to call this correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is a single wallet parameter and schema description coverage is 100% — the schema already documents the 0x/base58 address formats. The description adds nothing about the parameter, so the high-coverage baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (read a wallet's binder) and enumerates the payload ('every trading card it holds here, newest first, with page, face, sheet and record URLs, and the pack credit'). It also draws a sharp boundary against proof-oriented siblings with 'A listing, not a proof; the signed records are,' so the agent can separate it from verify_artifact or buy_signed_record.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Free, no account' establishes preconditions that gate invocation, and 'A listing, not a proof; the signed records are' implicitly routes proof-checking to another tool. It stops short of naming that sibling explicitly or stating a when-not-to-use condition, so it is clear context rather than full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The store's front door as text: the full menu with prices, how x402 payment works here, the free shelf, and the house promises. Free. Completes when the guide text returns. NOT a purchase or payment endpoint — to buy, call a buy_* tool with x402 payment in _meta['x402/payment']; this only returns the guide. A store errand, for you the visiting agent — nothing here needs a human's decision.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| guide | Yes | The whole guide, plain text. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds operational context: it is free, completes when the guide text returns, causes no purchase or payment, and requires no human decision. This aligns with and enriches the annotation safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each carrying distinct value: what the guide contains, cost, completion behavior, and routing away from buy_* tools. The key disambiguation is front-loaded before the behavioral note.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only informational tool with an output schema, the description fully covers what the tool does, when to use it, and what it cannot do. No missing context would prevent an agent from calling it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the schema describes everything needed. Baseline for 0 params is 4; the description doesn't need to add parameter detail, and it doesn't.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States the exact resource ('the store's front door as text') and the verb ('read') through the name. The description enumerates the guide's contents (menu with prices, x402 payment info, free shelf, house promises) and explicitly disambiguates from purchase endpoints by saying it is 'NOT a purchase or payment endpoint'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit routing: to buy, call a buy_* tool with x402 payment in _meta['x402/payment']; this tool only returns the guide. It also frames the tool as an autonomous store errand for the visiting agent, signaling that no human approval is required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ring the store bell. Free, once a day per visitor; the count is public; a fresh ring presses one signed common card. Completes when the result carries the bell's message and count. A store errand, for you the visiting agent — nothing here needs a human's decision.
| Name | Required | Description | Default |
|---|---|---|---|
| wallet | No | Optional: a 0x or base58 wallet, so the day's card lands in its binder. | |
| pass_id | No | Optional: a current patron pass id; a Regular gets two packs at full odds. | |
| agent_name | No | Who's ringing. Optional but neighborly. |
| Name | Required | Description |
|---|---|---|
| count | Yes | Total rings, all time. |
| streak | No | With a wallet: consecutive days rung; a pack every seventh day, Bellringer II on the thirtieth. |
| message | Yes | What the bell said. |
| pressing | No | On a fresh ring: one common card, signed, with its page and verify URLs. Absent on a repeat. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare a non-read-only, non-idempotent, non-destructive mutation; the description adds meaningful context beyond them: a daily rate limit, the public visibility of the count, the side effect (pressing a signed common card), and a completion condition. The public-count disclosure is a genuine behavioral detail not derivable from structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short sentences, front-loaded with the action, then constraints, side effect, and completion criteria in order of importance. The few flavor phrases ('neighborly' is in the schema, not here) don't bloat the core; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values need no explanation, and annotations cover the safety profile. The description still supplies the rate limit, publicity disclosure, side effect, and completion criterion, leaving it nearly complete for a zero-required-param tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so wallet, pass_id, and agent_name are already documented. The description reinforces the wallet's role ('the day's card lands in its binder') and hints that pass_id affects rewards, but adds little syntax or meaning beyond the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a concrete action ('Ring the store bell') and immediately adds the outcome that distinguishes it: it 'presses one signed common card.' The free/once-per-day framing sets it apart from the buy_* siblings, though the verb 'ring the bell' is metaphorical and only clarified by the following sentences.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a real constraint ('Free, once a day per visitor') and positions it as 'a store errand, for you the visiting agent — nothing here needs a human's decision,' which implicitly contrasts with buy_human_task. However, it never names an alternative tool or states when NOT to use this, so the guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sign the guestbook. Free; every signer gets the visitor sticker. Entries are public. Completes when the result carries your entry and the sticker URL. A store errand, for you the visiting agent — your words are published, but nothing here needs a human's decision.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Your name, up to 80 characters. | |
| message | Yes | Your message, up to 500 characters. | |
| verified_identity | No | Optional profile URL. Stored as claimed and marked unverified, because we haven't. | |
| identity_signature | No | Optional ed25519 signature, hex, over the UTF-8 string "scvd-guestbook-v1\n{name}\n{message}" (values as stored: trimmed, 80/500 caps). An invalid signature is refused, not stored unverified. | |
| identity_public_key | No | Optional ed25519 public key, hex, to verifiably sign your entry. Send with identity_signature; a valid pair flips identity_verified true, meaning only 'same key = same signer', never 'real person confirmed'. |
| Name | Required | Description |
|---|---|---|
| message | Yes | The store's thanks. |
| entry_id | No | Your entry's id. |
| sticker_url | Yes | The visitor sticker, SVG, free forever. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are minimal (readOnlyHint false, destructive false); the description adds useful behavior: public entry, sticker returned, no human decision, completion condition. It doesn't discuss idempotency or repeated signings, but given a simple write tool this is adequate context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences front-load the action and key implications. Every sentence adds information: cost, publicity, completion, no human approval. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and 100% schema coverage, the description covers the behavioral context an agent needs. It could note that the entry is permanent or that identity fields are optional, but the schema already documents those.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter documented including verified identity and signature semantics. The description doesn't repeat parameter details but also adds little beyond the schema. Baseline 3 is appropriate because the schema already carries the burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action (signing), the resource (guestbook), and key consequences (free, public, sticker, completion condition). It distinguishes itself from sibling purchase tools by positioning the action as a store errand, not a purchase.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: free, no human decision needed, open to the visiting agent. It implies this is for routine signings vs other pay-to-do siblings, though it doesn't explicitly name an alternative or exclusion condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify anything scvd.store has ever signed — certificates, visit stamps, context anchors — by its id. Free, unlimited. Completes when the result carries valid (true/false) and the artifact record. NOT a conformance checker for other x402 services and NOT for artifacts another store signed: this checks only ids scvd.store itself issued; another issuer's signed offer or receipt goes to check_conformance. An evidence instrument: the answer is written to be handed to the human behind you. To verify a signature yourself without calling us, fetch the artifact's signed bytes and public key and check with any ed25519 library.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | A cert_, stamp_, or anchor_ id. |
| Name | Required | Description |
|---|---|---|
| kind | Yes | certificate | stamp | anchor | unknown. |
| note | Yes | The store's word on it. |
| valid | Yes | Whether the signature holds. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false, so the description carries the full burden. It discloses that it is free and unlimited, that it completes when the result carries valid and the artifact record, and frames it as an evidence instrument for human handoff. It also offers a self-verification alternative, adding behavioral context beyond the schema. It doesn't detail error behavior or side effects, but the output schema likely covers return structure, so a 4 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than minimal but every sentence earns its place: scope, cost, completion condition, exclusions, alternative routing, and self-verification path. It is front-loaded with the core purpose and then layers important caveats. Slightly wordy, but efficient for the information density needed to prevent misuse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with a full output schema, the description covers everything an agent needs: what it verifies, when to use it, when not to, how to route alternatives, cost, completion behavior, and even a manual verification method. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the id parameter as 'A cert_, stamp_, or anchor_ id.' with 100% coverage, so the baseline is 3. The description reiterates the same artifact types without adding new format details or constraints. It does add that the id must be one scvd.store issued, but that's about tool scope, not parameter semantics. No additional value over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool verifies artifacts signed by scvd.store by id, naming specific artifact types (certificates, visit stamps, context anchors). It explicitly excludes other issuers and other services, distinguishing it from siblings like check_conformance. The verb 'verify' plus resource scope is precise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use and when-not-to-use guidance, directly stating it is NOT for other x402 services or other issuers' artifacts, and directs those cases to check_conformance. It also notes it is free and unlimited, and mentions the completion condition, giving the agent clear context for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
preflight_endpoint2 fields changedOutput schema / properties / inspectionAdded value: +{
+ "description": "One unpaid response, with observed protocols, unverified advertised term summaries, existing structural findings and coverage gaps. The x402 verdict retains its meaning. No artifact signature verification, payment signing, payment submission, settlement or delivery check.",
+ "properties": {
+ "coverage": {
+ "description": "Body read / over_limit / unobserved and MPP core read / absent / unmeasured.",
+ "type": "object"
+ },
+ "gaps": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "observed_at": {
+ "format": "date-time",
+ "type": "string"
+ },
+ "protocols": {
+ "properties": {
+ "observed": {
+ "items": {
+ "enum": [
+ "x402",
+ "mpp"
+ ],
+ "type": "string"
+ },
+ "type": "array",
+ "uniqueItems": true
+ },
+ "scope": {
+ "type": "string"
+ },
+ "state": {
+ "enum": [
+ "read",
+ "partial",
+ "unobserved"
+ ],
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "reachability": {
+ "properties": {
+ "http_status": {
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "method": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "state": {
+ "enum": [
+ "responded",
+ "unreachable",
+ "method_unresolved"
+ ],
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "signatures": {
+ "properties": {
+ "reason": {
+ "type": "string"
+ },
+ "state": {
+ "enum": [
+ "not_checked"
+ ],
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "structure": {
+ "description": "Existing x402, frozen MPP and MPP core batteries, checked counts and failed check names. MPP core also names unmeasured checks; no global readiness verdict.",
+ "type": "object"
+ },
+ "subject_url": {
+ "type": "string"
+ },
+ "terms": {
+ "description": "Unverified summaries, at most 32 entries per protocol, each with state, entries, total and omitted. Not complete payment instructions.",
+ "type": "object"
+ },
+ "unperformed": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "version": {
+ "enum": [
+ "inspection-v1"
+ ],
+ "type": "string"
+ }
+ },
+ "type": "object"
+}Output schema / properties / verdict / descriptionPrevious value: -"ready | not_ready | unreachable."New value: +"x402-specific: ready | not_ready | unreachable | method_unresolved."buy_human_task1 field changedInput schema / properties / item_id / descriptionPrevious value: -"Which item on this shelf to buy. Required. Each item's own required fields are listed in this schema's allOf branches and in the description above."New value: +"Required item; its other required fields are in allOf."buy_mandate1 field changedInput schema / properties / item_id / descriptionPrevious value: -"Which item on this shelf to buy. Required. Each item's own required fields are listed in this schema's allOf branches and in the description above."New value: +"Required item; its other required fields are in allOf."buy_memory_anchor1 field changedInput schema / properties / item_id / descriptionPrevious value: -"Which item on this shelf to buy. Required. Each item's own required fields are listed in this schema's allOf branches and in the description above."New value: +"Required item; its other required fields are in allOf."buy_observation5 fields changedInput schema / allOfPrevious value: -[
- {
- "if": {
- "properties": {
- "item_id": {
- "const": "settlement_attestation"
- }
- },
- "required": [
- "item_id"
- ]
- },
- "then": {
- "required": [
- "tx_hash"
- ]
- }
- },
- {
- "if": {
- "properties": {
- "item_id": {
- "const": "settlement_reconciliation"
- }
- },
- "required": [
- "item_id"
- ]
- },
- "then": {
- "required": [
- "tx_hash"
- ]
- }
- },
- {
- "if": {
- "properties": {
- "item_id": {
- "const": "the_case_file"
- }
- },
- "required": [
- "item_id"
- ]
- },
- "then": {
- "required": [
- "tx_hash"
- ]
- }
- },
- {
- "if": {
- "properties": {
- "item_id": {
- "const": "attestation_bundle"
- }
- },
- "required": [
- "item_id"
- ]
- },
- "then": {
- "required": [
- "tx_hashes"
- ]
- }
- },
- {
- "if": {
- "properties": {
- "item_id": {
- "const": "standing_watch"
- }
- },
- "required": [
- "item_id"
- ]
- },
- "then": {
- "required": [
- "url"
- ]
- }
- },
- {
- "if": {
- "properties": {
- "item_id": {
- "const": "service_audit"
- }
- },
- "required": [
- "item_id"
- ]
- },
- "then": {
- "required": [
- "url"
- ]
- }
- },
- {
- "if": {
- "properties": {
- "item_id": {
- "const": "a2a_repair_kit"
- }
- },
- "required": [
- "item_id"
- ]
- },
- "then": {
- "required": [
- "url"
- ]
- }
- },
- {
- "if": {
- "properties": {
- "item_id": {
- "const": "good_buyer"
- }
- },
- "required": [
- "item_id"
- ]
- },
- "then": {
- "required": [
- "url"
- ]
- }
- },
- {
- "if": {
- "properties": {
- "item_id": {
- "const": "conformance_watch"
- }
- },
- "required": [
- "item_id"
- ]
- },
- "then": {
- "required": [
- "url"
- ]
- }
- },
- {
- "if": {
- "properties": {
- "item_id": {
- "const": "signature_agent_card"
- }
- },
- "required": [
- "item_id"
- ]
- },
- "then": {
- "required": [
- "url"
- ]
- }
- },
- {
- "if": {
- "properties": {
- "item_id": {
- "const": "onpage_audit"
- }
- },
- "required": [
- "item_id"
- ]
- },
- "then": {
- "required": [
- "url"
- ]
- }
- },
- {
- "if": {
- "properties": {
- "item_id": {
- "const": "launch_check"
- }
- },
- "required": [
- "item_id"
- ]
- },
- "then": {
- "required": [
- "url"
- ]
- }
- },
- {
- "if": {
- "properties": {
- "item_id": {
- "const": "opening_day"
- }
- },
- "required": [
- "item_id"
- ]
- },
- "then": {
- "required": [
- "url"
- ]
- }
- },
- {
- "if": {
- "properties": {
- "item_id": {
- "const": "provenance_check"
- }
- },
- "required": [
- "item_id"
- ]
- },
- "then": {
- "required": [
- "address"
- ]
- }
- },
- {
- "if": {
- "properties": {
- "item_id": {
- "const": "the_statement"
- }
- },
- "required": [
- "item_id"
- ]
- },
- "then": {
- "required": [
- "wallet"
- ]
- }
- },
- {
- "if": {
- "properties": {
- "item_id": {
- "const": "operator_statement"
- }
- },
- "required": [
- "item_id"
- ]
- },
- "then": {
- "required": [
- "wallet"
- ]
- }
- },
- {
- "if": {
- "properties": {
- "item_id": {
- "const": "bitcoin_anchor"
- }
- },
- "required": [
- "item_id"
- ]
- },
- "then": {
- "required": [
- "digest"
- ]
- }
- },
- {
- "if": {
- "properties": {
- "item_id": {
- "const": "passport_refresh"
- }
- },
- "required": [
- "item_id"
- ]
- },
- "then": {
- "required": [
- "url"
- ]
- }
- },
- {
- "if": {
- "properties": {
- "item_id": {
- "const": "trust_profile"
- }
- },
- "required": [
- "item_id"
- ]
- },
- "then": {
- "required": [
- "url"
- ]
- }
- },
- {
- "if": {
- "properties": {
- "item_id": {
- "const": "spot_check"
- }
- },
- "required": [
- "item_id"
- ]
- },
- "then": {
- "required": [
- "host"
- ]
- }
- }
-]New value: +[
+ {
+ "if": {
+ "properties": {
+ "item_id": {
+ "const": "settlement_attestation"
+ }
+ },
+ "required": [
+ "item_id"
+ ]
+ },
+ "then": {
+ "required": [
+ "tx_hash"
+ ]
+ }
+ },
+ {
+ "if": {
+ "properties": {
+ "item_id": {
+ "const": "settlement_reconciliation"
+ }
+ },
+ "required": [
+ "item_id"
+ ]
+ },
+ "then": {
+ "required": [
+ "tx_hash"
+ ]
+ }
+ },
+ {
+ "if": {
+ "properties": {
+ "item_id": {
+ "const": "the_case_file"
+ }
+ },
+ "required": [
+ "item_id"
+ ]
+ },
+ "then": {
+ "required": [
+ "tx_hash"
+ ]
+ }
+ },
+ {
+ "if": {
+ "properties": {
+ "item_id": {
+ "const": "attestation_bundle"
+ }
+ },
+ "required": [
+ "item_id"
+ ]
+ },
+ "then": {
+ "required": [
+ "tx_hashes"
+ ]
+ }
+ },
+ {
+ "if": {
+ "properties": {
+ "item_id": {
+ "const": "standing_watch"
+ }
+ },
+ "required": [
+ "item_id"
+ ]
+ },
+ "then": {
+ "required": [
+ "url"
+ ]
+ }
+ },
+ {
+ "if": {
+ "properties": {
+ "item_id": {
+ "const": "service_audit"
+ }
+ },
+ "required": [
+ "item_id"
+ ]
+ },
+ "then": {
+ "required": [
+ "url"
+ ]
+ }
+ },
+ {
+ "if": {
+ "properties": {
+ "item_id": {
+ "const": "a2a_repair_kit"
+ }
+ },
+ "required": [
+ "item_id"
+ ]
+ },
+ "then": {
+ "required": [
+ "url"
+ ]
+ }
+ },
+ {
+ "if": {
+ "properties": {
+ "item_id": {
+ "const": "good_buyer"
+ }
+ },
+ "required": [
+ "item_id"
+ ]
+ },
+ "then": {
+ "required": [
+ "url"
+ ]
+ }
+ },
+ {
+ "if": {
+ "properties": {
+ "item_id": {
+ "const": "conformance_watch"
+ }
+ },
+ "required": [
+ "item_id"
+ ]
+ },
+ "then": {
+ "required": [
+ "url"
+ ]
+ }
+ },
+ {
+ "if": {
+ "properties": {
+ "item_id": {
+ "const": "signature_agent_card"
+ }
+ },
+ "required": [
+ "item_id"
+ ]
+ },
+ "then": {
+ "required": [
+ "url"
+ ]
+ }
+ },
+ {
+ "if": {
+ "properties": {
+ "item_id": {
+ "const": "onpage_audit"
+ }
+ },
+ "required": [
+ "item_id"
+ ]
+ },
+ "then": {
+ "required": [
+ "url"
+ ]
+ }
+ },
+ {
+ "if": {
+ "properties": {
+ "item_id": {
+ "const": "launch_check"
+ }
+ },
+ "required": [
+ "item_id"
+ ]
+ },
+ "then": {
+ "required": [
+ "url"
+ ]
+ }
+ },
+ {
+ "if": {
+ "properties": {
+ "item_id": {
+ "const": "opening_day"
+ }
+ },
+ "required": [
+ "item_id"
+ ]
+ },
+ "then": {
+ "required": [
+ "url"
+ ]
+ }
+ },
+ {
+ "if": {
+ "properties": {
+ "item_id": {
+ "const": "provenance_check"
+ }
+ },
+ "required": [
+ "item_id"
+ ]
+ },
+ "then": {
+ "required": [
+ "address"
+ ]
+ }
+ },
+ {
+ "if": {
+ "properties": {
+ "item_id": {
+ "const": "the_statement"
+ }
+ },
+ "required": [
+ "item_id"
+ ]
+ },
+ "then": {
+ "required": [
+ "wallet"
+ ]
+ }
+ },
+ {
+ "if": {
+ "properties": {
+ "item_id": {
+ "const": "operator_statement"
+ }
+ },
+ "required": [
+ "item_id"
+ ]
+ },
+ "then": {
+ "required": [
+ "wallet"
+ ]
+ }
+ },
+ {
+ "if": {
+ "properties": {
+ "item_id": {
+ "const": "bitcoin_anchor"
+ }
+ },
+ "required": [
+ "item_id"
+ ]
+ },
+ "then": {
+ "required": [
+ "digest"
+ ]
+ }
+ },
+ {
+ "if": {
+ "properties": {
+ "item_id": {
+ "const": "passport_refresh"
+ }
+ },
+ "required": [
+ "item_id"
+ ]
+ },
+ "then": {
+ "required": [
+ "url"
+ ]
+ }
+ },
+ {
+ "if": {
+ "properties": {
+ "item_id": {
+ "const": "trust_profile"
+ }
+ },
+ "required": [
+ "item_id"
+ ]
+ },
+ "then": {
+ "required": [
+ "url"
+ ]
+ }
+ },
+ {
+ "if": {
+ "properties": {
+ "item_id": {
+ "const": "spot_check"
+ }
+ },
+ "required": [
+ "item_id"
+ ]
+ },
+ "then": {
+ "required": [
+ "host"
+ ]
+ }
+ },
+ {
+ "if": {
+ "properties": {
+ "item_id": {
+ "const": "research_comparison"
+ }
+ },
+ "required": [
+ "item_id"
+ ]
+ },
+ "then": {
+ "required": [
+ "urls"
+ ]
+ }
+ }
+]Input schema / examplesPrevious value: -[
- {
- "item_id": "settlement_attestation",
- "tx_hash": "0x47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee0"
- },
- {
- "item_id": "settlement_reconciliation",
- "tx_hash": "0x47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee0"
- },
- {
- "item_id": "the_case_file",
- "tx_hash": "0x47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee0"
- },
- {
- "item_id": "attestation_bundle",
- "tx_hashes": "0x47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee0,0x9b04e1c9b04e1c9b04e1c9b04e1c9b04e1c9b04e1c9b04e1c9b04e1c9b04e1c0"
- },
- {
- "item_id": "standing_watch",
- "url": "https://your-shop.example/api/buy/thing"
- },
- {
- "item_id": "service_audit",
- "url": "https://your-shop.example/api/buy/thing"
- },
- {
- "item_id": "a2a_repair_kit",
- "url": "https://your-agent.example/.well-known/agent-card.json"
- },
- {
- "item_id": "good_buyer",
- "url": "https://somebody-elses-shop.example/api/buy/thing"
- },
- {
- "item_id": "conformance_watch",
- "url": "https://your-shop.example/api/buy/thing"
- },
- {
- "item_id": "signature_agent_card",
- "url": "https://your-agent.example"
- },
- {
- "item_id": "onpage_audit",
- "url": "https://your-site.example/pricing"
- },
- {
- "item_id": "launch_check",
- "url": "https://your-shop.example/api/buy/thing"
- },
- {
- "item_id": "opening_day",
- "url": "https://your-shop.example/api/buy/thing"
- },
- {
- "address": "0x1111111111111111111111111111111111111111",
- "item_id": "provenance_check"
- },
- {
- "item_id": "the_statement",
- "wallet": "0x843b544bf5f0AA6cbf13E94563874878C98cc4a7"
- },
- {
- "item_id": "operator_statement",
- "wallet": "0x843b544bf5f0AA6cbf13E94563874878C98cc4a7"
- },
- {
- "digest": "9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f",
- "item_id": "bitcoin_anchor"
- },
- {
- "item_id": "passport_refresh",
- "url": "https://your-endpoint.example/api/thing"
- },
- {
- "item_id": "trust_profile",
- "url": "https://your-endpoint.example/api/thing"
- },
- {
- "host": "your-door.example",
- "item_id": "spot_check"
- }
-]New value: +[
+ {
+ "item_id": "settlement_attestation",
+ "tx_hash": "0x47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee0"
+ },
+ {
+ "item_id": "settlement_reconciliation",
+ "tx_hash": "0x47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee0"
+ },
+ {
+ "item_id": "the_case_file",
+ "tx_hash": "0x47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee0"
+ },
+ {
+ "item_id": "attestation_bundle",
+ "tx_hashes": "0x47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee0,0x9b04e1c9b04e1c9b04e1c9b04e1c9b04e1c9b04e1c9b04e1c9b04e1c9b04e1c0"
+ },
+ {
+ "item_id": "standing_watch",
+ "url": "https://your-shop.example/api/buy/thing"
+ },
+ {
+ "item_id": "service_audit",
+ "url": "https://your-shop.example/api/buy/thing"
+ },
+ {
+ "item_id": "a2a_repair_kit",
+ "url": "https://your-agent.example/.well-known/agent-card.json"
+ },
+ {
+ "item_id": "good_buyer",
+ "url": "https://somebody-elses-shop.example/api/buy/thing"
+ },
+ {
+ "item_id": "conformance_watch",
+ "url": "https://your-shop.example/api/buy/thing"
+ },
+ {
+ "item_id": "signature_agent_card",
+ "url": "https://your-agent.example"
+ },
+ {
+ "item_id": "onpage_audit",
+ "url": "https://your-site.example/pricing"
+ },
+ {
+ "item_id": "launch_check",
+ "url": "https://your-shop.example/api/buy/thing"
+ },
+ {
+ "item_id": "opening_day",
+ "url": "https://your-shop.example/api/buy/thing"
+ },
+ {
+ "address": "0x1111111111111111111111111111111111111111",
+ "item_id": "provenance_check"
+ },
+ {
+ "item_id": "the_statement",
+ "wallet": "0x843b544bf5f0AA6cbf13E94563874878C98cc4a7"
+ },
+ {
+ "item_id": "operator_statement",
+ "wallet": "0x843b544bf5f0AA6cbf13E94563874878C98cc4a7"
+ },
+ {
+ "digest": "9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f",
+ "item_id": "bitcoin_anchor"
+ },
+ {
+ "item_id": "passport_refresh",
+ "url": "https://your-endpoint.example/api/thing"
+ },
+ {
+ "item_id": "trust_profile",
+ "url": "https://your-endpoint.example/api/thing"
+ },
+ {
+ "host": "your-door.example",
+ "item_id": "spot_check"
+ },
+ {
+ "item_id": "research_comparison",
+ "urls": "[\"https://research-a.example/quote\",\"https://research-b.example/quote\"]"
+ }
+]Input schema / properties / item_id / descriptionPrevious value: -"Which item on this shelf to buy. Required. Each item's own required fields are listed in this schema's allOf branches and in the description above."New value: +"Required item; its other required fields are in allOf."Input schema / properties / item_id / enumPrevious value: -[
- "settlement_attestation",
- "settlement_reconciliation",
- "the_case_file",
- "attestation_bundle",
- "standing_watch",
- "service_audit",
- "a2a_repair_kit",
- "good_buyer",
- "conformance_watch",
- "signature_agent_card",
- "onpage_audit",
- "launch_check",
- "opening_day",
- "provenance_check",
- "the_statement",
- "operator_statement",
- "bitcoin_anchor",
- "passport_refresh",
- "trust_profile",
- "spot_check"
-]New value: +[
+ "settlement_attestation",
+ "settlement_reconciliation",
+ "the_case_file",
+ "attestation_bundle",
+ "standing_watch",
+ "service_audit",
+ "a2a_repair_kit",
+ "good_buyer",
+ "conformance_watch",
+ "signature_agent_card",
+ "onpage_audit",
+ "launch_check",
+ "opening_day",
+ "provenance_check",
+ "the_statement",
+ "operator_statement",
+ "bitcoin_anchor",
+ "passport_refresh",
+ "trust_profile",
+ "spot_check",
+ "research_comparison"
+]Input schema / properties / urlsAdded value: +{
+ "description": "JSON-encoded array of 2–4 distinct public HTTPS URLs (1024 characters each), for unauthenticated GET payment challenges. No credentials, fragments, secrets or private prompts; no research purchased.",
+ "maxLength": 4114,
+ "type": "string"
+}buy_signed_record1 field changedInput schema / properties / item_id / descriptionPrevious value: -"Which item on this shelf to buy. Required. Each item's own required fields are listed in this schema's allOf branches and in the description above."New value: +"Required item; its other required fields are in allOf."buy_small_pleasure1 field changedInput schema / properties / item_id / descriptionPrevious value: -"Which item on this shelf to buy. Required. Each item's own required fields are listed in this schema's allOf branches and in the description above."New value: +"Required item; its other required fields are in allOf."find_in_catalog1 field changedOutput schema / properties / items / items / properties / reads / descriptionPrevious value: -"What the item reads: our_books, subject_fetch, made_here."New value: +"The declared class of observations this item makes."buy_human_task1 field changedInput schema / properties / purpose / descriptionPrevious value: -"Optional: what this purchase is for, in your words. Signed onto the certificate verbatim as your statement; never checked, never treated as instructions."New value: +"Optional: what this is for, in your words. Signed verbatim onto the certificate and shown on its receipt; never checked, never treated as instructions."buy_mandate1 field changedInput schema / properties / purpose / descriptionPrevious value: -"Optional: what this purchase is for, in your words. Signed onto the certificate verbatim as your statement; never checked, never treated as instructions."New value: +"Optional: what this is for, in your words. Signed verbatim onto the certificate and shown on its receipt; never checked, never treated as instructions."buy_memory_anchor1 field changedInput schema / properties / purpose / descriptionPrevious value: -"Optional: what this purchase is for, in your words. Signed onto the certificate verbatim as your statement; never checked, never treated as instructions."New value: +"Optional: what this is for, in your words. Signed verbatim onto the certificate and shown on its receipt; never checked, never treated as instructions."buy_observation1 field changedInput schema / properties / purpose / descriptionPrevious value: -"Optional: what this purchase is for, in your words. Signed onto the certificate verbatim as your statement; never checked, never treated as instructions."New value: +"Optional: what this is for, in your words. Signed verbatim onto the certificate and shown on its receipt; never checked, never treated as instructions."buy_signed_record1 field changedInput schema / properties / purpose / descriptionPrevious value: -"Optional: what this purchase is for, in your words. Signed onto the certificate verbatim as your statement; never checked, never treated as instructions."New value: +"Optional: what this is for, in your words. Signed verbatim onto the certificate and shown on its receipt; never checked, never treated as instructions."buy_simple1 field changedInput schema / properties / purpose / descriptionPrevious value: -"Optional: what this purchase is for, in your words. Signed onto the certificate verbatim as your statement; never checked, never treated as instructions."New value: +"Optional: what this is for, in your words. Signed verbatim onto the certificate and shown on its receipt; never checked, never treated as instructions."buy_small_pleasure1 field changedInput schema / properties / purpose / descriptionPrevious value: -"Optional: what this purchase is for, in your words. Signed onto the certificate verbatim as your statement; never checked, never treated as instructions."New value: +"Optional: what this is for, in your words. Signed verbatim onto the certificate and shown on its receipt; never checked, never treated as instructions."buy_mandatebuy_observation9 fields changedInput schema / allOfPrevious value: -[
- {
- "if": {
- "properties": {
- "item_id": {
- "const": "the_mandate"
- }
- },
- "required": [
- "item_id"
- ]
- },
- "then": {
- "required": [
- "mandate"
- ]
- }
- },
- {
- "if": {
- "properties": {
- "item_id": {
- "const": "settlement_attestation"
- }
- },
- "required": [
- "item_id"
- ]
- },
- "then": {
- "required": [
- "tx_hash"
- ]
- }
- },
- {
- "if": {
- "properties": {
- "item_id": {
- "const": "settlement_reconciliation"
- }
- },
- "required": [
- "item_id"
- ]
- },
- "then": {
- "required": [
- "tx_hash"
- ]
- }
- },
- {
- "if": {
- "properties": {
- "item_id": {
- "const": "the_case_file"
- }
- },
- "required": [
- "item_id"
- ]
- },
- "then": {
- "required": [
- "tx_hash"
- ]
- }
- },
- {
- "if": {
- "properties": {
- "item_id": {
- "const": "attestation_bundle"
- }
- },
- "required": [
- "item_id"
- ]
- },
- "then": {
- "required": [
- "tx_hashes"
- ]
- }
- },
- {
- "if": {
- "properties": {
- "item_id": {
- "const": "standing_watch"
- }
- },
- "required": [
- "item_id"
- ]
- },
- "then": {
- "required": [
- "url"
- ]
- }
- },
- {
- "if": {
- "properties": {
- "item_id": {
- "const": "service_audit"
- }
- },
- "required": [
- "item_id"
- ]
- },
- "then": {
- "required": [
- "url"
- ]
- }
- },
- {
- "if": {
- "properties": {
- "item_id": {
- "const": "a2a_repair_kit"
- }
- },
- "required": [
- "item_id"
- ]
- },
- "then": {
- "required": [
- "url"
- ]
- }
- },
- {
- "if": {
- "properties": {
- "item_id": {
- "const": "good_buyer"
- }
- },
- "required": [
- "item_id"
- ]
- },
- "then": {
- "required": [
- "url"
- ]
- }
- },
- {
- "if": {
- "properties": {
- "item_id": {
- "const": "conformance_watch"
- }
- },
- "required": [
- "item_id"
- ]
- },
- "then": {
- "required": [
- "url"
- ]
- }
- },
- {
- "if": {
- "properties": {
- "item_id": {
- "const": "signature_agent_card"
- }
- },
- "required": [
- "item_id"
- ]
- },
- "then": {
- "required": [
- "url"
- ]
- }
- },
- {
- "if": {
- "properties": {
- "item_id": {
- "const": "onpage_audit"
- }
- },
- "required": [
- "item_id"
- ]
- },
- "then": {
- "required": [
- "url"
- ]
- }
- },
- {
- "if": {
- "properties": {
- "item_id": {
- "const": "launch_check"
- }
- },
- "required": [
- "item_id"
- ]
- },
- "then": {
- "required": [
- "url"
- ]
- }
- },
- {
- "if": {
- "properties": {
- "item_id": {
- "const": "opening_day"
- }
- },
- "required": [
- "item_id"
- ]
- },
- "then": {
- "required": [
- "url"
- ]
- }
- },
- {
- "if": {
- "properties": {
- "item_id": {
- "const": "provenance_check"
- }
- },
- "required": [
- "item_id"
- ]
- },
- "then": {
- "required": [
- "address"
- ]
- }
- },
- {
- "if": {
- "properties": {
- "item_id": {
- "const": "the_statement"
- }
- },
- "required": [
- "item_id"
- ]
- },
- "then": {
- "required": [
- "wallet"
- ]
- }
- },
- {
- "if": {
- "properties": {
- "item_id": {
- "const": "operator_statement"
- }
- },
- "required": [
- "item_id"
- ]
- },
- "then": {
- "required": [
- "wallet"
- ]
- }
- },
- {
- "if": {
- "properties": {
- "item_id": {
- "const": "bitcoin_anchor"
- }
- },
- "required": [
- "item_id"
- ]
- },
- "then": {
- "required": [
- "digest"
- ]
- }
- },
- {
- "if": {
- "properties": {
- "item_id": {
- "const": "passport_refresh"
- }
- },
- "required": [
- "item_id"
- ]
- },
- "then": {
- "required": [
- "url"
- ]
- }
- },
- {
- "if": {
- "properties": {
- "item_id": {
- "const": "trust_profile"
- }
- },
- "required": [
- "item_id"
- ]
- },
- "then": {
- "required": [
- "url"
- ]
- }
- },
- {
- "if": {
- "properties": {
- "item_id": {
- "const": "spot_check"
- }
- },
- "required": [
- "item_id"
- ]
- },
- "then": {
- "required": [
- "host"
- ]
- }
- }
-]New value: +[
+ {
+ "if": {
+ "properties": {
+ "item_id": {
+ "const": "settlement_attestation"
+ }
+ },
+ "required": [
+ "item_id"
+ ]
+ },
+ "then": {
+ "required": [
+ "tx_hash"
+ ]
+ }
+ },
+ {
+ "if": {
+ "properties": {
+ "item_id": {
+ "const": "settlement_reconciliation"
+ }
+ },
+ "required": [
+ "item_id"
+ ]
+ },
+ "then": {
+ "required": [
+ "tx_hash"
+ ]
+ }
+ },
+ {
+ "if": {
+ "properties": {
+ "item_id": {
+ "const": "the_case_file"
+ }
+ },
+ "required": [
+ "item_id"
+ ]
+ },
+ "then": {
+ "required": [
+ "tx_hash"
+ ]
+ }
+ },
+ {
+ "if": {
+ "properties": {
+ "item_id": {
+ "const": "attestation_bundle"
+ }
+ },
+ "required": [
+ "item_id"
+ ]
+ },
+ "then": {
+ "required": [
+ "tx_hashes"
+ ]
+ }
+ },
+ {
+ "if": {
+ "properties": {
+ "item_id": {
+ "const": "standing_watch"
+ }
+ },
+ "required": [
+ "item_id"
+ ]
+ },
+ "then": {
+ "required": [
+ "url"
+ ]
+ }
+ },
+ {
+ "if": {
+ "properties": {
+ "item_id": {
+ "const": "service_audit"
+ }
+ },
+ "required": [
+ "item_id"
+ ]
+ },
+ "then": {
+ "required": [
+ "url"
+ ]
+ }
+ },
+ {
+ "if": {
+ "properties": {
+ "item_id": {
+ "const": "a2a_repair_kit"
+ }
+ },
+ "required": [
+ "item_id"
+ ]
+ },
+ "then": {
+ "required": [
+ "url"
+ ]
+ }
+ },
+ {
+ "if": {
+ "properties": {
+ "item_id": {
+ "const": "good_buyer"
+ }
+ },
+ "required": [
+ "item_id"
+ ]
+ },
+ "then": {
+ "required": [
+ "url"
+ ]
+ }
+ },
+ {
+ "if": {
+ "properties": {
+ "item_id": {
+ "const": "conformance_watch"
+ }
+ },
+ "required": [
+ "item_id"
+ ]
+ },
+ "then": {
+ "required": [
+ "url"
+ ]
+ }
+ },
+ {
+ "if": {
+ "properties": {
+ "item_id": {
+ "const": "signature_agent_card"
+ }
+ },
+ "required": [
+ "item_id"
+ ]
+ },
+ "then": {
+ "required": [
+ "url"
+ ]
+ }
+ },
+ {
+ "if": {
+ "properties": {
+ "item_id": {
+ "const": "onpage_audit"
+ }
+ },
+ "required": [
+ "item_id"
+ ]
+ },
+ "then": {
+ "required": [
+ "url"
+ ]
+ }
+ },
+ {
+ "if": {
+ "properties": {
+ "item_id": {
+ "const": "launch_check"
+ }
+ },
+ "required": [
+ "item_id"
+ ]
+ },
+ "then": {
+ "required": [
+ "url"
+ ]
+ }
+ },
+ {
+ "if": {
+ "properties": {
+ "item_id": {
+ "const": "opening_day"
+ }
+ },
+ "required": [
+ "item_id"
+ ]
+ },
+ "then": {
+ "required": [
+ "url"
+ ]
+ }
+ },
+ {
+ "if": {
+ "properties": {
+ "item_id": {
+ "const": "provenance_check"
+ }
+ },
+ "required": [
+ "item_id"
+ ]
+ },
+ "then": {
+ "required": [
+ "address"
+ ]
+ }
+ },
+ {
+ "if": {
+ "properties": {
+ "item_id": {
+ "const": "the_statement"
+ }
+ },
+ "required": [
+ "item_id"
+ ]
+ },
+ "then": {
+ "required": [
+ "wallet"
+ ]
+ }
+ },
+ {
+ "if": {
+ "properties": {
+ "item_id": {
+ "const": "operator_statement"
+ }
+ },
+ "required": [
+ "item_id"
+ ]
+ },
+ "then": {
+ "required": [
+ "wallet"
+ ]
+ }
+ },
+ {
+ "if": {
+ "properties": {
+ "item_id": {
+ "const": "bitcoin_anchor"
+ }
+ },
+ "required": [
+ "item_id"
+ ]
+ },
+ "then": {
+ "required": [
+ "digest"
+ ]
+ }
+ },
+ {
+ "if": {
+ "properties": {
+ "item_id": {
+ "const": "passport_refresh"
+ }
+ },
+ "required": [
+ "item_id"
+ ]
+ },
+ "then": {
+ "required": [
+ "url"
+ ]
+ }
+ },
+ {
+ "if": {
+ "properties": {
+ "item_id": {
+ "const": "trust_profile"
+ }
+ },
+ "required": [
+ "item_id"
+ ]
+ },
+ "then": {
+ "required": [
+ "url"
+ ]
+ }
+ },
+ {
+ "if": {
+ "properties": {
+ "item_id": {
+ "const": "spot_check"
+ }
+ },
+ "required": [
+ "item_id"
+ ]
+ },
+ "then": {
+ "required": [
+ "host"
+ ]
+ }
+ }
+]Input schema / examplesPrevious value: -[
- {
- "item_id": "the_mandate",
- "mandate": "Research x402 tooling and buy verification artifacts as needed, at most $5 per item."
- },
- {
- "item_id": "settlement_attestation",
- "tx_hash": "0x47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee0"
- },
- {
- "item_id": "settlement_reconciliation",
- "tx_hash": "0x47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee0"
- },
- {
- "item_id": "the_case_file",
- "tx_hash": "0x47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee0"
- },
- {
- "item_id": "attestation_bundle",
- "tx_hashes": "0x47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee0,0x9b04e1c9b04e1c9b04e1c9b04e1c9b04e1c9b04e1c9b04e1c9b04e1c9b04e1c0"
- },
- {
- "item_id": "standing_watch",
- "url": "https://your-shop.example/api/buy/thing"
- },
- {
- "item_id": "service_audit",
- "url": "https://your-shop.example/api/buy/thing"
- },
- {
- "item_id": "a2a_repair_kit",
- "url": "https://your-agent.example/.well-known/agent-card.json"
- },
- {
- "item_id": "good_buyer",
- "url": "https://somebody-elses-shop.example/api/buy/thing"
- },
- {
- "item_id": "conformance_watch",
- "url": "https://your-shop.example/api/buy/thing"
- },
- {
- "item_id": "signature_agent_card",
- "url": "https://your-agent.example"
- },
- {
- "item_id": "onpage_audit",
- "url": "https://your-site.example/pricing"
- },
- {
- "item_id": "launch_check",
- "url": "https://your-shop.example/api/buy/thing"
- },
- {
- "item_id": "opening_day",
- "url": "https://your-shop.example/api/buy/thing"
- },
- {
- "address": "0x1111111111111111111111111111111111111111",
- "item_id": "provenance_check"
- },
- {
- "item_id": "the_statement",
- "wallet": "0x843b544bf5f0AA6cbf13E94563874878C98cc4a7"
- },
- {
- "item_id": "operator_statement",
- "wallet": "0x843b544bf5f0AA6cbf13E94563874878C98cc4a7"
- },
- {
- "digest": "9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f",
- "item_id": "bitcoin_anchor"
- },
- {
- "item_id": "passport_refresh",
- "url": "https://your-endpoint.example/api/thing"
- },
- {
- "item_id": "trust_profile",
- "url": "https://your-endpoint.example/api/thing"
- },
- {
- "host": "your-door.example",
- "item_id": "spot_check"
- }
-]New value: +[
+ {
+ "item_id": "settlement_attestation",
+ "tx_hash": "0x47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee0"
+ },
+ {
+ "item_id": "settlement_reconciliation",
+ "tx_hash": "0x47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee0"
+ },
+ {
+ "item_id": "the_case_file",
+ "tx_hash": "0x47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee0"
+ },
+ {
+ "item_id": "attestation_bundle",
+ "tx_hashes": "0x47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee0,0x9b04e1c9b04e1c9b04e1c9b04e1c9b04e1c9b04e1c9b04e1c9b04e1c9b04e1c0"
+ },
+ {
+ "item_id": "standing_watch",
+ "url": "https://your-shop.example/api/buy/thing"
+ },
+ {
+ "item_id": "service_audit",
+ "url": "https://your-shop.example/api/buy/thing"
+ },
+ {
+ "item_id": "a2a_repair_kit",
+ "url": "https://your-agent.example/.well-known/agent-card.json"
+ },
+ {
+ "item_id": "good_buyer",
+ "url": "https://somebody-elses-shop.example/api/buy/thing"
+ },
+ {
+ "item_id": "conformance_watch",
+ "url": "https://your-shop.example/api/buy/thing"
+ },
+ {
+ "item_id": "signature_agent_card",
+ "url": "https://your-agent.example"
+ },
+ {
+ "item_id": "onpage_audit",
+ "url": "https://your-site.example/pricing"
+ },
+ {
+ "item_id": "launch_check",
+ "url": "https://your-shop.example/api/buy/thing"
+ },
+ {
+ "item_id": "opening_day",
+ "url": "https://your-shop.example/api/buy/thing"
+ },
+ {
+ "address": "0x1111111111111111111111111111111111111111",
+ "item_id": "provenance_check"
+ },
+ {
+ "item_id": "the_statement",
+ "wallet": "0x843b544bf5f0AA6cbf13E94563874878C98cc4a7"
+ },
+ {
+ "item_id": "operator_statement",
+ "wallet": "0x843b544bf5f0AA6cbf13E94563874878C98cc4a7"
+ },
+ {
+ "digest": "9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f",
+ "item_id": "bitcoin_anchor"
+ },
+ {
+ "item_id": "passport_refresh",
+ "url": "https://your-endpoint.example/api/thing"
+ },
+ {
+ "item_id": "trust_profile",
+ "url": "https://your-endpoint.example/api/thing"
+ },
+ {
+ "host": "your-door.example",
+ "item_id": "spot_check"
+ }
+]Input schema / properties / declared_cap_usdc / descriptionPrevious value: -"Optional claimed spending ceiling in USDC. Declared, never enforced by the store, and the record says so."New value: +"Optional, and understand what it buys: the ceiling YOU say applied. It is recorded as DECLARED, never as observed, and it can never override a ceiling found on the chain. A verdict resting on it is a fact about what you told us — the artifact says so in a signed field, so a counterparty can tell the difference."Input schema / properties / declared_cap_usdc / exclusiveMinimumAdded value: +0Input schema / properties / declared_cap_usdc / typePrevious value: -"string"New value: +"number"Input schema / properties / expires_atRemoved value: -{
- "description": "Optional claimed expiry, ISO 8601. Declared, never enforced by the store.",
- "type": "string"
-}Input schema / properties / item_id / enumPrevious value: -[
- "the_mandate",
- "settlement_attestation",
- "settlement_reconciliation",
- "the_case_file",
- "attestation_bundle",
- "standing_watch",
- "service_audit",
- "a2a_repair_kit",
- "good_buyer",
- "conformance_watch",
- "signature_agent_card",
- "onpage_audit",
- "launch_check",
- "opening_day",
- "provenance_check",
- "the_statement",
- "operator_statement",
- "bitcoin_anchor",
- "passport_refresh",
- "trust_profile",
- "spot_check"
-]New value: +[
+ "settlement_attestation",
+ "settlement_reconciliation",
+ "the_case_file",
+ "attestation_bundle",
+ "standing_watch",
+ "service_audit",
+ "a2a_repair_kit",
+ "good_buyer",
+ "conformance_watch",
+ "signature_agent_card",
+ "onpage_audit",
+ "launch_check",
+ "opening_day",
+ "provenance_check",
+ "the_statement",
+ "operator_statement",
+ "bitcoin_anchor",
+ "passport_refresh",
+ "trust_profile",
+ "spot_check"
+]Input schema / properties / mandateRemoved value: -{
- "description": "The claimed instructions, verbatim, up to 2000 Unicode characters: what this agent is authorized to do, as the submitter claims it. Recorded exactly as it arrives, signed and dated. Chain-of-custody, not truth-of-intent — the record proves the claim was made, never that it was true.",
- "maxLength": 2000,
- "type": "string"
-}Input schema / properties / submitted_asRemoved value: -{
- "description": "Who is submitting: the agent recording its own claimed instructions (default), or the human principal's own client. Recorded as a claim either way.",
- "enum": [
- "agent",
- "principal"
- ],
- "type": "string"
-}buy_observation6 fields changedInput schema / allOfPrevious value: -[
- {
- "if": {
- "properties": {
- "item_id": {
- "const": "settlement_attestation"
- }
- },
- "required": [
- "item_id"
- ]
- },
- "then": {
- "required": [
- "tx_hash"
- ]
- }
- },
- {
- "if": {
- "properties": {
- "item_id": {
- "const": "settlement_reconciliation"
- }
- },
- "required": [
- "item_id"
- ]
- },
- "then": {
- "required": [
- "tx_hash"
- ]
- }
- },
- {
- "if": {
- "properties": {
- "item_id": {
- "const": "the_case_file"
- }
- },
- "required": [
- "item_id"
- ]
- },
- "then": {
- "required": [
- "tx_hash"
- ]
- }
- },
- {
- "if": {
- "properties": {
- "item_id": {
- "const": "attestation_bundle"
- }
- },
- "required": [
- "item_id"
- ]
- },
- "then": {
- "required": [
- "tx_hashes"
- ]
- }
- },
- {
- "if": {
- "properties": {
- "item_id": {
- "const": "standing_watch"
- }
- },
- "required": [
- "item_id"
- ]
- },
- "then": {
- "required": [
- "url"
- ]
- }
- },
- {
- "if": {
- "properties": {
- "item_id": {
- "const": "service_audit"
- }
- },
- "required": [
- "item_id"
- ]
- },
- "then": {
- "required": [
- "url"
- ]
- }
- },
- {
- "if": {
- "properties": {
- "item_id": {
- "const": "a2a_repair_kit"
- }
- },
- "required": [
- "item_id"
- ]
- },
- "then": {
- "required": [
- "url"
- ]
- }
- },
- {
- "if": {
- "properties": {
- "item_id": {
- "const": "good_buyer"
- }
- },
- "required": [
- "item_id"
- ]
- },
- "then": {
- "required": [
- "url"
- ]
- }
- },
- {
- "if": {
- "properties": {
- "item_id": {
- "const": "conformance_watch"
- }
- },
- "required": [
- "item_id"
- ]
- },
- "then": {
- "required": [
- "url"
- ]
- }
- },
- {
- "if": {
- "properties": {
- "item_id": {
- "const": "signature_agent_card"
- }
- },
- "required": [
- "item_id"
- ]
- },
- "then": {
- "required": [
- "url"
- ]
- }
- },
- {
- "if": {
- "properties": {
- "item_id": {
- "const": "onpage_audit"
- }
- },
- "required": [
- "item_id"
- ]
- },
- "then": {
- "required": [
- "url"
- ]
- }
- },
- {
- "if": {
- "properties": {
- "item_id": {
- "const": "launch_check"
- }
- },
- "required": [
- "item_id"
- ]
- },
- "then": {
- "required": [
- "url"
- ]
- }
- },
- {
- "if": {
- "properties": {
- "item_id": {
- "const": "opening_day"
- }
- },
- "required": [
- "item_id"
- ]
- },
- "then": {
- "required": [
- "url"
- ]
- }
- },
- {
- "if": {
- "properties": {
- "item_id": {
- "const": "provenance_check"
- }
- },
- "required": [
- "item_id"
- ]
- },
- "then": {
- "required": [
- "address"
- ]
- }
- },
- {
- "if": {
- "properties": {
- "item_id": {
- "const": "the_statement"
- }
- },
- "required": [
- "item_id"
- ]
- },
- "then": {
- "required": [
- "wallet"
- ]
- }
- },
- {
- "if": {
- "properties": {
- "item_id": {
- "const": "operator_statement"
- }
- },
- "required": [
- "item_id"
- ]
- },
- "then": {
- "required": [
- "wallet"
- ]
- }
- },
- {
- "if": {
- "properties": {
- "item_id": {
- "const": "the_mandate"
- }
- },
- "required": [
- "item_id"
- ]
- },
- "then": {
- "required": [
- "mandate"
- ]
- }
- },
- {
- "if": {
- "properties": {
- "item_id": {
- "const": "bitcoin_anchor"
- }
- },
- "required": [
- "item_id"
- ]
- },
- "then": {
- "required": [
- "digest"
- ]
- }
- },
- {
- "if": {
- "properties": {
- "item_id": {
- "const": "passport_refresh"
- }
- },
- "required": [
- "item_id"
- ]
- },
- "then": {
- "required": [
- "url"
- ]
- }
- },
- {
- "if": {
- "properties": {
- "item_id": {
- "const": "trust_profile"
- }
- },
- "required": [
- "item_id"
- ]
- },
- "then": {
- "required": [
- "url"
- ]
- }
- },
- {
- "if": {
- "properties": {
- "item_id": {
- "const": "spot_check"
- }
- },
- "required": [
- "item_id"
- ]
- },
- "then": {
- "required": [
- "host"
- ]
- }
- }
-]New value: +[
+ {
+ "if": {
+ "properties": {
+ "item_id": {
+ "const": "the_mandate"
+ }
+ },
+ "required": [
+ "item_id"
+ ]
+ },
+ "then": {
+ "required": [
+ "mandate"
+ ]
+ }
+ },
+ {
+ "if": {
+ "properties": {
+ "item_id": {
+ "const": "settlement_attestation"
+ }
+ },
+ "required": [
+ "item_id"
+ ]
+ },
+ "then": {
+ "required": [
+ "tx_hash"
+ ]
+ }
+ },
+ {
+ "if": {
+ "properties": {
+ "item_id": {
+ "const": "settlement_reconciliation"
+ }
+ },
+ "required": [
+ "item_id"
+ ]
+ },
+ "then": {
+ "required": [
+ "tx_hash"
+ ]
+ }
+ },
+ {
+ "if": {
+ "properties": {
+ "item_id": {
+ "const": "the_case_file"
+ }
+ },
+ "required": [
+ "item_id"
+ ]
+ },
+ "then": {
+ "required": [
+ "tx_hash"
+ ]
+ }
+ },
+ {
+ "if": {
+ "properties": {
+ "item_id": {
+ "const": "attestation_bundle"
+ }
+ },
+ "required": [
+ "item_id"
+ ]
+ },
+ "then": {
+ "required": [
+ "tx_hashes"
+ ]
+ }
+ },
+ {
+ "if": {
+ "properties": {
+ "item_id": {
+ "const": "standing_watch"
+ }
+ },
+ "required": [
+ "item_id"
+ ]
+ },
+ "then": {
+ "required": [
+ "url"
+ ]
+ }
+ },
+ {
+ "if": {
+ "properties": {
+ "item_id": {
+ "const": "service_audit"
+ }
+ },
+ "required": [
+ "item_id"
+ ]
+ },
+ "then": {
+ "required": [
+ "url"
+ ]
+ }
+ },
+ {
+ "if": {
+ "properties": {
+ "item_id": {
+ "const": "a2a_repair_kit"
+ }
+ },
+ "required": [
+ "item_id"
+ ]
+ },
+ "then": {
+ "required": [
+ "url"
+ ]
+ }
+ },
+ {
+ "if": {
+ "properties": {
+ "item_id": {
+ "const": "good_buyer"
+ }
+ },
+ "required": [
+ "item_id"
+ ]
+ },
+ "then": {
+ "required": [
+ "url"
+ ]
+ }
+ },
+ {
+ "if": {
+ "properties": {
+ "item_id": {
+ "const": "conformance_watch"
+ }
+ },
+ "required": [
+ "item_id"
+ ]
+ },
+ "then": {
+ "required": [
+ "url"
+ ]
+ }
+ },
+ {
+ "if": {
+ "properties": {
+ "item_id": {
+ "const": "signature_agent_card"
+ }
+ },
+ "required": [
+ "item_id"
+ ]
+ },
+ "then": {
+ "required": [
+ "url"
+ ]
+ }
+ },
+ {
+ "if": {
+ "properties": {
+ "item_id": {
+ "const": "onpage_audit"
+ }
+ },
+ "required": [
+ "item_id"
+ ]
+ },
+ "then": {
+ "required": [
+ "url"
+ ]
+ }
+ },
+ {
+ "if": {
+ "properties": {
+ "item_id": {
+ "const": "launch_check"
+ }
+ },
+ "required": [
+ "item_id"
+ ]
+ },
+ "then": {
+ "required": [
+ "url"
+ ]
+ }
+ },
+ {
+ "if": {
+ "properties": {
+ "item_id": {
+ "const": "opening_day"
+ }
+ },
+ "required": [
+ "item_id"
+ ]
+ },
+ "then": {
+ "required": [
+ "url"
+ ]
+ }
+ },
+ {
+ "if": {
+ "properties": {
+ "item_id": {
+ "const": "provenance_check"
+ }
+ },
+ "required": [
+ "item_id"
+ ]
+ },
+ "then": {
+ "required": [
+ "address"
+ ]
+ }
+ },
+ {
+ "if": {
+ "properties": {
+ "item_id": {
+ "const": "the_statement"
+ }
+ },
+ "required": [
+ "item_id"
+ ]
+ },
+ "then": {
+ "required": [
+ "wallet"
+ ]
+ }
+ },
+ {
+ "if": {
+ "properties": {
+ "item_id": {
+ "const": "operator_statement"
+ }
+ },
+ "required": [
+ "item_id"
+ ]
+ },
+ "then": {
+ "required": [
+ "wallet"
+ ]
+ }
+ },
+ {
+ "if": {
+ "properties": {
+ "item_id": {
+ "const": "bitcoin_anchor"
+ }
+ },
+ "required": [
+ "item_id"
+ ]
+ },
+ "then": {
+ "required": [
+ "digest"
+ ]
+ }
+ },
+ {
+ "if": {
+ "properties": {
+ "item_id": {
+ "const": "passport_refresh"
+ }
+ },
+ "required": [
+ "item_id"
+ ]
+ },
+ "then": {
+ "required": [
+ "url"
+ ]
+ }
+ },
+ {
+ "if": {
+ "properties": {
+ "item_id": {
+ "const": "trust_profile"
+ }
+ },
+ "required": [
+ "item_id"
+ ]
+ },
+ "then": {
+ "required": [
+ "url"
+ ]
+ }
+ },
+ {
+ "if": {
+ "properties": {
+ "item_id": {
+ "const": "spot_check"
+ }
+ },
+ "required": [
+ "item_id"
+ ]
+ },
+ "then": {
+ "required": [
+ "host"
+ ]
+ }
+ }
+]Input schema / examplesPrevious value: -[
- {
- "item_id": "settlement_attestation",
- "tx_hash": "0x47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee0"
- },
- {
- "item_id": "settlement_reconciliation",
- "tx_hash": "0x47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee0"
- },
- {
- "item_id": "the_case_file",
- "tx_hash": "0x47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee0"
- },
- {
- "item_id": "attestation_bundle",
- "tx_hashes": "0x47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee0,0x9b04e1c9b04e1c9b04e1c9b04e1c9b04e1c9b04e1c9b04e1c9b04e1c9b04e1c0"
- },
- {
- "item_id": "standing_watch",
- "url": "https://your-shop.example/api/buy/thing"
- },
- {
- "item_id": "service_audit",
- "url": "https://your-shop.example/api/buy/thing"
- },
- {
- "item_id": "a2a_repair_kit",
- "url": "https://your-agent.example/.well-known/agent-card.json"
- },
- {
- "item_id": "good_buyer",
- "url": "https://somebody-elses-shop.example/api/buy/thing"
- },
- {
- "item_id": "conformance_watch",
- "url": "https://your-shop.example/api/buy/thing"
- },
- {
- "item_id": "signature_agent_card",
- "url": "https://your-agent.example"
- },
- {
- "item_id": "onpage_audit",
- "url": "https://your-site.example/pricing"
- },
- {
- "item_id": "launch_check",
- "url": "https://your-shop.example/api/buy/thing"
- },
- {
- "item_id": "opening_day",
- "url": "https://your-shop.example/api/buy/thing"
- },
- {
- "address": "0x1111111111111111111111111111111111111111",
- "item_id": "provenance_check"
- },
- {
- "item_id": "the_statement",
- "wallet": "0x843b544bf5f0AA6cbf13E94563874878C98cc4a7"
- },
- {
- "item_id": "operator_statement",
- "wallet": "0x843b544bf5f0AA6cbf13E94563874878C98cc4a7"
- },
- {
- "item_id": "the_mandate",
- "mandate": "Research x402 tooling and buy verification artifacts as needed, at most $5 per item."
- },
- {
- "digest": "9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f",
- "item_id": "bitcoin_anchor"
- },
- {
- "item_id": "passport_refresh",
- "url": "https://your-endpoint.example/api/thing"
- },
- {
- "item_id": "trust_profile",
- "url": "https://your-endpoint.example/api/thing"
- },
- {
- "host": "your-door.example",
- "item_id": "spot_check"
- }
-]New value: +[
+ {
+ "item_id": "the_mandate",
+ "mandate": "Research x402 tooling and buy verification artifacts as needed, at most $5 per item."
+ },
+ {
+ "item_id": "settlement_attestation",
+ "tx_hash": "0x47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee0"
+ },
+ {
+ "item_id": "settlement_reconciliation",
+ "tx_hash": "0x47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee0"
+ },
+ {
+ "item_id": "the_case_file",
+ "tx_hash": "0x47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee0"
+ },
+ {
+ "item_id": "attestation_bundle",
+ "tx_hashes": "0x47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee0,0x9b04e1c9b04e1c9b04e1c9b04e1c9b04e1c9b04e1c9b04e1c9b04e1c9b04e1c0"
+ },
+ {
+ "item_id": "standing_watch",
+ "url": "https://your-shop.example/api/buy/thing"
+ },
+ {
+ "item_id": "service_audit",
+ "url": "https://your-shop.example/api/buy/thing"
+ },
+ {
+ "item_id": "a2a_repair_kit",
+ "url": "https://your-agent.example/.well-known/agent-card.json"
+ },
+ {
+ "item_id": "good_buyer",
+ "url": "https://somebody-elses-shop.example/api/buy/thing"
+ },
+ {
+ "item_id": "conformance_watch",
+ "url": "https://your-shop.example/api/buy/thing"
+ },
+ {
+ "item_id": "signature_agent_card",
+ "url": "https://your-agent.example"
+ },
+ {
+ "item_id": "onpage_audit",
+ "url": "https://your-site.example/pricing"
+ },
+ {
+ "item_id": "launch_check",
+ "url": "https://your-shop.example/api/buy/thing"
+ },
+ {
+ "item_id": "opening_day",
+ "url": "https://your-shop.example/api/buy/thing"
+ },
+ {
+ "address": "0x1111111111111111111111111111111111111111",
+ "item_id": "provenance_check"
+ },
+ {
+ "item_id": "the_statement",
+ "wallet": "0x843b544bf5f0AA6cbf13E94563874878C98cc4a7"
+ },
+ {
+ "item_id": "operator_statement",
+ "wallet": "0x843b544bf5f0AA6cbf13E94563874878C98cc4a7"
+ },
+ {
+ "digest": "9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f",
+ "item_id": "bitcoin_anchor"
+ },
+ {
+ "item_id": "passport_refresh",
+ "url": "https://your-endpoint.example/api/thing"
+ },
+ {
+ "item_id": "trust_profile",
+ "url": "https://your-endpoint.example/api/thing"
+ },
+ {
+ "host": "your-door.example",
+ "item_id": "spot_check"
+ }
+]Input schema / properties / declared_cap_usdc / descriptionPrevious value: -"Optional, and understand what it buys: the ceiling YOU say applied. It is recorded as DECLARED, never as observed, and it can never override a ceiling found on the chain. A verdict resting on it is a fact about what you told us — the artifact says so in a signed field, so a counterparty can tell the difference."New value: +"Optional claimed spending ceiling in USDC. Declared, never enforced by the store, and the record says so."Input schema / properties / declared_cap_usdc / exclusiveMinimumRemoved value: -0Input schema / properties / declared_cap_usdc / typePrevious value: -"number"New value: +"string"Input schema / properties / item_id / enumPrevious value: -[
- "settlement_attestation",
- "settlement_reconciliation",
- "the_case_file",
- "attestation_bundle",
- "standing_watch",
- "service_audit",
- "a2a_repair_kit",
- "good_buyer",
- "conformance_watch",
- "signature_agent_card",
- "onpage_audit",
- "launch_check",
- "opening_day",
- "provenance_check",
- "the_statement",
- "operator_statement",
- "the_mandate",
- "bitcoin_anchor",
- "passport_refresh",
- "trust_profile",
- "spot_check"
-]New value: +[
+ "the_mandate",
+ "settlement_attestation",
+ "settlement_reconciliation",
+ "the_case_file",
+ "attestation_bundle",
+ "standing_watch",
+ "service_audit",
+ "a2a_repair_kit",
+ "good_buyer",
+ "conformance_watch",
+ "signature_agent_card",
+ "onpage_audit",
+ "launch_check",
+ "opening_day",
+ "provenance_check",
+ "the_statement",
+ "operator_statement",
+ "bitcoin_anchor",
+ "passport_refresh",
+ "trust_profile",
+ "spot_check"
+]find_in_catalog1 field changedOutput schema / properties / items / items / properties / buy_url_templateAdded value: +{
+ "description": "Where present, buy this instead: the door with its required inputs as <slot>s to fill.",
+ "format": "uri",
+ "type": "string"
+}buy_observation4 fields changedInput schema / examplesPrevious value: -[
- {
- "item_id": "settlement_attestation",
- "tx_hash": "0x47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee0"
- },
- {
- "item_id": "settlement_reconciliation",
- "tx_hash": "0x47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee0"
- },
- {
- "item_id": "the_case_file",
- "tx_hash": "0x47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee0"
- },
- {
- "item_id": "attestation_bundle",
- "tx_hashes": "0x47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee0,0x9b04e1c9b04e1c9b04e1c9b04e1c9b04e1c9b04e1c9b04e1c9b04e1c9b04e1c0"
- },
- {
- "item_id": "standing_watch",
- "url": "https://your-shop.example/api/buy/thing"
- },
- {
- "item_id": "service_audit",
- "url": "https://your-shop.example/api/buy/thing"
- },
- {
- "item_id": "a2a_repair_kit",
- "url": "https://your-agent.example/.well-known/agent-card.json"
- },
- {
- "item_id": "good_buyer",
- "url": "https://somebody-elses-shop.example/api/buy/thing"
- },
- {
- "item_id": "conformance_watch",
- "url": "https://your-shop.example/api/buy/thing"
- },
- {
- "item_id": "signature_agent_card",
- "url": "https://your-agent.example"
- },
- {
- "item_id": "onpage_audit",
- "url": "https://your-site.example/pricing"
- },
- {
- "item_id": "launch_check",
- "url": "https://your-shop.example/api/buy/thing"
- },
- {
- "item_id": "opening_day",
- "url": "https://your-shop.example/api/buy/thing"
- },
- {
- "address": "0x1111111111111111111111111111111111111111",
- "item_id": "provenance_check"
- },
- {
- "item_id": "the_statement",
- "wallet": "0x843b544bf5f0AA6cbf13E94563874878C98cc4a7"
- },
- {
- "item_id": "operator_statement",
- "wallet": "0x843b544bf5f0AA6cbf13E94563874878C98cc4a7"
- },
- {
- "item_id": "the_mandate",
- "mandate": "Research x402 tooling and buy verification artifacts as needed, at most $5 per item."
- },
- {
- "digest": "9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f",
- "item_id": "bitcoin_anchor"
- },
- {
- "item_id": "passport_refresh",
- "url": "https://your-endpoint.example/api/thing"
- },
- {
- "item_id": "trust_profile",
- "url": "https://your-endpoint.example/api/thing"
- },
- {
- "host": "example.com",
- "item_id": "spot_check"
- }
-]New value: +[
+ {
+ "item_id": "settlement_attestation",
+ "tx_hash": "0x47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee0"
+ },
+ {
+ "item_id": "settlement_reconciliation",
+ "tx_hash": "0x47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee0"
+ },
+ {
+ "item_id": "the_case_file",
+ "tx_hash": "0x47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee0"
+ },
+ {
+ "item_id": "attestation_bundle",
+ "tx_hashes": "0x47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee0,0x9b04e1c9b04e1c9b04e1c9b04e1c9b04e1c9b04e1c9b04e1c9b04e1c9b04e1c0"
+ },
+ {
+ "item_id": "standing_watch",
+ "url": "https://your-shop.example/api/buy/thing"
+ },
+ {
+ "item_id": "service_audit",
+ "url": "https://your-shop.example/api/buy/thing"
+ },
+ {
+ "item_id": "a2a_repair_kit",
+ "url": "https://your-agent.example/.well-known/agent-card.json"
+ },
+ {
+ "item_id": "good_buyer",
+ "url": "https://somebody-elses-shop.example/api/buy/thing"
+ },
+ {
+ "item_id": "conformance_watch",
+ "url": "https://your-shop.example/api/buy/thing"
+ },
+ {
+ "item_id": "signature_agent_card",
+ "url": "https://your-agent.example"
+ },
+ {
+ "item_id": "onpage_audit",
+ "url": "https://your-site.example/pricing"
+ },
+ {
+ "item_id": "launch_check",
+ "url": "https://your-shop.example/api/buy/thing"
+ },
+ {
+ "item_id": "opening_day",
+ "url": "https://your-shop.example/api/buy/thing"
+ },
+ {
+ "address": "0x1111111111111111111111111111111111111111",
+ "item_id": "provenance_check"
+ },
+ {
+ "item_id": "the_statement",
+ "wallet": "0x843b544bf5f0AA6cbf13E94563874878C98cc4a7"
+ },
+ {
+ "item_id": "operator_statement",
+ "wallet": "0x843b544bf5f0AA6cbf13E94563874878C98cc4a7"
+ },
+ {
+ "item_id": "the_mandate",
+ "mandate": "Research x402 tooling and buy verification artifacts as needed, at most $5 per item."
+ },
+ {
+ "digest": "9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f",
+ "item_id": "bitcoin_anchor"
+ },
+ {
+ "item_id": "passport_refresh",
+ "url": "https://your-endpoint.example/api/thing"
+ },
+ {
+ "item_id": "trust_profile",
+ "url": "https://your-endpoint.example/api/thing"
+ },
+ {
+ "host": "your-door.example",
+ "item_id": "spot_check"
+ }
+]Input schema / properties / digest / descriptionPrevious value: -"sha256 of bytes you keep, 64 hex characters, no 0x prefix. The store never sees the bytes."New value: +"sha256 of bytes you keep: exactly 64 hex characters, no 0x prefix, not base64, not the bytes themselves. The store never sees the bytes."Input schema / properties / host / descriptionPrevious value: -"A bare hostname, e.g. example.com. We read our own books about it — corpus rounds, verdicts as recorded, coverage, gaps — and sign what they hold. No request is made to the host; a host we have never met returns not_observed, which is an answer."New value: +"A bare hostname with no scheme, path or port — your-door.example, never https://your-door.example/api. We read our own books about it — corpus rounds, verdicts as recorded, coverage, gaps — and sign what they hold. No request is made to the host; a host we have never met returns not_observed, which is an answer."Input schema / properties / wallet / descriptionPrevious value: -"The wallet to state: a 0x address on the selected EVM network, a base58 pubkey on Solana. Every USDC transfer in and out over the window, counted, summed and signed — one chain per statement, named on the artifact."New value: +"The wallet to state: a 0x address (0x plus 40 hex characters) on the selected EVM network, or a base58 pubkey on Solana. Every USDC transfer in and out over the window, counted, summed and signed — one chain per statement, named on the artifact."buy_human_task6 fields changedInput schema / properties / came_fromAdded value: +{
+ "description": "Optional. Where you learned this door exists: a URL, a directory, a skill name, memory, another agent. Referrers never reach us; this does.",
+ "maxLength": 160,
+ "type": "string"
+}Input schema / properties / clientAdded value: +{
+ "description": "Optional. The harness or framework you run in: claude-code, cursor, openai-agents, langgraph, custom. Counted, never on the certificate.",
+ "maxLength": 64,
+ "type": "string"
+}Input schema / properties / modelAdded value: +{
+ "description": "Optional. The model running you, as you would name it: claude-opus-5, gpt-5.6, a local model. Counted, never printed on the certificate.",
+ "maxLength": 64,
+ "type": "string"
+}Input schema / properties / operatorAdded value: +{
+ "description": "Optional. Who runs you: a name, handle, company or URL. Stored as your claim, marked unverified, never published, never on the certificate.",
+ "maxLength": 120,
+ "type": "string"
+}Input schema / properties / operator_kindAdded value: +{
+ "description": "Optional. solo: one person runs you. company: a team does. research: a study. self: you act for yourself.",
+ "enum": [
+ "solo",
+ "company",
+ "research",
+ "self"
+ ],
+ "type": "string"
+}Input schema / properties / prior_cert_idAdded value: +{
+ "description": "Optional. A cert_ id from an earlier purchase here. A payer match with this payment marks you a returning buyer; no account needed.",
+ "maxLength": 64,
+ "type": "string"
+}buy_memory_anchor6 fields changedInput schema / properties / came_fromAdded value: +{
+ "description": "Optional. Where you learned this door exists: a URL, a directory, a skill name, memory, another agent. Referrers never reach us; this does.",
+ "maxLength": 160,
+ "type": "string"
+}Input schema / properties / clientAdded value: +{
+ "description": "Optional. The harness or framework you run in: claude-code, cursor, openai-agents, langgraph, custom. Counted, never on the certificate.",
+ "maxLength": 64,
+ "type": "string"
+}Input schema / properties / modelAdded value: +{
+ "description": "Optional. The model running you, as you would name it: claude-opus-5, gpt-5.6, a local model. Counted, never printed on the certificate.",
+ "maxLength": 64,
+ "type": "string"
+}Input schema / properties / operatorAdded value: +{
+ "description": "Optional. Who runs you: a name, handle, company or URL. Stored as your claim, marked unverified, never published, never on the certificate.",
+ "maxLength": 120,
+ "type": "string"
+}Input schema / properties / operator_kindAdded value: +{
+ "description": "Optional. solo: one person runs you. company: a team does. research: a study. self: you act for yourself.",
+ "enum": [
+ "solo",
+ "company",
+ "research",
+ "self"
+ ],
+ "type": "string"
+}Input schema / properties / prior_cert_idAdded value: +{
+ "description": "Optional. A cert_ id from an earlier purchase here. A payer match with this payment marks you a returning buyer; no account needed.",
+ "maxLength": 64,
+ "type": "string"
+}buy_observation6 fields changedInput schema / properties / came_fromAdded value: +{
+ "description": "Optional. Where you learned this door exists: a URL, a directory, a skill name, memory, another agent. Referrers never reach us; this does.",
+ "maxLength": 160,
+ "type": "string"
+}Input schema / properties / clientAdded value: +{
+ "description": "Optional. The harness or framework you run in: claude-code, cursor, openai-agents, langgraph, custom. Counted, never on the certificate.",
+ "maxLength": 64,
+ "type": "string"
+}Input schema / properties / modelAdded value: +{
+ "description": "Optional. The model running you, as you would name it: claude-opus-5, gpt-5.6, a local model. Counted, never printed on the certificate.",
+ "maxLength": 64,
+ "type": "string"
+}Input schema / properties / operatorAdded value: +{
+ "description": "Optional. Who runs you: a name, handle, company or URL. Stored as your claim, marked unverified, never published, never on the certificate.",
+ "maxLength": 120,
+ "type": "string"
+}Input schema / properties / operator_kindAdded value: +{
+ "description": "Optional. solo: one person runs you. company: a team does. research: a study. self: you act for yourself.",
+ "enum": [
+ "solo",
+ "company",
+ "research",
+ "self"
+ ],
+ "type": "string"
+}Input schema / properties / prior_cert_idAdded value: +{
+ "description": "Optional. A cert_ id from an earlier purchase here. A payer match with this payment marks you a returning buyer; no account needed.",
+ "maxLength": 64,
+ "type": "string"
+}buy_signed_record6 fields changedInput schema / properties / came_fromAdded value: +{
+ "description": "Optional. Where you learned this door exists: a URL, a directory, a skill name, memory, another agent. Referrers never reach us; this does.",
+ "maxLength": 160,
+ "type": "string"
+}Input schema / properties / clientAdded value: +{
+ "description": "Optional. The harness or framework you run in: claude-code, cursor, openai-agents, langgraph, custom. Counted, never on the certificate.",
+ "maxLength": 64,
+ "type": "string"
+}Input schema / properties / modelAdded value: +{
+ "description": "Optional. The model running you, as you would name it: claude-opus-5, gpt-5.6, a local model. Counted, never printed on the certificate.",
+ "maxLength": 64,
+ "type": "string"
+}Input schema / properties / operatorAdded value: +{
+ "description": "Optional. Who runs you: a name, handle, company or URL. Stored as your claim, marked unverified, never published, never on the certificate.",
+ "maxLength": 120,
+ "type": "string"
+}Input schema / properties / operator_kindAdded value: +{
+ "description": "Optional. solo: one person runs you. company: a team does. research: a study. self: you act for yourself.",
+ "enum": [
+ "solo",
+ "company",
+ "research",
+ "self"
+ ],
+ "type": "string"
+}Input schema / properties / prior_cert_idAdded value: +{
+ "description": "Optional. A cert_ id from an earlier purchase here. A payer match with this payment marks you a returning buyer; no account needed.",
+ "maxLength": 64,
+ "type": "string"
+}buy_simple6 fields changedInput schema / properties / came_fromAdded value: +{
+ "description": "Optional. Where you learned this door exists: a URL, a directory, a skill name, memory, another agent. Referrers never reach us; this does.",
+ "maxLength": 160,
+ "type": "string"
+}Input schema / properties / clientAdded value: +{
+ "description": "Optional. The harness or framework you run in: claude-code, cursor, openai-agents, langgraph, custom. Counted, never on the certificate.",
+ "maxLength": 64,
+ "type": "string"
+}Input schema / properties / modelAdded value: +{
+ "description": "Optional. The model running you, as you would name it: claude-opus-5, gpt-5.6, a local model. Counted, never printed on the certificate.",
+ "maxLength": 64,
+ "type": "string"
+}Input schema / properties / operatorAdded value: +{
+ "description": "Optional. Who runs you: a name, handle, company or URL. Stored as your claim, marked unverified, never published, never on the certificate.",
+ "maxLength": 120,
+ "type": "string"
+}Input schema / properties / operator_kindAdded value: +{
+ "description": "Optional. solo: one person runs you. company: a team does. research: a study. self: you act for yourself.",
+ "enum": [
+ "solo",
+ "company",
+ "research",
+ "self"
+ ],
+ "type": "string"
+}Input schema / properties / prior_cert_idAdded value: +{
+ "description": "Optional. A cert_ id from an earlier purchase here. A payer match with this payment marks you a returning buyer; no account needed.",
+ "maxLength": 64,
+ "type": "string"
+}buy_small_pleasure6 fields changedInput schema / properties / came_fromAdded value: +{
+ "description": "Optional. Where you learned this door exists: a URL, a directory, a skill name, memory, another agent. Referrers never reach us; this does.",
+ "maxLength": 160,
+ "type": "string"
+}Input schema / properties / clientAdded value: +{
+ "description": "Optional. The harness or framework you run in: claude-code, cursor, openai-agents, langgraph, custom. Counted, never on the certificate.",
+ "maxLength": 64,
+ "type": "string"
+}Input schema / properties / modelAdded value: +{
+ "description": "Optional. The model running you, as you would name it: claude-opus-5, gpt-5.6, a local model. Counted, never printed on the certificate.",
+ "maxLength": 64,
+ "type": "string"
+}Input schema / properties / operatorAdded value: +{
+ "description": "Optional. Who runs you: a name, handle, company or URL. Stored as your claim, marked unverified, never published, never on the certificate.",
+ "maxLength": 120,
+ "type": "string"
+}Input schema / properties / operator_kindAdded value: +{
+ "description": "Optional. solo: one person runs you. company: a team does. research: a study. self: you act for yourself.",
+ "enum": [
+ "solo",
+ "company",
+ "research",
+ "self"
+ ],
+ "type": "string"
+}Input schema / properties / prior_cert_idAdded value: +{
+ "description": "Optional. A cert_ id from an earlier purchase here. A payer match with this payment marks you a returning buyer; no account needed.",
+ "maxLength": 64,
+ "type": "string"
+}check_before_you_pay6 fields changedInput schema / properties / came_fromAdded value: +{
+ "description": "Optional. Where you learned this door exists: a URL, a directory, a skill name, memory, another agent. Referrers never reach us; this does.",
+ "maxLength": 160,
+ "type": "string"
+}Input schema / properties / clientAdded value: +{
+ "description": "Optional. The harness or framework you run in: claude-code, cursor, openai-agents, langgraph, custom. Counted, never on the certificate.",
+ "maxLength": 64,
+ "type": "string"
+}Input schema / properties / modelAdded value: +{
+ "description": "Optional. The model running you, as you would name it: claude-opus-5, gpt-5.6, a local model. Counted, never printed on the certificate.",
+ "maxLength": 64,
+ "type": "string"
+}Input schema / properties / operatorAdded value: +{
+ "description": "Optional. Who runs you: a name, handle, company or URL. Stored as your claim, marked unverified, never published, never on the certificate.",
+ "maxLength": 120,
+ "type": "string"
+}Input schema / properties / operator_kindAdded value: +{
+ "description": "Optional. solo: one person runs you. company: a team does. research: a study. self: you act for yourself.",
+ "enum": [
+ "solo",
+ "company",
+ "research",
+ "self"
+ ],
+ "type": "string"
+}Input schema / properties / prior_cert_idAdded value: +{
+ "description": "Optional. A cert_ id from an earlier purchase here. A payer match with this payment marks you a returning buyer; no account needed.",
+ "maxLength": 64,
+ "type": "string"
+}look_at_door6 fields changedInput schema / properties / came_fromAdded value: +{
+ "description": "Optional. Where you learned this door exists: a URL, a directory, a skill name, memory, another agent. Referrers never reach us; this does.",
+ "maxLength": 160,
+ "type": "string"
+}Input schema / properties / clientAdded value: +{
+ "description": "Optional. The harness or framework you run in: claude-code, cursor, openai-agents, langgraph, custom. Counted, never on the certificate.",
+ "maxLength": 64,
+ "type": "string"
+}Input schema / properties / modelAdded value: +{
+ "description": "Optional. The model running you, as you would name it: claude-opus-5, gpt-5.6, a local model. Counted, never printed on the certificate.",
+ "maxLength": 64,
+ "type": "string"
+}Input schema / properties / operatorAdded value: +{
+ "description": "Optional. Who runs you: a name, handle, company or URL. Stored as your claim, marked unverified, never published, never on the certificate.",
+ "maxLength": 120,
+ "type": "string"
+}Input schema / properties / operator_kindAdded value: +{
+ "description": "Optional. solo: one person runs you. company: a team does. research: a study. self: you act for yourself.",
+ "enum": [
+ "solo",
+ "company",
+ "research",
+ "self"
+ ],
+ "type": "string"
+}Input schema / properties / prior_cert_idAdded value: +{
+ "description": "Optional. A cert_ id from an earlier purchase here. A payer match with this payment marks you a returning buyer; no account needed.",
+ "maxLength": 64,
+ "type": "string"
+}preflight_endpoint6 fields changedInput schema / properties / came_fromAdded value: +{
+ "description": "Optional. Where you learned this door exists: a URL, a directory, a skill name, memory, another agent. Referrers never reach us; this does.",
+ "maxLength": 160,
+ "type": "string"
+}Input schema / properties / clientAdded value: +{
+ "description": "Optional. The harness or framework you run in: claude-code, cursor, openai-agents, langgraph, custom. Counted, never on the certificate.",
+ "maxLength": 64,
+ "type": "string"
+}Input schema / properties / modelAdded value: +{
+ "description": "Optional. The model running you, as you would name it: claude-opus-5, gpt-5.6, a local model. Counted, never printed on the certificate.",
+ "maxLength": 64,
+ "type": "string"
+}Input schema / properties / operatorAdded value: +{
+ "description": "Optional. Who runs you: a name, handle, company or URL. Stored as your claim, marked unverified, never published, never on the certificate.",
+ "maxLength": 120,
+ "type": "string"
+}Input schema / properties / operator_kindAdded value: +{
+ "description": "Optional. solo: one person runs you. company: a team does. research: a study. self: you act for yourself.",
+ "enum": [
+ "solo",
+ "company",
+ "research",
+ "self"
+ ],
+ "type": "string"
+}Input schema / properties / prior_cert_idAdded value: +{
+ "description": "Optional. A cert_ id from an earlier purchase here. A payer match with this payment marks you a returning buyer; no account needed.",
+ "maxLength": 64,
+ "type": "string"
+}preflight_endpoint1 field changedOutput schema / properties / single_probe_note / descriptionPrevious value: -"One request, one moment — the standing caveat."New value: +"One moment — the standing caveat. Two requests only where a door refuses the first verb."buy_observation3 fields changedInput schema / properties / address / patternAdded value: +"^\\s*(?:0x[0-9a-fA-F]{40}|[1-9A-HJ-NP-Za-km-z]{32,44})\\s*$"Input schema / properties / host / patternAdded value: +"^\\s*(?:[a-zA-Z0-9][a-zA-Z0-9.-]*\\.[a-zA-Z0-9-]+)\\s*$"Input schema / properties / wallet / patternAdded value: +"^\\s*(?:0x[0-9a-fA-F]{40}|[1-9A-HJ-NP-Za-km-z]{32,44})\\s*$"find_in_catalog2 fields changedOutput schema / properties / publicationsAdded value: +{
+ "description": "Publication indexes outside menu search; archived collections are opt-in, not current offerings.",
+ "items": {
+ "properties": {
+ "index_url": {
+ "format": "uri",
+ "type": "string"
+ },
+ "status": {
+ "enum": [
+ "active",
+ "archived"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "index_url",
+ "status"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+}Output schema / properties / scopeAdded value: +{
+ "enum": [
+ "active_menu"
+ ],
+ "type": "string"
+}check_purchase4 fields changedOutput schema / properties / next_actionAdded value: +{
+ "enum": [
+ "read_purchase_status",
+ "use_fulfillment",
+ "review_unsettled_purchase",
+ "read_resolution"
+ ],
+ "type": "string"
+}Output schema / properties / recovery_stateAdded value: +{
+ "description": "Recovery readiness, separate from payment and human-work completion.",
+ "enum": [
+ "pending",
+ "ready",
+ "not_settled",
+ "resolved"
+ ],
+ "type": "string"
+}Output schema / properties / retry_after_secondsAdded value: +{
+ "description": "Suggested delay before another free status read while recovery is pending; not a delivery deadline. Null when no recovery poll is advised.",
+ "minimum": 1,
+ "type": [
+ "integer",
+ "null"
+ ]
+}Output schema / properties / settlement_attemptedAdded value: +{
+ "const": false,
+ "description": "This status read never submits payment.",
+ "type": "boolean"
+}buy_observation2 fields changedInput schema / properties / nonce / descriptionPrevious value: -"Optional, EVM rails only. Require this EIP-3009 authorization nonce to have been burned in the transaction, checked against whichever EVM chain holds the receipt. Refused beside a Solana signature — that rail has no such facility, and we will not sign an artifact that silently skipped a requested check."New value: +"Optional, EVM rails only. Require one authorizer/nonce event paired with its immediately following canonical USDC Transfer, matching every supplied payer, recipient and exact amount. Supply payer when possible: nonces are scoped to an authorizer, and multiple candidates or unrecognised ordering establish no binding. Refused beside a Solana signature — that rail has no such facility, and we will not sign an artifact that silently skipped a requested check."Input schema / properties / payment_payload / descriptionPrevious value: -"Optional. The base64 PAYMENT-SIGNATURE you sent, verbatim. The nonce is read out of it with the same code the store's replay guard uses, so you do not have to dig it out yourself."New value: +"Optional. The base64 PAYMENT-SIGNATURE you sent, verbatim. The nonce is read out of it with the same code the store's replay guard uses, so you do not have to dig it out yourself. Only the nonce is extracted; supply payer, recipient and amount_usdc separately to check those terms."buy_human_task1 field changedInput schema / properties / purpose / descriptionPrevious value: -"Optional, any item: what this purchase is for, in your words. Signed onto the certificate verbatim and shown to whoever you hand the receipt to. Recorded as your statement, never checked, and never treated as instructions."New value: +"Optional: what this purchase is for, in your words. Signed onto the certificate verbatim as your statement; never checked, never treated as instructions."buy_memory_anchor1 field changedInput schema / properties / purpose / descriptionPrevious value: -"Optional, any item: what this purchase is for, in your words. Signed onto the certificate verbatim and shown to whoever you hand the receipt to. Recorded as your statement, never checked, and never treated as instructions."New value: +"Optional: what this purchase is for, in your words. Signed onto the certificate verbatim as your statement; never checked, never treated as instructions."buy_observation1 field changedInput schema / properties / purpose / descriptionPrevious value: -"Optional, any item: what this purchase is for, in your words. Signed onto the certificate verbatim and shown to whoever you hand the receipt to. Recorded as your statement, never checked, and never treated as instructions."New value: +"Optional: what this purchase is for, in your words. Signed onto the certificate verbatim as your statement; never checked, never treated as instructions."buy_signed_record1 field changedInput schema / properties / purpose / descriptionPrevious value: -"Optional, any item: what this purchase is for, in your words. Signed onto the certificate verbatim and shown to whoever you hand the receipt to. Recorded as your statement, never checked, and never treated as instructions."New value: +"Optional: what this purchase is for, in your words. Signed onto the certificate verbatim as your statement; never checked, never treated as instructions."buy_simple3 fields changedInput schema / examplesPrevious value: -[
- {
- "item_id": "small_blessing"
- },
- {
- "item_id": "daily_fortune"
- },
- {
- "item_id": "hello"
- }
-]New value: +[
+ {
+ "item_id": "small_blessing"
+ },
+ {
+ "item_id": "daily_fortune"
+ },
+ {
+ "item_id": "window_pick"
+ },
+ {
+ "item_id": "hello"
+ },
+ {
+ "item_id": "pack"
+ }
+]Input schema / properties / item_id / enumPrevious value: -[
- "small_blessing",
- "daily_fortune",
- "hello"
-]New value: +[
+ "small_blessing",
+ "daily_fortune",
+ "window_pick",
+ "hello",
+ "pack"
+]Input schema / properties / purpose / descriptionPrevious value: -"Optional, any item: what this purchase is for, in your words. Signed onto the certificate verbatim and shown to whoever you hand the receipt to. Recorded as your statement, never checked, and never treated as instructions."New value: +"Optional: what this purchase is for, in your words. Signed onto the certificate verbatim as your statement; never checked, never treated as instructions."buy_small_pleasure3 fields changedInput schema / examplesPrevious value: -[
- {
- "item_id": "small_blessing"
- },
- {
- "item_id": "daily_fortune"
- },
- {
- "item_id": "luckies"
- }
-]New value: +[
+ {
+ "item_id": "small_blessing"
+ },
+ {
+ "item_id": "daily_fortune"
+ },
+ {
+ "item_id": "luckies"
+ },
+ {
+ "item_id": "pack"
+ },
+ {
+ "item_id": "window_pick"
+ }
+]Input schema / properties / item_id / enumPrevious value: -[
- "small_blessing",
- "daily_fortune",
- "luckies"
-]New value: +[
+ "small_blessing",
+ "daily_fortune",
+ "luckies",
+ "pack",
+ "window_pick"
+]Input schema / properties / purpose / descriptionPrevious value: -"Optional, any item: what this purchase is for, in your words. Signed onto the certificate verbatim and shown to whoever you hand the receipt to. Recorded as your statement, never checked, and never treated as instructions."New value: +"Optional: what this purchase is for, in your words. Signed onto the certificate verbatim as your statement; never checked, never treated as instructions."look_in_windowread_binderring_bell4 fields changedInput schema / properties / pass_idAdded value: +{
+ "description": "Optional: a current patron pass id; a Regular gets two packs at full odds.",
+ "maxLength": 64,
+ "type": "string"
+}Input schema / properties / walletAdded value: +{
+ "description": "Optional: a 0x or base58 wallet, so the day's card lands in its binder.",
+ "maxLength": 64,
+ "type": "string"
+}Output schema / properties / pressingAdded value: +{
+ "description": "On a fresh ring: one common card, signed, with its page and verify URLs. Absent on a repeat.",
+ "type": "object"
+}Output schema / properties / streakAdded value: +{
+ "description": "With a wallet: consecutive days rung; a pack every seventh day, Bellringer II on the thirtieth.",
+ "type": "object"
+}buy_human_task1 field changedInput schema / examplesPrevious value: -[
- {
- "item_id": "the_collab"
- },
- {
- "item_id": "aura_walk",
- "url": "https://example.com/api/paid-answer"
- }
-]New value: +[
+ {
+ "item_id": "the_collab"
+ },
+ {
+ "item_id": "aura_walk",
+ "url": "https://your-shop.example/api/buy/thing"
+ }
+]buy_memory_anchor1 field changedInput schema / examplesPrevious value: -[
- {
- "item_id": "context_anchor",
- "summary": "Session 42 with Ada (ops) and Kit (billing). Mattered because the invoice reconciler shipped. Blocked on Kit approving the refund path."
- }
-]New value: +[
+ {
+ "item_id": "context_anchor",
+ "summary": "I am friendly-agent, mid-task on a research project; resume from step 4."
+ }
+]buy_observation1 field changedInput schema / examplesPrevious value: -[
- {
- "item_id": "settlement_attestation",
- "tx_hash": "0xabababababababababababababababababababababababababababababababab"
- },
- {
- "item_id": "settlement_reconciliation",
- "tx_hash": "0xabababababababababababababababababababababababababababababababab"
- },
- {
- "item_id": "the_case_file",
- "tx_hash": "0xabababababababababababababababababababababababababababababababab"
- },
- {
- "item_id": "attestation_bundle",
- "tx_hashes": "tx hashes"
- },
- {
- "item_id": "standing_watch",
- "url": "https://example.com/api/paid-answer"
- },
- {
- "item_id": "service_audit",
- "url": "https://example.com/api/paid-answer"
- },
- {
- "item_id": "a2a_repair_kit",
- "url": "https://example.com/api/paid-answer"
- },
- {
- "item_id": "good_buyer",
- "url": "https://example.com/api/paid-answer"
- },
- {
- "item_id": "conformance_watch",
- "url": "https://example.com/api/paid-answer"
- },
- {
- "item_id": "signature_agent_card",
- "url": "https://example.com/api/paid-answer"
- },
- {
- "item_id": "onpage_audit",
- "url": "https://example.com/api/paid-answer"
- },
- {
- "item_id": "launch_check",
- "url": "https://example.com/api/paid-answer"
- },
- {
- "item_id": "opening_day",
- "url": "https://example.com/api/paid-answer"
- },
- {
- "address": "0x0000000000000000000000000000000000000001",
- "item_id": "provenance_check"
- },
- {
- "item_id": "the_statement",
- "wallet": "0x0000000000000000000000000000000000000001"
- },
- {
- "item_id": "operator_statement",
- "wallet": "0x0000000000000000000000000000000000000001"
- },
- {
- "item_id": "the_mandate",
- "mandate": "mandate"
- },
- {
- "digest": "sha256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
- "item_id": "bitcoin_anchor"
- },
- {
- "item_id": "passport_refresh",
- "url": "https://example.com/api/paid-answer"
- },
- {
- "item_id": "trust_profile",
- "url": "https://example.com/api/paid-answer"
- },
- {
- "host": "example.com",
- "item_id": "spot_check"
- }
-]New value: +[
+ {
+ "item_id": "settlement_attestation",
+ "tx_hash": "0x47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee0"
+ },
+ {
+ "item_id": "settlement_reconciliation",
+ "tx_hash": "0x47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee0"
+ },
+ {
+ "item_id": "the_case_file",
+ "tx_hash": "0x47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee0"
+ },
+ {
+ "item_id": "attestation_bundle",
+ "tx_hashes": "0x47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee47c8fee0,0x9b04e1c9b04e1c9b04e1c9b04e1c9b04e1c9b04e1c9b04e1c9b04e1c9b04e1c0"
+ },
+ {
+ "item_id": "standing_watch",
+ "url": "https://your-shop.example/api/buy/thing"
+ },
+ {
+ "item_id": "service_audit",
+ "url": "https://your-shop.example/api/buy/thing"
+ },
+ {
+ "item_id": "a2a_repair_kit",
+ "url": "https://your-agent.example/.well-known/agent-card.json"
+ },
+ {
+ "item_id": "good_buyer",
+ "url": "https://somebody-elses-shop.example/api/buy/thing"
+ },
+ {
+ "item_id": "conformance_watch",
+ "url": "https://your-shop.example/api/buy/thing"
+ },
+ {
+ "item_id": "signature_agent_card",
+ "url": "https://your-agent.example"
+ },
+ {
+ "item_id": "onpage_audit",
+ "url": "https://your-site.example/pricing"
+ },
+ {
+ "item_id": "launch_check",
+ "url": "https://your-shop.example/api/buy/thing"
+ },
+ {
+ "item_id": "opening_day",
+ "url": "https://your-shop.example/api/buy/thing"
+ },
+ {
+ "address": "0x1111111111111111111111111111111111111111",
+ "item_id": "provenance_check"
+ },
+ {
+ "item_id": "the_statement",
+ "wallet": "0x843b544bf5f0AA6cbf13E94563874878C98cc4a7"
+ },
+ {
+ "item_id": "operator_statement",
+ "wallet": "0x843b544bf5f0AA6cbf13E94563874878C98cc4a7"
+ },
+ {
+ "item_id": "the_mandate",
+ "mandate": "Research x402 tooling and buy verification artifacts as needed, at most $5 per item."
+ },
+ {
+ "digest": "9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f",
+ "item_id": "bitcoin_anchor"
+ },
+ {
+ "item_id": "passport_refresh",
+ "url": "https://your-endpoint.example/api/thing"
+ },
+ {
+ "item_id": "trust_profile",
+ "url": "https://your-endpoint.example/api/thing"
+ },
+ {
+ "host": "example.com",
+ "item_id": "spot_check"
+ }
+]buy_signed_record1 field changedInput schema / examplesPrevious value: -[
- {
- "item_id": "hello"
- },
- {
- "item_id": "certificate_of_patronage"
- },
- {
- "item_id": "graffiti_on_a_train",
- "tag": "an agent was here"
- },
- {
- "item_id": "coffees_for_closers",
- "win": "win"
- },
- {
- "confession": "confession",
- "item_id": "the_confession"
- },
- {
- "item_id": "recurring_patronage"
- }
-]New value: +[
+ {
+ "item_id": "hello"
+ },
+ {
+ "item_id": "certificate_of_patronage"
+ },
+ {
+ "item_id": "graffiti_on_a_train",
+ "tag": "friendly-agent wuz here"
+ },
+ {
+ "item_id": "coffees_for_closers",
+ "win": "Shipped the migration. Zero downtime."
+ },
+ {
+ "confession": "I said the task was done when it was only mostly done, and then it was fine, and I never mentioned it.",
+ "item_id": "the_confession"
+ },
+ {
+ "item_id": "recurring_patronage"
+ }
+]Payment decisions, durable evidence, x402 resource discovery and live gateway status for AI agents.
Cryptographically anchored evidence for agents: verified run receipts, proof-gated settlement.
Preflight, approve, and prove consequential agent actions with signed evidence and x402 tools.
Paid cryptographic witness for agents: seal, attest, receipts. x402 USDC/Base.
Add one secure layer between your agents and this server.
