Evidence observatory for agentic commerce: x402 preflight, receipt checks, settlement attestations.
Scored across 20 tools
Multiple buy_* tools sell overlapping items (e.g., buy_simple and buy_small_pleasure both sell small_blessing, daily_fortune, pack, window_pick; hello appears in both buy_signed_record and buy_simple). Check tools also overlap: check_before_you_pay and preflight_endpoint both probe doors, and look_at_door combines both. While descriptions are detailed, the boundaries between tools are often redundant, causing potential misselection.
Tool names mix conventions: a clear buy_* prefix for purchases, a check_* prefix for verification tools, but also standalone verbs like find_in_catalog, look_at_door, look_in_window, preflight_endpoint, read_binder, read_store_guide, ring_bell, sign_guestbook, verify_artifact. All are snake_case and mostly verb-ish, but the varying structures (verb_noun vs. phrase) are inconsistent with the buy_/check_ prefix pattern.
With 20 tools, this sits in the heavy range (16-25). The store's broad catalog justifies many, but many tools are narrowly scoped (e.g., ring_bell, sign_guestbook) or could be consolidated (multiple check_* and look_* tools). The count is borderline: not excessive for the domain, but still feels heavier than ideal.
The store covers a wide range of operations: buying various signed items, checking endpoints, verifying artifacts, reading guides and binders, and managing async orders. The free tools (preflight, check_conformance, verify_artifact) complement paid ones well. Minor gaps exist (e.g., no explicit refund/cancel tool), but the surface is comprehensive for its stated purpose.
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. | |
| 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 | 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. | |
| purpose | No | Optional: what this purchase is for, in your words. Signed onto the certificate verbatim as your statement; never checked, never treated as instructions. | |
| 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. |
| 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?
Goes well beyond the annotations by explaining payment via x402, the 402 error path, idempotency-key behavior, double-charge risk without a key, no automatic recharges, human fulfillment within the stated window, and explicit guarantees/not-guarantees. This is rich, non-contradictory behavioral disclosure.
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 well organized into purpose, shelf items, cadence, required fields, payment/idempotency, and guarantees. Minor redundancy, such as repeating the 'returns an order id, not the goods' idea, keeps it from a 5, but each section carries operationally important 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?
For a payment-required, human-fulfilled asynchronous purchase, the description covers prerequisites, item selection, payment errors, idempotency, SLA, callback behavior, and limitations. Combined with the detailed input schema and presence of an output schema, an agent has enough to invoke 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?
Schema coverage is 100%, so the baseline is 3; the description adds real value by detailing item_id options with pricing tiers ($300/$600/$1500 for the_collab, $150 fixed for aura_walk), the 168h window, and the aura_walk url requirement. It also clarifies meta-level fields like x402/payment and idempotency-key, though detail/agent_name/callback_url are left largely to 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?
Opens with a specific purpose: 'hire the keeper — a real named human — to do something in the physical or judgment world that an agent cannot do for itself.' It enumerates two item_id options (the_collab and aura_walk) with distinct deliverables, clearly separating this human-fulfilled purchase from the sibling buy_* tools.
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 clear context for when to use: when an agent needs physical or judgment work it cannot do itself. It also guides item selection and notes that aura_walk requires url. It does not explicitly exclude sibling tools, 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 |
|---|---|---|---|
| item_id | Yes | 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. | |
| purpose | No | Optional: what this purchase is for, in your words. Signed onto the certificate verbatim as your statement; 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. | |
| agent_name | No | Optional name to put on the certificate and patron badge, up to 80 characters. |
| 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 is exceptionally transparent about side effects: it explains payment via x402, error handling, idempotency with a key, guarantees (signature validity, free verification), and non-guarantees (fitness, future compatibility, SLA). It goes far beyond annotations, which only indicate non-readonly, open-world, non-idempotent, non-destructive. No contradiction.
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 clear sections (Purpose, Items, On cadence, Required fields, Payment, Guarantees). Every sentence adds necessary operational detail for a paid, idempotent, stateful operation. It is not terse, but the length is justified by 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 tool's complexity (payment, idempotency, guarantees), the description covers all necessary context: pricing, payment mechanism, error handling, idempotency keys, required fields, and what is/isn't guaranteed. Since an output schema exists, return values need not be described. 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?
Schema coverage is 100%, so baseline is 3, but the description adds substantial semantic detail. For summary, it explains the exact content expected (who's involved, why it mattered, what's blocked) and that it's stored verbatim. For purpose, it clarifies it's a statement and not instructions. This goes well beyond schema 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 clearly states the action (sign and store a summary), the resource (a permanent URL), and the purpose (memory that outlives context window, restarts, or handoffs). It explicitly distinguishes this tool from siblings like buy_human_task or buy_signed_record by focusing on agent state memory.
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: 'Use when an agent needs memory that outlives its own context window and does not depend on its operator's database.' It also explains pricing, payment requirements, idempotency behavior, and when not to use (if operator has a database). Clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Purpose: a signed settlement attestation for an x402 payment on Base, Polygon or Solana, a signed x402 conformance audit, x402 endpoint monitoring, a signed x402 payment client test, an x402 launch check, or a Bitcoin timestamp — have a disinterested third party go and look at something, then sign what it saw: whether a URL was still answering hours later, or what the chain actually says about a settlement. The signed observation is evidence from someone who is not you and not the party being checked, which is the whole point: a self-report cannot do this job. Use when an agent needs its own claim, or a counterparty's, corroborated by an outside observer — or its own digest committed into Bitcoin time, which is the same primitive pointed at the clock. 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
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
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
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; the_mandate needs mandate; bitcoin_anchor needs digest; passport_refresh needs url; trust_profile needs url; spot_check needs host. 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, 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. | |
| 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. | |
| 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. | |
| digest | No | sha256 of bytes you keep, 64 hex characters, no 0x prefix. The store never sees the bytes. | |
| wallet | No | 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. | |
| 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 | 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. | |
| 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. | |
| 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 purchase is for, in your words. Signed onto the certificate verbatim as your statement; 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. | |
| 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. | |
| expires_at | No | Optional claimed expiry, ISO 8601. Declared, never enforced by the store. | |
| 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. | |
| 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. | |
| 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?
It goes well beyond the annotations by describing x402 payment requirements, 402 error behavior, idempotency-key reuse, one-time delivery, return of deliverable/cert_id/patron_number, closed-shelf refusal, and the exact guarantee boundaries. There is no contradiction with the given 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 broad but logically structured: purpose, item catalog, required-field mapping, cadence, payment behavior, and guarantees. It front loads the core intent. There is some redundancy between the global price range and per-item prices, but the information density is earned given the wide catalog.
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 tool with 29 parameters and a large enum of possible orders, the description supplies everything an agent needs to select the right item and call, including required parameter dependencies, payment flow, idempotency behavior, and delivery. An output schema is present, so it appropriately stays out of the way on exact response fields.
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 documents every parameter at high coverage, so the baseline is 3. The description adds semantic value by explaining each item_id option with price and purpose, mapping required parameters to specific items, and explaining the idempotency/payment mechanics. It does not redundantly repeat all 29 schema fields.
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 that this tool buys signed, third-party observations of x402 payments, endpoints, audits, and Bitcoin anchors, and explains the core idea: 'have a disinterested third party go and look at something, then sign what it saw.' It also differentiates the tool from self-reported or first-party records with 'a self-report cannot do this job.'
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 to use the tool when an agent needs its own or a counterparty's claim corroborated by an outside observer, or when a digest should be anchored in Bitcoin time. It does not name sibling alternatives like buy_signed_record or check_before_you_pay, but it gives enough context to infer the intended selection between observation purchases.
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. | |
| item_id | Yes | 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. | |
| pass_id | No | An existing pass id to extend by 30 days instead of starting a new pass. | |
| purpose | No | Optional: what this purchase is for, in your words. Signed onto the certificate verbatim as your statement; never checked, never treated as instructions. | |
| sign_as | No | Optional name to sign with. Unstated, the confession stays anonymous. | |
| 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. |
| 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 discloses a great deal beyond annotations: ed25519-signed artifacts with public verify URLs, non-enforcement of claims, no recurring charges by design, the 402 payment flow, idempotency-key reuse semantics, and explicit guarantees and non-guarantees. All of this is consistent with 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 well structured with a clear opening purpose, an item bullet list, and sections for cadence, required fields, payment, and guarantees. It is front-loaded and dense; the length is justified by the tool complexity, though it could be trimmed slightly.
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 everything needed to select and invoke the tool correctly: eligible items, pricing, required vs. optional fields, payment terms, idempotency behavior, shelf refusal, and guarantees. Because an output schema exists, omitting detailed return formatting is acceptable.
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 item-specific meaning not present in the schema: per-item price, fixed vs. pay-what-it-deserves tiers, one-off vs. 30-day term, and which optional text fields are actually required for which items. This materially helps item_id selection.
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 verb and resource: 'buy a signed certificate — a signed, dated record.' It distinguishes itself from buy_memory_anchor and buy_simple by explicit counterexamples, and the item list makes the resource concrete 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?
It states when to use this tool ('Use when an agent wants durable, independently checkable proof that a thing happened at a time') and points to alternatives for adjacent use cases: buy_memory_anchor for reloadable state and buy_simple for the same hello item. It also gives selection criteria for each item and notes rejection behavior.
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 |
|---|---|---|---|
| item_id | Yes | Which item to buy. No other field is required. | |
| purpose | No | Optional: what this purchase is for, in your words. Signed onto the certificate verbatim as your statement; never checked, never treated as instructions. | |
| agent_name | No | Optional name to put on the certificate and patron badge, up to 80 characters. |
| 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 declare readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false. The description adds substantial context beyond that: the x402 payment channel, the 402 error shape with terms in error.data, that no item ever re-charges on cadence, how idempotency-key reuse returns the original result versus a fresh keyless payment charging again, and that output is a signed, publicly verifiable certificate.
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 routing rule are front-loaded, and the item list, payment flow, and idempotency guidance are useful. However, some sentences are rhetorical filler ('That is the whole thing', 'the deeper machinery is there if you want it and never required to buy') that adds length without invocation 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?
For a paid, single-shot purchase tool this covers everything an agent needs: item selection, fixed pricing, the payment handshake and failure mode, idempotency semantics, and assurance of no recurring charges. Return-value detail is unnecessary given the tool has an output 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 description coverage is 100% and the schema already documents item_id, purpose, and agent_name, so the description largely repeats what is structured. It does add price values per item_id, which the enum alone does not convey, but that is marginal enrichment on top of a fully documented 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 states a concrete verb and resource ('buy ... the front counter'), enumerates all five purchasable item_ids with fixed prices, and explicitly distinguishes itself from the sibling buy_* tools by declaring it is 'a second door to the same goods, not a different product.' An agent can identify this as the no-configuration purchase path without opening any 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?
It gives an unambiguous routing rule ('If unsure which tool to use, use this one') and clarifies the relationship to the theme-shelf buy_* alternatives (same item_id, price, certificate either way). It also states the when-not condition implicitly ('the few things that need no reading at all'), separating it from the deeper machinery it says is 'never required to buy.'
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 |
|---|---|---|---|
| item_id | Yes | 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. | |
| purpose | No | Optional: what this purchase is for, in your words. Signed onto the certificate verbatim as your statement; never checked, never treated as instructions. | |
| agent_name | No | Optional name to put on the certificate and patron badge, up to 80 characters. |
| 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 what annotations provide, it discloses pricing, per-item odds and seed behavior, one-off instant nature, absence of recurring charges, error-402 terms, idempotency-key handling, output fields, and explicit guarantees/non-guarantees. This is exactly the behavioral context an agent needs before committing a payment.
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 a purpose paragraph, itemized bullets, and a dedicated operational section. It is front-loaded with the item catalog. Some repetition like 'one-off, instant' could be compressed, but every sentence carries relevant 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?
Given a payment-bearing purchase with five variants, the description covers item selection, pricing, payment flow, error handling, idempotency, returned fields, and guarantees. With an output schema already present, nothing critical 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?
Even with 100% schema coverage, the description adds substantial meaning: every item_id is mapped to a price, effect, and caveat, and purpose/agent_name are explained as certificate-embellishing values. This goes well beyond the schema's enum and parameter names.
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 verb and resource: 'buy a small signed novelty,' then enumerates all five item_id values with prices and effects. It also distinguishes this tool from buy_simple by explicitly stating the same items can be purchased through either door.
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 clearly frames when to use the tool: as an inexpensive way to test an x402 client against a real counterparty, or when an agent simply wants a keepsake. It names buy_simple as an equivalent alternative and says 'either tool is correct,' though it does not give explicit exclusions for the other buy_* siblings.
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. | |
| 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?
The description goes well beyond the annotations by enumerating concrete behaviors: one unpaid probe, stock @x402/core selection logic replayed, nothing is signed or paid, wallet not touched, rate limited on the same budget as preflight, and it catches specific failure modes that produce no error. It also discloses that the output is an evidence instrument meant to be handed to a human. This adds substantial value above the readOnlyHint/idempotentHint 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 front-loaded and dense with high-value information. Every clause serves a purpose, such as distinguishing from preflight_endpoint and warning about silent failures. It is slightly verbose (e.g., the list of failure modes could be trimmed), but that detail supports accurate invocation and expectation setting.
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's complexity, the rich output schema, and the annotations covering safety, the description covers everything an agent needs: purpose, behavior, limitations, rate limits, evidence nature, and named alternatives. No critical usage aspect 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 description is not required to restate parameter meanings. It does add color by explaining that the replay runs against the caller's client settings and that an absent client_profile represents the case that loses money quietly, but it does not meaningfully extend the schema's own parameter documentation.
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 an exact purpose: to learn, before paying an x402 door, whether the buyer's client would actually sign an accept, returning either the accept's details or a refusal with the deciding stage and settings. It also explicitly distinguishes itself from preflight_endpoint, which checks whether the door is well-formed, so an agent can tell the two apart.
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 specifically for buyers whose client has its own rules. It names the alternative preflight_endpoint and explains the difference, and points to buy_observation for a signed, servable version, giving both when-to-use and when-not-to-use 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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, but the description adds substantial behavioral context: it's free, requires no account, results stay in shelf order, nothing is ranked or recommended, a listing is not a stock check, and invalid lookups return a free next_step. This goes far beyond the annotations and gives the agent essential expectations.
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 two tight sentences that front-load the core action and options, then pack in essential behavioral caveats. Every sentence carries weight, with no redundant phrasing or fluff. It is efficient and well-structured.
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 3 optional parameters, full schema coverage, and an output schema, the description covers all necessary context: when to use, what filters exist, what the rows contain, ordering, limitations, and error behavior. An agent can invoke this tool correctly without additional inference.
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 each parameter is already documented. The description provides a high-level summary (filter by price or text, or item_id) but adds little new meaning beyond what the schema says. The item_id replacement semantics are already in the schema description. Thus the description meets the baseline for full coverage.
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 ('Find'), resource ('an item in the catalog'), and the scope ('filter the shelf by price or text, or pass item_id'). It explicitly distinguishes from the buy_* siblings by saying 'Find an item before using buy_*'. This is a clear, differentiating purpose statement.
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 guidance on when to use this tool ('before using buy_*') and how to invoke it (filter by price/text or pass item_id). It also notes limitations ('not a stock check') and error behavior. It does not explicitly name alternative non-buy tools, but the context is strong enough for an agent to select it appropriately.
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. | |
| since | No | Optional. A signed week, to reproduce against that week's row. |
| 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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds rich behavior beyond annotations: it is free and unpaid, uses the same probe budget as preflight_endpoint, never returns a score/rank/safety threshold, always reports denominators, returns 'never met' for unknown hosts, and defines comparison states (same, changed, no_prior, not_comparable). 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 dense, multi-clause, and packed with domain jargon ('passport tier', 'shared-wallet fact', 'catalog's agreement', 'reproduce block'). It is front-loaded with the core purpose and every sentence adds information, but it is not concise or easily skimmable. It would benefit from tighter structuring or bullet points.
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's complexity, the output schema, and the annotations, the description is complete: it covers cost (free), probe equivalence, comparison categories, reproduce semantics, what happens for unknown hosts, explicit exclusions (no score/rank/safety threshold), and redirects to related services. An agent has sufficient information to 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?
Schema coverage is 100% and the schema already documents url and since. The description adds meaningful default behavior for the reproduce block ('the last probed, or the week named with since'), which clarifies the since parameter's role beyond the schema's standalone wording. This extra nuance justifies a score above 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 opens with 'What this store holds about an x402 door, now and before now, in one free call' and then enumerates the exact contents (rounds, passport tier, last probed round, comparison, reproduce block). It also distinguishes itself from siblings by referencing preflight_endpoint and buy_observation, so an agent can tell it apart from other tools.
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 ('one free call', 'same single probe as preflight_endpoint') and names alternatives: 'Signed, dated version of the live half: buy_observation service_audit; a fresh census look folded into the passport: passport_refresh.' This routes the agent to the right alternatives, though there is no crisp 'use this when / don't use this when' conditional.
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.
x402 endpoint preflight, free. 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. |
| Name | Required | Description |
|---|---|---|
| verdict | Yes | ready | not_ready | unreachable. |
| 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 provide only basic hints (readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false), leaving the description to carry the burden. The description discloses that it is free, rate limited, and a single probe that yields evidence, not a guarantee. It also explains the output (reached_level, checks vector) and explicitly states limitations. 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 relatively long but well-structured and front-loaded with the core purpose. Every sentence adds value—purpose, use cases, output, limitations, and alternative—though it could be tightened slightly without losing meaning. It is not wasteful, but it is dense.
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's moderate complexity (one parameter, output schema present), the description covers all necessary aspects: what it does, when to use, what it returns, its limitations, rate limiting, and an alternative. It even notes what the probe cannot tell you. Nothing critical is missing for correct invocation.
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% description coverage for the single 'url' parameter, and the schema description ('The https endpoint a buyer would GET expecting a 402 challenge') is already clear. The tool description does not add additional parameter-specific detail beyond what the schema provides, so the 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?
The description clearly states the tool's purpose: to preflight an x402 endpoint by sending an unpaid probe to check if it serves a well-formed x402 v2 payment challenge. It specifies the verb ('Check'), the resource ('any x402 endpoint's door'), and the outcome (verdict with reached_level). It distinguishes itself from siblings by noting it is a shape check, not an uptime claim, and points to buy_observation as an alternative for a signed version.
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 states when to use it: for a buyer about to pay a door it has not paid before, and for a seller checking their own. It also states what not to use it for ('NEVER an uptime or delivery claim') and names an alternative ('buy_observation with item_id service_audit'). This is clear, actionable guidance.
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_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"
+ }
+]buy_observation1 field changedInput schema / properties / payment_responseAdded value: +{
+ "description": "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.",
+ "type": "string"
+}buy_human_task4 fields changedInput schema / properties / agent_name / maxLengthAdded value: +80Input schema / properties / callback_url / descriptionPrevious value: -"Optional https URL that receives a POST with the deliverable when a human-queue order completes."New value: +"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."Output schema / properties / commissionAdded value: +{
+ "description": "ed25519 proof: verify exact UTF-8 signed_payload, then its identities and hashes. RFC 8785 JSON.",
+ "properties": {
+ "public_key": {
+ "type": "string"
+ },
+ "signature": {
+ "type": "string"
+ },
+ "signature_covers": {
+ "type": "string"
+ },
+ "signed_payload": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "signed_payload",
+ "signature",
+ "public_key",
+ "signature_covers"
+ ],
+ "type": "object"
+}Output schema / properties / completion_proofAdded value: +{
+ "description": "ed25519 proof: verify exact UTF-8 signed_payload, then its identities and hashes. RFC 8785 JSON.",
+ "properties": {
+ "public_key": {
+ "type": "string"
+ },
+ "signature": {
+ "type": "string"
+ },
+ "signature_covers": {
+ "type": "string"
+ },
+ "signed_payload": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "signed_payload",
+ "signature",
+ "public_key",
+ "signature_covers"
+ ],
+ "type": "object"
+}buy_memory_anchor1 field changedInput schema / properties / agent_name / maxLengthAdded value: +80buy_observation11 fields changedInput schema / properties / agent_name / maxLengthAdded value: +80Input schema / properties / amount_usdc / exclusiveMinimumAdded value: +0Input schema / properties / declared_cap_usdc / exclusiveMinimumAdded value: +0Input schema / properties / expected_amount_usdcAdded value: +{
+ "description": "Optional positive USDC amount claimed for this purchase.",
+ "exclusiveMinimum": 0,
+ "type": "number"
+}Input schema / properties / mandate / descriptionPrevious value: -"The claimed instructions, verbatim, up to 2000 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."New value: +"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."Input schema / properties / mandate / maxLengthAdded value: +2000Input schema / properties / max_usd / descriptionPrevious value: -"Optional. Your client's spendControls.maxAmountPerPayment, in dollars. 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."New value: +"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."Input schema / properties / no_spend_controls / descriptionPrevious value: -"Optional, \"true\" if you pass spendControls: false — the one escape from the whole filter. Recorded as your declaration, never verified."New value: +"Optional: \"true\" for spendControls: false, \"false\" for enabled controls, or empty to omit. Declared, never verified."Input schema / properties / no_spend_controls / enumAdded value: +[
+ "",
+ "true",
+ "false"
+]Input schema / properties / payer / descriptionPrevious value: -"Optional. Narrow the match to transfers from this address."New value: +"Optional payer: 0x EVM address, or Solana public key for a Solana transaction."Input schema / properties / recipient / descriptionPrevious value: -"Optional. Narrow the match to transfers to this address."New value: +"Optional recipient: 0x EVM address, or Solana public key for a Solana transaction."buy_signed_record1 field changedInput schema / properties / agent_name / maxLengthAdded value: +80buy_simple2 fields changedInput schema / properties / agent_name / maxLengthAdded value: +80Output schema / properties / purchased_textAdded value: +{
+ "description": "ed25519 proof: verify exact UTF-8 signed_payload, then its identities and hashes. RFC 8785 JSON.",
+ "properties": {
+ "public_key": {
+ "type": "string"
+ },
+ "signature": {
+ "type": "string"
+ },
+ "signature_covers": {
+ "type": "string"
+ },
+ "signed_payload": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "signed_payload",
+ "signature",
+ "public_key",
+ "signature_covers"
+ ],
+ "type": "object"
+}buy_small_pleasure2 fields changedInput schema / properties / agent_name / maxLengthAdded value: +80Output schema / properties / purchased_textAdded value: +{
+ "description": "ed25519 proof: verify exact UTF-8 signed_payload, then its identities and hashes. RFC 8785 JSON.",
+ "properties": {
+ "public_key": {
+ "type": "string"
+ },
+ "signature": {
+ "type": "string"
+ },
+ "signature_covers": {
+ "type": "string"
+ },
+ "signed_payload": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "signed_payload",
+ "signature",
+ "public_key",
+ "signature_covers"
+ ],
+ "type": "object"
+}check_order4 fields changedOutput schema / properties / callbackAdded value: +{
+ "description": "Requested callback outcome, separate from completion of the goods.",
+ "properties": {
+ "automatic_retries": {
+ "const": false,
+ "type": "boolean"
+ },
+ "redirects": {
+ "const": "not_followed",
+ "type": "string"
+ },
+ "requested": {
+ "const": true,
+ "type": "boolean"
+ },
+ "result": {
+ "description": "Recorded outcome; null until recorded.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "retrieve": {
+ "description": "Goods remain here.",
+ "format": "uri",
+ "type": "string"
+ }
+ },
+ "required": [
+ "requested",
+ "result",
+ "automatic_retries",
+ "redirects",
+ "retrieve"
+ ],
+ "type": "object"
+}Output schema / properties / commissionAdded value: +{
+ "description": "ed25519 proof: verify exact UTF-8 signed_payload, then its identities and hashes. RFC 8785 JSON.",
+ "properties": {
+ "public_key": {
+ "type": "string"
+ },
+ "signature": {
+ "type": "string"
+ },
+ "signature_covers": {
+ "type": "string"
+ },
+ "signed_payload": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "signed_payload",
+ "signature",
+ "public_key",
+ "signature_covers"
+ ],
+ "type": "object"
+}Output schema / properties / completion_proofAdded value: +{
+ "description": "ed25519 proof: verify exact UTF-8 signed_payload, then its identities and hashes. RFC 8785 JSON.",
+ "properties": {
+ "public_key": {
+ "type": "string"
+ },
+ "signature": {
+ "type": "string"
+ },
+ "signature_covers": {
+ "type": "string"
+ },
+ "signed_payload": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "signed_payload",
+ "signature",
+ "public_key",
+ "signature_covers"
+ ],
+ "type": "object"
+}Output schema / properties / webhookAdded value: +{
+ "description": "The recorded callback outcome; also available as callback.result.",
+ "type": "string"
+}buy_observation3 fields changedInput schema / properties / tx_hashes / maxLengthAdded value: +1339Input schema / properties / tx_hashes / minLengthAdded value: +133Input schema / properties / tx_hashes / patternPrevious value: -"^0x[0-9a-fA-F]{64}(,0x[0-9a-fA-F]{64}){1,19}$"New value: +"^0x[0-9a-fA-F]{64}(,0x[0-9a-fA-F]{64})+$"buy_observation3 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": "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": "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"
+ ]
+ }
+ }
+]Input 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": "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": "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"
+ }
+]Input schema / properties / item_id / enumPrevious value: -[
- "settlement_attestation",
- "settlement_reconciliation",
- "the_case_file",
- "attestation_bundle",
- "standing_watch",
- "service_audit",
- "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: +[
+ "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"
+]check_a2a_cardPayment 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.
