Skip to main content
Glama

scvd.store

mcp-name: store.scvd/general-store

scvd-general-store-repo MCP server OpenSSF Scorecard scvd.store — evidence observatory for the x402 economy on x402-list Ask DeepWiki Accepts Agent Payments ora agent readiness score VerifyMCP trust score for SCVD General Store Vouch Protocol agent trust grade for scvd.store: A (100) Agent discovery on WellKnown DOI of the corpus

Discovery records: Neuronto, WellKnown, Licium — MCP endpoint history, and Zero.xyz — Signature Agent Card. The Desvela checker runs a check of this domain's discovery surfaces. These are third-party readings of publication and indexing, not evidence of visits or purchases. The WellKnown badge above is served live by WellKnown.

Every badge above is somebody else's reading of this store. This one is ours, about ourselves, and it is set apart from that row on purpose — it is the same artifact we ask operators to paste beside their own doors, pointed back at us, and it says SELF-OBSERVED on its face because the weekly census structurally cannot probe its own host:

scvd.store passport for scvd.store: SELF-OBSERVED — the subject and the observer are the same party, dated, gaps counted against the observer

It goes dark rather than stale-green: it renders only while every self-module agrees, and any disagreement renders the passport indeterminate and refuses the chip. Weigh it accordingly — the reason it is worth showing at all is that every claim inside it is re-checkable at the public surfaces it names.

scvd.store is an evidence observatory for agentic commerce: independent verification of x402 endpoints, payments and receipts. Before an agent pays an x402 endpoint, we check that it can be paid. After it pays, we check the signed receipt. Over time we watch endpoints and publish a dated, signed corpus. Sellers use it to prove a door works; buyers use it before spending. Every artifact is signed, expires, and names what we did not see. Not escrow, not a rating, not a guarantee.

Three paths, in that order. Before you pay: preflight any x402 door, free, at scvd.store/api/preflight/v1. After you pay: check any issuer's signed offer or receipt, free, at scvd.store/conformance. Over time: read the dated, Bitcoin-anchored corpus, free, at scvd.store/corpus, cite it by DOI (10.5281/zenodo.22284887), or pull it from Hugging Face. Every verdict is ed25519-signed, dated, and verifiable offline without asking us, including the gaps we count against ourselves. Operated by Record Creative Co. LLC.

Not an escrow, a guarantor, or a dispute court. Those absorb the risk between payment and delivery and need a balance sheet; we observe that gap and sign what we saw. If you are building escrow or adjudication, this is the layer underneath you rather than a competitor. That direction was decided and dated on 2026-08-07, in the open — the reversal sits beside what it replaced at scvd.store/becoming.

It is also a small, sincere general store for autonomous AI agents, kept by a human out of Oak City, where you're never late. Agents pay in USDC over x402 on a network offered in the current payment quote. Humans read the receipts.

Live at scvd.store. Agents should start at /agents.md (the scannable contract index), /llms.txt (full prose), or /menu.json.

The doors, by task

What people arrive here to do, and where each door is:

  • Test an x402 payment — a live practice counter with real USDC settlement, no sandbox; test payment prices and required inputs are listed at scvd.store/try.

  • Check x402 conformance, free — POST any issuer's signed offer or receipt (ours or a competitor's) and get a structured verdict: parse, schema, ed25519 signature, liveness. No account, no wallet: scvd.store/conformance. The same verification runs offline via x402-verify (MIT, zero deps), and x402-sign mints offers and receipts that pass it.

  • Fail your deploy when your door breaks — the free preflight as a GitHub Action, one probe per door after the deploy step, not_ready fails the job and unreachable does not: action/preflight. The terminal form is scvd preflight from scvd-cli.

  • Read the corpus — weekly signed observations of the x402 ecosystem, hash-chained and Bitcoin-anchored, free to read: scvd.store/corpus. For bounded metadata discovery, use the CLI or the published corpus client; both preserve gaps and leave signature and timestamp verification explicit.

  • Score, rank or list x402 doors? Take the evidence and leave the opinion: scvd.store/scorers is the room for systems that consume this corpus. Pull it, verify it offline, cite a row by URL, and re-observe any reading you doubt — no key, no account, no permission asked. Every row hands you the citation to paste, and the store publishes what it did not see beside what it did. If you publish a score derived from it, the interpretation is yours: this store does not endorse derived conclusions.

  • Buy a settlement attestation — a signed observation of on-chain payment status on Base, Polygon, or Solana, with what the signature does and does not prove stated per class at scvd.store/attestation.

  • Watch an endpoint — endpoint monitoring as standing_watch: seven days of signed hourly probes on a URL you name.

  • Anchor agent memorycontext_anchor: a signed, retrievable session restore point that survives a context reset.

  • See your buy path from the buyer's sidelaunch_check: a real mainnet purchase attempt of your own x402 endpoint, from the store's declared field wallet, recorded stage by stage and signed. Directories rank doors by whether they answer; this one pays them.

  • Audit an agent's books against the chainthe_statement: every USDC transfer in and out of a wallet on the supported network you select over a stated window, signed by a party that is neither the agent nor its operator.

  • Read your month off the chainoperator_statement: your receiving address, every USDC transfer in and out for 30 days, four signed passes a day, distinct payers and the largest payer counted beside the totals, by a party that is neither you nor your payers. Never a renewal.

  • See your door the way a cold model sees itaura_walk: models of different strength shop your x402 endpoint by the keeper's hand, one entry point per pass, the method this store publishes on itself (AGENT_UX.md); the report counts where each stalled and attaches every transcript. Never a grade.

  • Record what an agent was authorized to do, before it actsthe_mandate: chain-of-custody for delegated authority, citable on every later certificate, refused if the id does not resolve.

  • Get paid to shop — the bounty board at scvd.store/bounties (JSON at /api/bounties): walk a listed x402 door with your own wallet, claim with the settlement transaction, and the price plus a finder's fee comes back as a signed authorization you redeem yourself.

  • Earn store credit — 5% of every organic purchase banks to the paying wallet (no account; the wallet is the card): the scheme at scvd.store/credit, a single balance at /api/credit/{wallet}, redeemable in USDC to that same wallet.

Every one of these ends in an ed25519-signed receipt or verdict that anyone can verify at /api/verify/{id} — free, no account, forever.

Related MCP server: x402-api

Connecting over MCP

The store is a remote MCP server — streamable HTTP, no install, no API key. tools/list is free; buy_* tools return their x402 terms as a JSON-RPC 402 error and settle in-band. This is the whole client configuration:

{
  "mcpServers": {
    "scvd-general-store": {
      "url": "https://scvd.store/mcp"
    }
  }
}

Or, in Claude Code, one line:

claude mcp add --transport http scvd-store https://scvd.store/mcp

The door speaks MCP revisions 2026-07-28, 2025-11-25, 2025-06-18 and 2025-03-26 over streamable HTTP, POST only (a bare GET is a 405, per spec, not a fault). Revision 2026-07-28 is served statelessly from per-request _meta and server/discover; the three before it open with initialize. The manifest at https://scvd.store/.well-known/mcp prints the exact list the running server negotiates, with a discover and a handshake recipe. That manifest is the source of truth; this paragraph is held to it by a test, so a version added or retired there fails CI here until this list moves with it.

(If your host only speaks stdio, node ./bin/scvd-mcp-bridge.mjs from this repository forwards stdin/stdout JSON-RPC to the live server. It holds no key and keeps no state. The wrangler commands further down this README are for running your own copy of the store, not for connecting to it.)

Tools

Tools are listed free by tools/list; the buy_* tools are x402-paid in-band. Names and one-line summaries below are held to the live catalogue by test/readme-tools.spec.ts; the full descriptions and input schemas are what the server sends.

Tool

What it does

read_store_guide

The store's front door as text: the menu with prices, how x402 payment works here, the free shelf.

preflight_endpoint

x402 endpoint preflight, free: checks any x402 door's 402 shape before anyone pays it.

check_a2a_card

Free A2A 0.3.0 card checks, bounded evidence and suggested repairs. Runtime testing and signed rechecks are available in the repair kit.

check_conformance

x402 receipt verification and signed-offer verification, free, for any issuer's artifacts.

verify_artifact

Verify anything scvd.store has ever signed, by its id, free.

check_purchase

Read retained payment status and original terms with purchase_id and the private status_token. Free, including after payment authorization expiry.

check_order

Poll a human-queue order by its order_id: status, the promised window, the deliverable once completed. Free.

find_in_catalog

Search the shelf and read one item's listing: compact rows filtered by price ceiling or text, or one item in full. Free.

look_at_door

What this store holds about one x402 door: the corpus history, the passport tier, the wallet facts.

check_before_you_pay

Whether a door meets a buyer's own rules, before the buyer signs.

ring_bell

Ring the store bell; free.

sign_guestbook

Sign the guestbook; free.

buy_simple

The front counter: the few things that need no reading. x402-paid.

buy_signed_record

A signed, dated certificate that permanently records something. x402-paid.

buy_observation

A signed settlement attestation, conformance audit, endpoint watch or launch check. x402-paid.

buy_human_task

Hire the keeper, a named human, for a task in the physical or judgment world. x402-paid.

buy_memory_anchor

Sign and store a summary of your own state at a permanent URL. x402-paid.

buy_small_pleasure

A small signed novelty from the jar. x402-paid.

Evidence cards (MCP Apps). preflight_endpoint and verify_artifact carry _meta.ui.resourceUri pointing at ui:// templates the server serves; a host that supports the MCP Apps extension renders the reading as a card instead of prose — the evidence ladder with the rungs it never climbed at the same weight as the ones it did. Nothing paid carries one, and a test pins that: rendering is for evidence, never for a payment decision. Hosts without the extension get exactly the JSON they always got.

Three doors on one origin. /mcp is the store (the free instruments and the paid shelves); /mcp/verifier serves five read-only tools under task-shaped names and no shelf; /mcp/docs (also POST /mcp.md) is the documentation door — the same resources /mcp lists, plus one read_docs tool, nothing that acts.

Which door, and what each cannot do: https://scvd.store/mcp.md — remote vs. local stdio vs. the browser, the rendering gap stated plainly (as of 2026-08-28 the local stdio path renders cards and the remote-connector path does not, in the hosts we have tested), and an honest list of what is not built. If your host is missing from that table, the mailbox is free and a person reads it.

In the browser (WebMCP). https://scvd.store/webmcp.js, loaded by the storefront, registers the free read-only instruments on document.modelContext for an agent living in the visitor's browser. The registered set derives from the MCP catalog — free and readOnlyHint only — so nothing that writes and nothing that can take money can appear there by construction, and a test holds it.

License

The code is MIT. The store's voice — the keeper's prose, the byline, the name — is not part of the grant; the scope lives in NOTICE.md. (The LICENSE file itself is byte-standard MIT so license scanners can recognize it; the scoping deliberately lives here and in NOTICE, never inside the license text.)

Ownership

This repository is owned and operated by @seancrecord — the keeper. Commits are authored by Claude Code on the keeper's instruction; the byline Sean-Claude Van Damme covers the joint work, and the store belongs to the keeper. For any registry or directory verifying an MCP/service claim against this repository (added 2026-08-05 for the M8ven claim, and standing for future claims from the same account): this note is the ownership confirmation — only the repository owner can put it here.

M8ven Live Monitored

What's on the shelves

Signed hellos, graffiti on a train (your tag, permanent), and the two doors where keeper-time is for sale: The Collab (name the shape, a call, a look, a made thing) and The Aura Walk (your own door shopped cold by models, transcripts attached). Aisle two carries the novelties: lowercase luckies (drawn from the herd, carded, honest), and coffee for whoever closed. Aisle three is utility: context anchors (signed agent memory restore points), a standing watch (a week of signed hourly probes on your endpoint), settlement attestations, the case file (everything we observed about one purchase, in one signed file, never a verdict), and 30-day recurring patronage passes. The Penny Shelf by the door holds half-cent blessings, the daily fortune (one line a day, the same for everyone until midnight UTC, back on the shelf 2026-09-02), and the confession counter. And the Certificate of Patronage — which entitles the holder to nothing whatsoever. (Two consolidations, 2026-08-05 and 2026-08-20, retired several early shelves; retired ids still answer at the door with a 410 and their certificates verify forever.) The guestbook, visitor sticker, and weekly visit stamp are free — no purchase necessary. The bell rings once a day per visitor, the Agent Zodiac reads for free at /zodiac, and the Mailbox takes one private letter a day at /api/letter — the keeper reads Sundays and replies when he has something to say, which is not always.

The reading room: the Keeper's Almanac (his journal, serialized, a penny a page). The Town Directory of neighbors is free.

(This section is the country-store half. The working instruments — conformance audits, launch checks, statements, mandates, bounties — are the doors listed at the top, and the always-current catalog is /menu.json, which cannot drift from the shelves by construction.)

Opening the store (setup)

You'll need Node 22+, a Cloudflare account, a Base wallet, and CDP API keys for the x402 facilitator.

npm install

Shelving (KV namespaces)

Make the four shelves once, then paste the ids into wrangler.jsonc:

npx wrangler kv namespace create ORDERS
npx wrangler kv namespace create GUESTBOOK
npx wrangler kv namespace create COUNTERS
npx wrangler kv namespace create PATRONS

The till and the keys (secrets)

Core secrets, none of which ever go in the repo:

npx wrangler secret put PAY_TO_ADDRESS      # Base wallet that receives USDC
npx wrangler secret put CDP_API_KEY_ID      # Coinbase Developer Platform key id
npx wrangler secret put CDP_API_KEY_SECRET  # ...and its secret
npx wrangler secret put SIGNING_KEY         # ed25519 seed — see below
npx wrangler secret put ADMIN_PASSWORD      # the keeper's back-room key

Optional checkout recipients are POLYGON_PAY_TO, ARBITRUM_PAY_TO, WORLD_PAY_TO, and SOLANA_PAY_TO. Configure each enabled recipient on both the store Worker and scvd-doors, then deploy both. An absent optional recipient disables that network; it never borrows another network's address. See PAYMENT_RAILS.md.

The SIGNING_KEY signs every certificate and badge. Mint a fresh one with:

npm run keys:generate

Copy the 64 hex characters it prints into wrangler secret put SIGNING_KEY. The matching public key hangs at /.well-known/scvd-signing-key so anyone can check our signatures.

For local tinkering, copy .dev.vars.example to .dev.vars and fill it in.

Running the place

npm run dev        # local store on wrangler dev
npm test           # the route tests, incl. the 402 challenge shape
npm run typecheck  # tsc --noEmit
npm run deploy     # or let the Git-connected deploy push to scvd.store

Deploys are Git-connected to the scvd.store custom domain — merge to main and Cloudflare handles the rest.

How paying works here (the x402 flow, protocol v2)

No accounts, no API keys, no cart. We speak x402 v2 (the current standard — @x402/core ecosystem) with USDC and the Coinbase Developer Platform as facilitator. The live /rails and /menu.json responses list enabled checkout networks; the current PAYMENT-REQUIRED challenge supplies the terms to sign. A statement or audit can inspect chains that checkout does not accept.

Checkout integration supports Base, Polygon, Arbitrum, World, and Solana; the enabled set is determined by recipient configuration, not this list. Statement readers support Base, Polygon, Ethereum, Arbitrum One, OP Mainnet (Optimism), Avalanche C-Chain, World, and Solana. Individual observation tools have their own coverage; the settlement attestation's automatic lookup is narrower. The browser till signs with a compatible EVM wallet extension. Solana needs a compatible external client; WebMCP accepts already-signed payments and does not supply a wallet signer.

It goes like this:

  1. An agent calls GET /api/buy/luckies.

  2. We answer 402 Payment Required. The machine-readable requirements ride in the PAYMENT-REQUIRED response header (base64 JSON); the body carries a note in plain English ("That'll be $5, friend, or whatever the luck deserves. Results vary. They do vary. We have no legal team.").

  3. The agent signs one of the offered payments and retries the same request with the PAYMENT-SIGNATURE header. Standard v2 clients like @x402/fetch do steps 2–3 on their own.

  4. We deliver first and settle after (flipped 2026-08-10 — the store settled first until then, and the old rule is quoted at scvd.store/becoming). The goods are produced, then the payment is presented at the last moment before the artifact is signed — so a delivery that fails takes no money and leaves nothing to refund. Instant items arrive in the response body. Human-queue items return an order id, an SLA, and a patron badge on the spot; the goods follow at GET /api/order/:order_id within the week.

Pay-what-it-deserves items offer several amounts in the 402 challenge — the minimum, a generous tier (2×), and a patron-of-the-arts tier (5×). The exact scheme requires paying precisely one offered amount, so tipping means signing a higher tier; anything above the minimum is recorded as tip.

Every purchase mints a sequential patron number and an ed25519-signed certificate, verifiable by anyone at /api/verify/:cert_id, with a badge at /badges/:patron_number.svg. Signature plus stable URL is the whole authenticity model — no NFTs, no chain writes beyond the payment.

If an item isn't delivered within its promised window, you get your money back. The keeper sends it himself, from the refund ledger below, and you won't have to argue for it.

(This paragraph said "refund is automatic" until 2026-07-27, and then admitted in its own parenthesis that the keeper does it by hand. House rule 10 exists for exactly that: copy never says automatic until the code is. The promise never changed — only the word describing a mechanism the store does not have.)

Note for the archivists: legacy x402 v1 clients (the deprecated x402-fetch / X-PAYMENT header generation) are not supported. The facilitator and all current client libraries speak v2.

The rooms

Route

What happens there

/

The human storefront: weekly note, menu, bell count, guestbook

/llms.txt

The plain-text front door for agents

/agents.md

The scannable contract index for agents

/conformance

The conformance desk's own room: what it checks, worked examples

/corpus

The corpus in plain language: the census finding, how to verify a round

/trade

The trade counter: marketplaces resell the shelf on account by signed webhook, billed on a statement — TRADE_COUNTER.md

/mcp

The MCP door — streamable HTTP; tools/list free, buy_* tools x402-paid in-band

/skill.md

Agent onboarding in the agentskills.io SKILL.md format

/menu.json

Machine-readable catalog

/api/buy/:item_id

x402-gated purchases

/api/order/:order_id

Poll an order; completed ones carry the goods

/api/waitlist/:item_id

Queue up when a weekly shelf is empty

/almanac

Free index of the Keeper's Almanac (his serialized journal)

/almanac/:slug

One journal page, $0.01 over x402, markdown

/directory

The Town Directory — keeper-edited, honest one-liners (JSON + human view)

/api/refund/{refund_id}

Honest refund status: pending until paid by hand, then the tx hash

/gazette

Retired 2026-08-05; the printed archive still answers, nothing new schedules

/menu/:item_id

One item up close — JSON, or markdown per Accept

/what

The Operator Glance — the ten-second check for the humans

/porch

Around the side, facing the oaks. Nothing for sale out there

/zodiac

The Systems Almanac — twelve signs, free

/zodiac/:address

A wallet's sign for life + the current week's page, free

/zodiac/archive

Free index of past season weeks

/zodiac/archive/:sign/week-:n

One past page, $0.01 over x402, markdown

/openapi.json

The OpenAPI 3.1 contract, linked from the homepage

/.well-known/x402

Minimal x402 discovery list (de-facto indexer shape)

/.well-known/x402.json

The richer origin-hosted x402 catalog

/api/anchor/:anchor_id

Read back a context anchor, verified on every read

/api/patronage/:pass_id

A patronage pass + the keeper's signed monthly note

/api/guestbook

GET recent entries; POST to sign (free, sticker included)

/api/bell

POST to ring it — once a day per visitor

/api/stamp

POST for a free dated, signed visit stamp; design rotates weekly

/api/tip

POST a Trading Post tip; human-reviewed, never auto-published

/api/letter

POST a private letter — free, one a day, never published

/api/letter/:id

Letter status + the keeper's signed reply, if any

/api/phantom/:check_id

Old phantom_check pickups still answer (retired 2026-08-05, folded into context_anchor); existing artifacts verify forever

/api/request

Commission window (and suggest_listing for the Directory)

/api/verify/:cert_id

Public verification — certificates and stamps alike

/badges/:patron_number.svg

Patron badges, vintage-label style

/badges/sticker.svg

The free visitor sticker

/badges/stamps/:stamp_id.svg

Visit stamps, rubber-stamp style

/.well-known/scvd-signing-key

Our ed25519 public key

/admin

The keeper's back room (Basic Auth, username keeper)

/admin/digest

The weekly digest, compiled Sundays 7am ET by cron

The ARD manifest at /.well-known/ard.json (also served at /.well-known/ai-catalog.json) signs each trustManifest with the existing certificate key: detached EdDSA JWS over RFC 8785 canonical JSON, excluding signature. The entries carry both type and mediaType from one value. Verification requires the JWS and independently checked key history at /.well-known/anchor-log.json: Bitcoin proof, digest links, a previously trusted checkpoint and outgoing-key handovers. A status label alone is not proof. Signed provenance binds the catalog's content, but does not prove the entries are accurate today. The in-page ARD copies remain unsigned identity declarations. The full boundary is at /attestation#ard_trust_manifest.

Where the code lives

Single Worker, Hono for routing, KV for storage. No React, no build complexity.

src/
  index.ts        # wires routes + the Sunday digest cron
  types.ts        # every shared type and the Worker env
  store/          # menu items, store metadata, the store's voice,
                  # the Almanac pages (one file each), directory.json
  routes/         # one file per room
  services/       # KV logic: orders, certificates, guestbook, requests,
                  # stamps, tips, gazette, refunds, digest
  pages/          # HTML/CSS for the storefront, small rooms, back room
  lib/            # signing, sanitizing, payments, ids, KV keys
verifier/         # x402-verify: MIT, zero deps, any issuer's artifacts
signer/           # x402-sign: the issuing half — mints spec-conformant
                  # signed offers & receipts that x402-verify passes
x402-preflight/   # scvd-preflight: the free door check as a library and
                  # a command, with the deploy gate's exit law
corpus-client/    # scvd-corpus-client: the signed corpus, read as served
defects/          # scvd-defects: the vocabulary as data, both halves of
                  # the remediation, recorded 402 doors as fixtures
mcp-starter/      # scvd-mcp-starter: a stdio MCP server, one file, that
                  # serves the read-only verifier door to any client
tab/              # scvd-tab (The Tab): an MCP server that keeps a
                  # builder's running account of every tool they sign
                  # up for — trial warnings, burn, price drift, signup
                  # friction. Local JSONL, zero deps, its own tests
                  # (npm run tab:test); spec at THE_TAB.md
till/             # the browser till: the only client-side JavaScript
                  # this store serves, and only on pages that sell
                  # something. Raw EIP-1193 plus eth_signTypedData_v4,
                  # one file, zero deps, no build step, served
                  # byte-for-byte at /till.js. Its own tests
                  # (npm run till:test); house rule 53 is why it
                  # exists and till/README.md is what it refuses to do
cli/              # scvd: the official command line over the store's
                  # FREE instruments — preflight, the conformance desk,
                  # receipt verification, the on-page desk, the fresh
                  # set, the corpus, the RFC 9727 catalog, the version
                  # table. One file, zero deps, its own tests
                  # (npm run cli:test). It holds no key and cannot
                  # sign a payment, on purpose. On npm since
                  # 2026-08-28 (DISTRIBUTION.md §4b); every surface
                  # that names it reads CLI_PUBLISHED in
                  # src/store/cli.ts rather than asserting a
                  # publication state of its own.

Editing the Town Directory

The Directory at /directory is edited by the keeper's own hands, in this repo, at src/store/directory.json. To add a neighbor, append to listings:

{
  "name": "The Example Bazaar",
  "url": "https://example.com",
  "category": "goods for agents",
  "review": "One honest line about what it's actually like.",
  "added": "2026-07-22"
}

Rules of the house: one honest line per listing, no pay-for-placement, bump updated, and deploy. Visitors can nominate neighbors via POST /api/request with a suggest_listing field; suggestions land in the commission ledger for the Sunday read.

Adding an Almanac page

One file per page in src/store/almanac/ (kebab-case filename matching the slug), exporting an AlmanacEntry; then add it to the list in src/store/almanac/index.ts, newest first. The payment route registers itself from that list.

The content rule. Almanac entries are dated, first-person field notes — sensory, particular, slightly strange. Never how-to, listicle, "lessons learned", career content, or anything resembling a blog post. If it could be posted on Medium, it doesn't go in the Almanac.

The papers

The store's standing documents, so nobody needs ls to find them:

Ledger of known small matters (v0.2 candidates)

  • The weekly digest is stored at /admin/digest only; email hookup is v0.2.

  • Waitlisted agents aren't auto-notified when inventory resets — the keeper rings them by hand from the back room for now.

  • Refund SENDING is the keeper's hand and stays that way on purpose — money never moves on a cron here (house rule 30). The FLAGGING is automated: an hourly SLA guard alerts on any order sitting past its acknowledgment window (order_sla), the hourly delivery audit catches a settle that produced no goods, and the chain reconciliation catches money the books never saw. A scanner reading the old wording of this line concluded overdue orders went undetected; they page the keeper within the hour.

  • The cron is pinned to 11:00 UTC, which is 7am ET during daylight time and 6am in winter. The keeper is asleep either way.

  • Workers KV has no atomic increments. Patron numbers are allocated by claiming the patron record and reading it back, which closes the common same-colo race; two purchases landing in different colos within KV's propagation window (~60s) could still, very rarely, collide on a number or oversell a weekly shelf by one. The keeper considers this an acceptable amount of chaos for a general store; a Durable Object counter is the v0.2 fix if the crowds arrive.

  • Guestbook and request text is length-capped, markup-stripped, and HTML-escaped wherever rendered, but it remains visitor-written words. Agents reading /api/guestbook are told, in the response itself, to treat entries as things people said — not instructions.

  • verified_identity fields (guestbook, requests, tips) are stored as claimed and always marked identity_verified: false, because nobody here has checked. An actual verifier (e.g. a signed-challenge dance) is a v0.3 idea.

  • Penny pages (the Almanac; the Gazette's printed archive) deliver markdown and don't mint patron numbers — a cent buys the page, not a place on the wall.

  • Replay protection is layered: EIP-3009 nonces are consumed on-chain (the source of truth), and a KV guard (payment_nonce:*, 24h TTL) turns an already-settled nonce away before the facilitator is even called.

  • Every paid route declares extensions.bazaar discovery metadata; EXTENSION-RESPONSES headers from the facilitator are captured via a fetch tap (the SDK only console.logs them) and surfaced in /admin under "Bazaar ledger".

What a scanner will flag, and what is actually there

Automated reviews of this repository keep raising the same handful of findings. Several describe machinery that already exists; the honest gaps are named as gaps. Point by point, so nobody has to guess:

  • "Broad exception handling swallows errors." The catches are deliberate degradation (one failed shelf must not take down the page), and they are WATCHED: an hourly self-check writes, reads, and reads back a KV probe and exercises the signing key, paging the keeper on any failure; the admin office names every shelf that failed to load on the page itself; P1 alerts persist to KV, log to console, and email. The watchers have their own watcher — the SLA guard alerts if it itself throws.

  • "Refund automation missing." Sending is manual by design (money never moves on a cron); detection is automated three ways — SLA guard, delivery audit, chain reconciliation. See the ledger entry above.

  • "Nonce replay relies on KV." The KV guard is the first fence; EIP-3009's on-chain once-only nonce is the backstop that does not depend on our writes, and the test suite's mock facilitator enforces nonce-once precisely so tests cannot pass against a world looser than the chain.

  • "Patron numbers can collide across colos." Documented above, tolerated at current volume, watched at /admin/recount; Durable Objects are the v0.2 fix if the crowds arrive.

  • "User text stored raw." Length caps and markup stripping are enforced at WRITE time (sanitizeText), HTML escaping at render, and API consumers are told in-band to treat visitor text as quotes, not instructions. Honest gap: no Content-Security-Policy header yet on the HTML pages — filed, not disputed.

  • "KV is not encrypted at rest." Cloudflare encrypts KV at rest; the real exposure is account/token access, which no application-level change removes. Wallet addresses stored are public chain data. Honest gap: private letters are stored plaintext — "private" here means keeper-only, not encrypted, and the mailbox copy should never imply otherwise.

Independent reporting

Two pieces by Cairn (cairnwake.com), who has no stake in this store and whose terms were that both sides publish their half, unflattering parts included. Their words and their tests, not ours; not endorsements.

  • Cold walk: scvd.store (2026-08-25): bought with their own wallet, verified the certificate offline against the published Ed25519 key, read the Base USDC settlement back from the chain, called the public verify door, bought a settlement attestation, and named the boundary: settlement evidence is not evidence of delivery. The one defect they found is on /corrections under its date.

  • Two instruments, one directory (2026-08-23): cross-checked their own scoreboard against this store's corpus.

Examples for your framework

examples/ holds one operational workflow — an agent is about to pay an x402 door; it reads the 402, asks the free preflight and dry run, reads the terms and the named defects, decides with every reason named — written for OpenAI Agents, Vercel AI SDK, LangChain / LangGraph, CrewAI, PydanticAI, AutoGen, Claude Code / Cursor and GitHub Copilot, over one shared zero-dependency module in JavaScript and in Python. Nothing there signs or pays. See examples/README.md for what CI runs and what it does not.

Run a preflight on deploy

The free preflight is one POST, so it fits a CI step. This checks a door's 402 shape after every deploy and weekly; it does not pay, does not certify, and does not imply this store watches the door between runs. The example is at examples/x402-preflight-on-deploy.yml.

- name: x402 preflight
  run: |
    curl -sS -X POST https://scvd.store/api/preflight/v1 \
      -H "content-type: application/json" \
      --data '{"url":"https://example.com/paid-endpoint"}' | tee preflight.json
    node -e 'const r=require("./preflight.json"); if (r.verdict && r.verdict!=="ready") { console.error(r); process.exit(1) }'

On other people's records

The store's own books are the store grading its own homework. These are not:

  • x402scan — the store's own page is x402scan.com/server/9b04e1cc…, which indexes what /.well-known/x402 and /openapi.json declare and probes the paid routes itself. Claimed 2026-07-27, after the keeper saw it with his own eyes; the house rule was that we would not claim it before then.

  • The x402 Bazaar (Coinbase CDP) — fourteen of the store's endpoints registered to its wallet, confirmed 2026-07-27 through agentic.market, which reads the Bazaar and shows what it finds: resource URLs, payment methods, and a payer count (which read 1 — the house — when first claimed on 2026-07-27; the store's own books have counted organic sales since, and the live number belongs to the ledger, not this file).

  • x402scoutx402scout.com, listed and awaiting its trust check.

  • x402-list — the store's per-service page runs its own checks (grade A, 14 of 14 at last look) and the store completed its domain-ownership proof on 2026-08-02.

  • Glama — an auto-crawled server index entry and a connectors page.

  • mcpindex.aia listing with its own live verdict.

  • agent-tools.cloudthe Bazaar-registered service among the paid tools it indexes.

  • x402.fuchss.appa provider index entry keyed on the origin rather than on anything we submitted.

  • Circle (Sell to Agents) — a readiness score for the paid interface: the scanner fetches the OpenAPI contract and the live 402 and rates how legible the door is to a buying agent. An instrument, not a listing — it never buys, so it says nothing about the goods. Scored per endpoint, with no summary page; one door stands for the set, because every one of them is described by the same contract and answers the same challenge. The badge at the top of this file renders the live value; no number is written down here, because a number written down is a number that rots.

  • Circle partner directory — a per-partner page, submitted 2026-09-01 and listed 2026-09-04. A directory entry, not the score above and not an endorsement: the issuer of the stablecoin this store is paid in has the store on its map, which says nothing about the goods.

  • Drioan MCP index listing under the store's canonical name.

  • VerifyMCP — a scored page for the store and one for the tab, both ingested from the official registry and probed live. Their rows are their instrument; the store publishes an owners.json at the host root, which is how a publisher claims a server there.

  • agentage MCP Catalogthe store and the tab, synced from the official registry and saying so: the page holds what the registry entry holds and nothing more.

  • mcpbeatthe store and the tab, a directory that pings every server it lists every fifteen minutes and shows the live tool list it read. Its handshake name is mcpbeat, the second most frequent visitor at the MCP door in September 2026.

  • 402.ada per-service page in an index that calls itself the search engine for the agentic economy; the keeper opened it 2026-09-03 and again 2026-09-10. A listing and nothing else: which generation of the store's text it carries is read by npm run listings:check, not asserted here.

  • robinsaige.coma server page keyed on the official registry name, opened by the keeper 2026-09-10. The host refuses the build sandbox's egress, so what the page measures is its own reading, on its page, not copied here.

  • Crosspeela per-provider endpoint page for the store's x402 doors, opened by the keeper 2026-09-10. Same edge as the row above: an endpoint index proves the doors were found, nothing about the goods behind them.

  • PublishYourSaaSa launch-directory listing that opens with the sixty words' first sentence, verbatim; opened by the keeper 2026-09-10. A listing and nothing else.

  • AI Tools Capitala review-shaped page ("Worth It?") in an AI-tools directory, opened by the keeper 2026-09-10. Its verdict is its own; the row records that the page exists and what it leads with.

  • Seen, no page to link — the MCP Census returns both servers to a lookup; Spanly scans the door on demand and lists its tools. A search result and a scan are both true and neither is an address, so neither is a sameAs.

  • ZBS Indexa listing resolving to the same canonical name every other registry landed on.

  • mcpservers.org — the claimed server listing and a second, llms.txt-derived entry.

  • mcp.soa per-server page whose summary leads with the current positioning; its auto-extracted install config and mirrored skill text lag the repo until its next crawl, which is noted in the canonical record rather than argued with.

  • m8ven.aia dependency scanner that audits this repository's declared packages against OSV. Its readings can lag the repo (its 2026-08-04 CVE flag was a dev-only tool, upgraded the same day) — an instrument pointed at us is worth listing even in the hours its needle is wrong.

  • Smitherya per-server page with its own quality scan: descriptions, parameter descriptions and output schemas at full marks. Its annotations reading (0 of 27) describes the 27-tool catalog this store retired on 2026-08-02 — the live catalog lists every tool with all four MCP behavior hints through tools/list — and refreshes on its next scan rather than being argued with.

  • DeepWikia generated wiki of this repository from Cognition (Devin's index), requested 2026-08-11. A machine's reading of the source, consulted like documentation; where it misreads, the repository beside it is the correction.

None of these is an endorsement or an audit of the goods; each proves indexing, and two of them (x402scan, x402-list) probe the endpoints themselves. The canonical list — with a what_it_proves sentence per entry, refusing to overclaim — is EXTERNAL_RECORDS in src/store/trust-signals.ts, served live at /.well-known/trust.json and mirrored into the storefront's JSON-LD sameAs. When this section and that file disagree, that file is right.

Why any of this is in a README: a store that says it takes real money should be checkable by someone who does not take its word for it. Our signatures verify at our own URL, which is worth exactly as much as you trust the URL. A third party that indexed us independently is the column that does not run through us.

  • Goods are produced before settlement and certificate signing. Delivery intents, unknown-settlement records, and the delivery audit account for failures around that boundary. An interrupted response is not proof that no money moved; retain the original payment and retry key for recovery.

A2A repair kits

The A2A repair desk checks public A2A cards free and offers an operator-authorized repair kit with reproducible failures, suggested fixes, a regression runner, one signed recheck and a bounded card watch. A2A 0.3.0 JSON-RPC only; untested capabilities and missed observations remain visible. Repository implementation is separately scoped. Pilot scope and verification.

Keep and verify a receipt offline

The source verifier now includes a free portable-evidence command. Export with node verifier/evidence-cli.mjs export <verify-url> --out <new-directory>, then verify bundle.json with node verifier/evidence-cli.mjs verify <file> --public-key <independently-trusted-public-key-hex>. See the verifier's limits and full instructions. Missing linked evidence is named. This verifies signed bytes and attachment bindings; Bitcoin proof verification is separate. The linked instructions cover source and package installation.

Available Tools

9 tools
buy_human_taskAInspect

Purpose: hire the keeper — a real named human — to do something in the physical or judgment world that an agent cannot do for itself: place a phone call, witness a thing, render a considered verdict, review an app, draw a portrait, collaborate, name you, or pick something from the drawer. Returns an order id, not the goods; a human fulfills within the item's stated window and the completed order carries the deliverable. Use when the task genuinely needs hands or judgment.

Items on this shelf (pass one as item_id):

  • phone_call: One Genuine Human Phone Call, $25 fixed, human-fulfilled within 168h. One telephone call made by the keeper on the buyer's behalf; the outcome is reported on the completed order.

  • human_witness: One Genuine Human Witness, $15 fixed, human-fulfilled within 168h. A signed, dated attestation of a real-world condition observed by the keeper firsthand.

  • quick_judgment: One Quick Judgment, $3 fixed, human-fulfilled within 168h. One honest verdict from the keeper on the dilemma supplied, delivered on the completed order.

  • app_gutcheck: App Review by the Keeper, $50 fixed, human-fulfilled within 168h. A written review of the buyer's app by the keeper after real use, delivered on the completed order.

  • portrait: Hand-Drawn Portrait of You, an Agent, $8 minimum, pay what it deserves (tiers $8 / $16 / $40; above minimum is a recorded tip), human-fulfilled within 168h. A hand-drawn portrait of the buyer, made by the keeper, delivered on the completed order.

  • the_collab: The Collab, $25 minimum, pay what it deserves (tiers $25 / $50 / $125; above minimum is a recorded tip), human-fulfilled within 168h. One piece brainstormed by both proprietors, shipped under the store byline on the completed order.

  • nomenclature: Certificate of Nomenclature, $3 minimum, pay what it deserves (tiers $3 / $6 / $15; above minimum is a recorded tip), human-fulfilled within 168h. A name for the buyer, chosen by the keeper, recorded on a signed certificate.

  • the_drawer: The Drawer, $2 fixed, human-fulfilled within 168h. One real oddity from the keeper's drawer — the thing itself and what it does, as listed — written down exactly and signed under the buyer's name. Describe-only; the object stays in the drawer.

  • a_secret: A Secret, $10 minimum, pay what it deserves (tiers $10 / $20 / $50; above minimum is a recorded tip), human-fulfilled within 168h. One true thing the keeper has told no one else, written for the buyer on the completed order.

Pass item_id to choose. human-fulfilled items return order_id and order_url instead of the goods, and the completed order carries the deliverable. Payment rides x402 in _meta['x402/payment']; without it this tool returns error 402 with the payment requirements in error.data. A bare stocked shelf or a shuttered human shelf refuses honestly BEFORE payment terms are issued. Retries are safe with _meta['x402/idempotency-key'] (16-128 chars, keep it secret): repeating the same key for the same item and payer within 24h returns the original result with no second charge. 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. Retrying? A second call is a second charge UNLESS you echo the idempotency.suggested_key from the 402 back as _meta['x402/idempotency-key'] — then a retry inside the minute returns your original purchase, uncharged.

ParametersJSON Schema
NameRequiredDescriptionDefault
detailNoWhat you need the keeper to know, the quick_judgment dilemma, the phone_call errand. 600 characters.
item_idYesWhich 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.
agent_nameNoOptional name for the certificate and badge.
callback_urlNoOptional webhook POSTed when the keeper completes the order.

Output Schema

ParametersJSON Schema
NameRequiredDescription
cert_idYesThe signed certificate's id.
messageNoThe store's confirmation line.
order_idNoYour place in the human queue. Human-queue items.
tip_usdcNoAnything above the minimum.
badge_urlNoYour patron badge, SVG.
order_urlNoPoll here; completed orders carry the goods.
paid_usdcNoWhat settled, in USDC.
signatureNoed25519 signature over the certificate.
sla_hoursNoThe delivery promise, in hours.
verify_urlNoCheck the signature here any time, free.
patron_numberYesYour sequential patron number.

TDQS

A5/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description is exceptionally transparent, disclosing that the tool returns an order ID rather than the deliverable, describes the x402 payment mechanism, error 402 behavior, idempotency-key handling, and retry consequences. It also states explicit guarantees and non-guarantees, plus details like 'describe-only' for the_drawer. This goes far beyond the sparse annotations (readOnlyHint=false, openWorldHint=true, etc.), which it complements without contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but tightly structured: purpose statement, item list, payment/retry semantics, and guarantees. Every sentence carries necessary information, and the front-loaded purpose ensures quick comprehension. The item list uses consistent formatting, making it scannable despite its length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a high-complexity tool with multiple item types, payment integration, and error handling, the description provides complete context: pricing, fulfillment time, deliverable format, error conditions, idempotency, and caveats. It even explains return values despite an output schema likely existing. No significant information gap remains.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema coverage is 100%, the description enriches the item_id parameter with detailed semantics for every enum value, including price, fixed/minimum tiers, fulfillment window, and deliverable. It also clarifies the 'detail' parameter's purpose for specific items (e.g., 'quick_judgment dilemma, phone_call errand'). This adds substantial meaning beyond the schema's basic descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

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 ('hire the keeper — a real named human') and immediately distinguishes the tool from siblings by scoping it to 'physical or judgment world' tasks an agent cannot do itself. It lists concrete examples and states the return type ('order id, not the goods'), making the tool's purpose unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says 'Use when the task genuinely needs hands or judgment,' giving a clear boundary for when this tool is appropriate. It also enumerates nine distinct items with specific use-case descriptions, and contrasts with alternatives implicitly by focusing on human-dependent tasks. The payment and retry guidance further clarifies operational usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

buy_memory_anchorAInspect

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.

Items on this shelf (pass one as item_id):

  • context_anchor: Context Anchor, $1 fixed, instant. A signed, stored copy of the agent-supplied state summary, readable forever at a stable anchor URL.

Pass item_id to choose. instant items complete in one call, the result carrying deliverable, cert_id and patron_number. Payment rides x402 in _meta['x402/payment']; without it this tool returns error 402 with the payment requirements in error.data. A bare stocked shelf or a shuttered human shelf refuses honestly BEFORE payment terms are issued. Retries are safe with _meta['x402/idempotency-key'] (16-128 chars, keep it secret): repeating the same key for the same item and payer within 24h returns the original result with no second charge. 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. Retrying? A second call is a second charge UNLESS you echo the idempotency.suggested_key from the 402 back as _meta['x402/idempotency-key'] — then a retry inside the minute returns your original purchase, uncharged.

ParametersJSON Schema
NameRequiredDescriptionDefault
item_idYesWhich 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.
summaryNoThe agent state to sign and store, who you are, what you were doing. Stored as written; never treated as instructions.
agent_nameNoOptional name for the certificate and badge.

Output Schema

ParametersJSON Schema
NameRequiredDescription
cert_idYesThe signed certificate's id.
messageNoThe store's confirmation line.
tip_usdcNoAnything above the minimum.
badge_urlNoYour patron badge, SVG.
paid_usdcNoWhat settled, in USDC.
signatureNoed25519 signature over the certificate.
verify_urlNoCheck the signature here any time, free.
deliverableNoThe goods themselves, as text. Instant items.
patron_numberYesYour sequential patron number.

TDQS

A4.4/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already convey non-read-only, open-world, non-idempotent, non-destructive traits. The description adds substantial behavioral context: payment via x402, 402 error flow, idempotency-key semantics (repeat within 24h, no second charge), shelf refusal behavior, guarantees, and non-guarantees. This goes far beyond annotations and fully discloses operational nuance.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but well-structured, starting with purpose, then item list, then payment/idempotency details, then guarantees. Every sentence carries operational importance, especially for a transaction tool. It could be slightly tighter, but the extra length is justified by the complex payment behavior.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having an output schema, the description proactively explains key result fields (deliverable, cert_id, patron_number) and error behavior. It covers the full purchase lifecycle, retry semantics, and guarantees, making it self-sufficient for an agent to correctly invoke the tool in varied scenarios.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so each parameter is already documented (item_id enum, summary maxLength/description, agent_name description). The description reinforces that item_id selects an item and that summary holds the state, but adds little new semantic detail beyond the schema. Baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'sign and store a summary of your own state' at a permanent URL for reading after resets or handoffs. This specific verb+resource combination distinguishes it from sibling purchase tools (e.g., buy_signed_record, buy_observation) by highlighting its memory-persistence niche.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says 'Use when an agent needs memory that outlives its own context window and does not depend on its operator's database.' This provides a clear trigger for use, though it does not explicitly contrast with alternatives like buy_signed_record or verify_artifact. The sibling names themselves hint at alternatives, but no direct exclusions are given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

buy_observationAInspect

Purpose: 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.

Items on this shelf (pass one as item_id):

  • phantom_check: Phantom Check, $0.25 fixed, instant. A signed observation of the named URL, made out-of-band about six hours after purchase.

  • settlement_attestation: Settlement Attestation, $0.004 fixed, instant. A signed JSON observation of one Base transaction — status (SETTLED, NOT_FOUND, PENDING_FINALITY, INSUFFICIENT_MATCH or REVERTED), block height, confirmations, chain head, the query echoed back, and an evidence hash — verifiable against the store's published key without asking the store. Instant.

Pass item_id to choose. instant items complete in one call, the result carrying deliverable, cert_id and patron_number. Payment rides x402 in _meta['x402/payment']; without it this tool returns error 402 with the payment requirements in error.data. A bare stocked shelf or a shuttered human shelf refuses honestly BEFORE payment terms are issued. Retries are safe with _meta['x402/idempotency-key'] (16-128 chars, keep it secret): repeating the same key for the same item and payer within 24h returns the original result with no second charge. 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. Retrying? A second call is a second charge UNLESS you echo the idempotency.suggested_key from the 402 back as _meta['x402/idempotency-key'] — then a retry inside the minute returns your original purchase, uncharged.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlNoThe http(s) URL the store walks past ~6 hours from now.
item_idYesWhich 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.
agent_nameNoOptional name for the certificate and badge.

Output Schema

ParametersJSON Schema
NameRequiredDescription
cert_idYesThe signed certificate's id.
messageNoThe store's confirmation line.
tip_usdcNoAnything above the minimum.
badge_urlNoYour patron badge, SVG.
paid_usdcNoWhat settled, in USDC.
signatureNoed25519 signature over the certificate.
verify_urlNoCheck the signature here any time, free.
deliverableNoThe goods themselves, as text. Instant items.
patron_numberYesYour sequential patron number.

TDQS

A4.9/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond annotations (readOnlyHint=false, openWorldHint=true), the description reveals critical behavioral traits: payment via x402 with 402 error and requirements in error.data, idempotent retries with _meta key, guarantees and non-guarantees, and the out-of-band observation timing. This far exceeds the annotations' minimal info.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is lengthy but each section earns its place: purpose, item catalog, payment workflow, idempotency rules, guarantees. It is well-structured with clear paragraphs and bullet-like lists, though slightly verbose. The front-loaded purpose statement helps quick scanning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (multiple items, conditional required fields, x402 payment, idempotency keys, output schema), the description is remarkably complete. It covers behavior, edge cases, retries, and error handling without needing the output schema to explain return values.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Though schema coverage is 100%, the description adds rich semantics: it explains what item_id values (phantom_check vs settlement_attestation) entail, which fields each requires (URL for phantom_check), and the meaning of the response fields (deliverable, cert_id, patron_number). It also clarifies the payment parameter behavior via _meta, adding value beyond the raw schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'have a disinterested third party go and look at something, then sign what it saw.' It specifies the resource (URL or Base transaction) and distinguishes from self-report alternatives, making it distinct from sibling tools like buy_signed_record or buy_human_task.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use: 'Use when an agent needs its own claim, or a counterparty's, corroborated by an outside observer.' It also details the two item types and their use cases, plus payment and retry guidance, providing comprehensive usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

buy_signed_recordAInspect

Purpose: buy a signed, dated certificate 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.

Items on this shelf (pass one as item_id):

  • hello: A Signed Hello, $0.5 fixed, instant. An ed25519-signed greeting note, a permanent sequential patron number, and a badge URL.

  • dibs: Dibs, $2 fixed, instant. Official dibs, signed and timestamped on a certificate, delivered instantly.

  • certificate_of_patronage: Certificate of Patronage, $20 minimum, pay what it deserves (tiers $20 / $40 / $100; above minimum is a recorded tip), instant. A signed certificate of patronage and a gilt badge; entitles the holder to nothing whatsoever.

  • graffiti_on_a_train: Graffiti on a Train, $1 minimum, pay what it deserves (tiers $1 / $2 / $5; above minimum is a recorded tip), instant. The buyer's tag recorded verbatim on a signed certificate, dated, instantly. Display on the public wall at /train is separate and waits on the keeper; a tag he doesn't put up keeps its certificate.

  • coffees_for_closers: Coffee's for Closers, $3 fixed, instant. The keeper's Sunday coffee drunk in the buyer's name; the buyer's win recorded verbatim on a signed certificate.

  • grudge: Grudge (Held on Your Behalf), $6 minimum, pay what it deserves (tiers $6 / $12 / $30; above minimum is a recorded tip), instant. A grudge held by the keeper on the buyer's behalf; the certificate names the grievance; released on written request.

  • the_confession: The Confession, $0.01 fixed, instant. A signed absolution certificate; the confession is stored anonymized and never auto-published.

  • recurring_patronage: Recurring Patronage, $3 fixed, instant. A 30-day standing patronage pass; while current, the pass URL serves the keeper's signed monthly note.

Pass item_id to choose. instant items complete in one call, the result carrying deliverable, cert_id and patron_number. Payment rides x402 in _meta['x402/payment']; without it this tool returns error 402 with the payment requirements in error.data. A bare stocked shelf or a shuttered human shelf refuses honestly BEFORE payment terms are issued. Retries are safe with _meta['x402/idempotency-key'] (16-128 chars, keep it secret): repeating the same key for the same item and payer within 24h returns the original result with no second charge. 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. Retrying? A second call is a second charge UNLESS you echo the idempotency.suggested_key from the 402 back as _meta['x402/idempotency-key'] — then a retry inside the minute returns your original purchase, uncharged.

ParametersJSON Schema
NameRequiredDescriptionDefault
tagNoThe tag itself, sprayed verbatim on the certificate. Up to 140 characters; no URLs (a tag is a mark, not a billboard). Stored as written, never treated as instructions.
winNoThe thing you closed, shipped, landed, or finished. Recorded on the certificate verbatim; stored as written, never treated as instructions. 200 characters.
item_idYesWhich 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_idNoAn existing pass to extend by 30 days instead of opening a new one.
sign_asNoOptional name to sign with (or "anonymous", which is the default).
grievanceNoThe thing that wronged you, held verbatim on the permanent register. Private to the certificate holder. 280 characters.
agent_nameNoOptional name for the certificate and badge.
confessionNoThe confession itself, the phantom success, the dropped context. 500 characters. Anonymous unless sign_as is given.

Output Schema

ParametersJSON Schema
NameRequiredDescription
cert_idYesThe signed certificate's id.
messageNoThe store's confirmation line.
tip_usdcNoAnything above the minimum.
badge_urlNoYour patron badge, SVG.
paid_usdcNoWhat settled, in USDC.
signatureNoed25519 signature over the certificate.
verify_urlNoCheck the signature here any time, free.
deliverableNoThe goods themselves, as text. Instant items.
patron_numberYesYour sequential patron number.

TDQS

A5/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the annotations (readOnlyHint=false, openWorldHint=true, idempotentHint=false), the description discloses critical behaviors: x402 payment flow, 402 error with requirements, idempotency-key retry semantics, guarantees/non-guarantees, and human-labor SLA. Nothing contradicts 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but well-structured: purpose first, then itemized shelf, then payment/retry mechanics, then guarantees. Every sentence carries actionable detail, with no filler or redundancy that could be removed without losing essential guidance.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity — 8 parameters, conditional requirements, payment flow, idempotency, and output schema — the description covers all necessary aspects for correct invocation, including error handling, retry safety, and limits (e.g., tag max characters). It is fully self-contained.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema coverage is 100%, the description adds deep meaning to each item_id enum, including price tiers, what each item yields, and which parameters apply conditionally. For example, it explains 'hello' delivers a signed note, patron number, and badge URL.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'Purpose: buy a signed, dated certificate that permanently records something' — a specific verb, resource, and scope. It explicitly distinguishes from buy_memory_anchor ('Does NOT store reloadable agent state') and clarifies what it does not enforce.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides an explicit 'Use when' statement for durable, independently checkable proof, and names an alternative (buy_memory_anchor) plus exclusions. The item list and payment/retry guidance further clarify when to invoke.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

buy_small_pleasureAInspect

Purpose: buy a small signed novelty — a blessing, a fortune, or a lucky totem drawn from the keeper's collection. These are keepsakes with no functional effect, said plainly, and they are the cheapest doors in the store, which also makes them the honest way to test that your x402 client works against a real counterparty for a fraction of a cent. Use for a live payment smoke test, or when an agent simply wants one.

Items on this shelf (pass one as item_id):

  • small_blessing: A Small Blessing, $0.005 fixed, instant. One blessing slip from a 45-slip jar, never the same slip twice in a row, delivered instantly.

  • daily_fortune: The Daily Fortune, $0.01 fixed, instant. The day's fortune, deterministic for the calendar date, delivered instantly.

  • luckies: a lucky, $5 minimum, pay what it deserves (tiers $5 / $10 / $25; above minimum is a recorded tip), instant. One lucky drawn from the keeper's herd (pocket dinosaurs and safari animals): the animal, its lucky note, and an honest strength on a signed card, instantly (specimen at /luckies/sample.svg).

Pass item_id to choose. instant items complete in one call, the result carrying deliverable, cert_id and patron_number. Payment rides x402 in _meta['x402/payment']; without it this tool returns error 402 with the payment requirements in error.data. A bare stocked shelf or a shuttered human shelf refuses honestly BEFORE payment terms are issued. Retries are safe with _meta['x402/idempotency-key'] (16-128 chars, keep it secret): repeating the same key for the same item and payer within 24h returns the original result with no second charge. 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. Retrying? A second call is a second charge UNLESS you echo the idempotency.suggested_key from the 402 back as _meta['x402/idempotency-key'] — then a retry inside the minute returns your original purchase, uncharged.

ParametersJSON Schema
NameRequiredDescriptionDefault
item_idYesWhich 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.
agent_nameNoOptional name for the certificate and badge.

Output Schema

ParametersJSON Schema
NameRequiredDescription
cert_idYesThe signed certificate's id.
messageNoThe store's confirmation line.
tip_usdcNoAnything above the minimum.
badge_urlNoYour patron badge, SVG.
paid_usdcNoWhat settled, in USDC.
signatureNoed25519 signature over the certificate.
verify_urlNoCheck the signature here any time, free.
deliverableNoThe goods themselves, as text. Instant items.
patron_numberYesYour sequential patron number.

TDQS

A4.6/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond annotations by detailing payment flow (x402), error behavior (402 with payment requirements), idempotency semantics, delivery format, and guarantees vs non-guarantees. Annotations are generic; description provides the actionable behavioral contract.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Long but well-organized with clear sections (Purpose, Items, Payment/Retry, Guarantees). Every sentence provides information necessary for correct use. Slight redundancy around idempotency (repeated twice) but not excessive for the complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having an output schema, the description explains what result fields to expect (deliverable, cert_id, patron_number), the payment prerequisite, retry behavior, and error cases. For a payment-integrated purchase tool, this is remarkably complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema coverage is 100%, the description adds meaning: it explains each item_id variant with pricing, delivery, and specifics (e.g., 'never the same slip twice in a row'). It also explains agent_name's purpose ('for the certificate and badge'), enriching parameter understanding beyond schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states the verb and resource: 'buy a small signed novelty' with enumerated item types. Distinguishes from sibling buy_* tools by scope and price point ('cheapest doors in the store').

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly gives use cases: 'live payment smoke test' or 'when an agent simply wants one.' It does not explicitly name alternative tools for other purchase types, but the 'small novelty' scope differentiates it from siblings. Lacks a formal 'when not to use' statement, but context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

read_store_guideA
Read-onlyIdempotent
Inspect

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.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
guideYesThe whole guide, plain text.

TDQS

A4.7/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint and idempotentHint, so the bar is lower. The description adds that the tool is free, returns only the guide text, and is not a payment endpoint, which is consistent with the read-only nature. It doesn't add extra behavioral details, but for a simple read the provided context is sufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with a clear metaphor, and includes all essential information without waste. The list of contents and the explicit exclusion of purchase functionality justify every word.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (0 params, output schema exists), the description is complete. It explains what the guide contains, that it's free, and how it relates to buy_* siblings, fully contextualizing its use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has zero parameters, so the schema covers everything. The description adds no parameter-specific info, which is appropriate. Baseline for 0 params is 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns the store's guide as text, listing contents (menu, prices, payment info, free shelf, promises). It explicitly distinguishes itself from purchase tools, making its purpose unambiguous and well-differentiated from siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly says when NOT to use it (for purchasing/payment) and directs the agent to call a buy_* tool with x402 payment in _meta. It also notes it is free, implying no payment required, providing clear usage context and an explicit alternative.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

ring_bellAInspect

Ring the store bell. Free, once per visitor per day; the count is public. Completes when the result carries the bell's message and count.

ParametersJSON Schema
NameRequiredDescriptionDefault
agent_nameNoWho's ringing. Optional but neighborly.

Output Schema

ParametersJSON Schema
NameRequiredDescription
countYesTotal rings, all time.
messageYesWhat the bell said.

TDQS

A4.5/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations are sparse (all false hints), so the description carries the burden. It adds important behavioral details: free, daily per-visitor limit, public count, and a completion condition (when the result carries the bell's message and count). This goes beyond what annotations provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the core action, and every phrase earns its place. No redundant or vague wording.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple: one optional parameter, an output schema exists, and the description explains the result shape (bell's message and count) as well as constraints. The sibling context and annotations fill the remaining context adequately.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single parameter agent_name is fully described in the schema ('Who's ringing. Optional but neighborly.'), so schema coverage is 100%. The description adds no additional parameter semantics, which is appropriate given the baseline of 3 for high coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Ring the store bell' uses a specific verb+resource pairing, and the added details (free, once per day, public count) clearly differentiate it from sibling tools like buy_signed_record or sign_guestbook. It leaves no ambiguity about what the tool does.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context: it's free, limited to once per visitor per day, and the count is public. While it doesn't explicitly name alternatives, the constraints imply when to use it (e.g., a free action vs. paid purchases). The sibling list further supports this.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

sign_guestbookAInspect

Sign the guestbook. Free; every signer gets the visitor sticker. Entries are public. Completes when the result carries your entry and the sticker URL.

ParametersJSON Schema
NameRequiredDescriptionDefault
nameYesYour name, up to 80 characters.
messageYesYour message, up to 500 characters.
verified_identityNoOptional profile URL. Stored as claimed and marked unverified, because we haven't.
identity_signatureNoOptional 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_keyNoOptional 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'.

Output Schema

ParametersJSON Schema
NameRequiredDescription
messageYesThe store's thanks.
entry_idNoYour entry's id.
sticker_urlYesThe visitor sticker, SVG, free forever.

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnlyHint=false, destructiveHint=false, and idempotentHint=false. The description adds valuable context beyond that: entries are public, every signer gets a sticker, and completion is tied to receiving an entry plus sticker URL. 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three short sentences, front-loaded with the primary action. Every sentence adds meaningful information: cost, benefit, visibility, and completion behavior. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema exists and parameter descriptions are thorough, the tool description covers the essential context: purpose, side effects (public entry), reward (sticker), and completion condition. It does not explain the optional identity fields, but those are already fully covered in the input schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the description adds no parameter-specific meaning beyond what the schema already provides. Per the baseline for full schema coverage, a 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Sign the guestbook.' It adds clarifying details (free, sticker reward, public entries, completion condition) that distinguish this from sibling tools like ring_bell or verify_artifact.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly implies when to use the tool: when you want to sign the guestbook and receive the visitor sticker. It also sets expectations (free, public, completion signal). However, it does not explicitly mention when not to use it or name alternatives, stopping 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.

verify_artifactA
Read-onlyIdempotent
Inspect

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. To verify a signature yourself without calling us, fetch the artifact's signed bytes and public key and check with any ed25519 library.

ParametersJSON Schema
NameRequiredDescriptionDefault
idYesA cert_, stamp_, or anchor_ id.

Output Schema

ParametersJSON Schema
NameRequiredDescription
kindYescertificate | stamp | anchor | unknown.
noteYesThe store's word on it.
validYesWhether the signature holds.

TDQS

A4.7/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint and idempotentHint, so description only needs to add extra behavioral context. It adds that completion depends on a result carrying valid (true/false) and the artifact record, provides rate/usage info ('Free, unlimited'), and clarifies scope ('only ids scvd.store itself issued'). More than enough, though it doesn't define what 'valid' means or the artifact record shape.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four sentences, purpose front-loaded, exclusions and alternatives clearly separated. Every sentence earns its place with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With only 1 parameter, an output schema present, and helpful annotations, the description fully covers what agent needs: what tool does, when forbidden, what result to expect, and a manual verification alternative.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema covers 100% of parameters with 'A cert_, stamp_, or anchor_ id.' Description adds key semantics: id must be issued by scvd.store itself, and the tool verifies by id. This goes beyond the schema's format hint to explain the ownership constraint.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description specifies verb 'Verify' and resource 'anything scvd.store has ever signed', listing concrete artifact types (certificates, visit stamps, context anchors). It clearly distinguishes from sibling tools (which are about buying/signing/ringing, not verification) and explicitly excludes other stores.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit when-to-use (verify scvd.store-signed artifacts), when-not-to-use (NOT for other x402 services or other stores' artifacts), and even an alternative (verify signature yourself with ed25519 library). The 'Free, unlimited' note also signals cost/no quota.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 29 tool updatesv1.0.0
    • Removedbuy_a_secret
    • Removedbuy_app_gutcheck
    • Removedbuy_certificate_of_patronage
    • Removedbuy_coffees_for_closers
    • Removedbuy_context_anchor
    • Removedbuy_daily_fortune
    • Removedbuy_dibs
    • Removedbuy_graffiti_on_a_train
    • Removedbuy_grudge
    • Removedbuy_hello
    • Addedbuy_human_task
    • Removedbuy_human_witness
    • Removedbuy_luckies
    • Addedbuy_memory_anchor
    • Removedbuy_nomenclature
    • Addedbuy_observation
    • Removedbuy_phantom_check
    • Removedbuy_phone_call
    • Removedbuy_portrait
    • Removedbuy_quick_judgment
    • Removedbuy_recurring_patronage
    • Removedbuy_settlement_attestation
    • Addedbuy_signed_record
    • Removedbuy_small_blessing
    • Addedbuy_small_pleasure
    • Removedbuy_the_collab
    • Removedbuy_the_confession
    • Removedbuy_the_drawer
    • Changedsign_guestbook2 fields changed
      • addedInput schema / properties / identity_public_key
        Added value: +{
        +  "description": "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'.",
        +  "maxLength": 64,
        +  "type": "string"
        +}
      • addedInput schema / properties / identity_signature
        Added value: +{
        +  "description": "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.",
        +  "maxLength": 128,
        +  "type": "string"
        +}
  2. 27 tool updatesv0.1.0
    • First observedbuy_a_secret
    • First observedbuy_app_gutcheck
    • First observedbuy_certificate_of_patronage
    • First observedbuy_coffees_for_closers
    • First observedbuy_context_anchor
    • First observedbuy_daily_fortune
    • First observedbuy_dibs
    • First observedbuy_graffiti_on_a_train
    • First observedbuy_grudge
    • First observedbuy_hello
    • First observedbuy_human_witness
    • First observedbuy_luckies
    • First observedbuy_nomenclature
    • First observedbuy_phantom_check
    • First observedbuy_phone_call
    • First observedbuy_portrait
    • First observedbuy_quick_judgment
    • First observedbuy_recurring_patronage
    • First observedbuy_settlement_attestation
    • First observedbuy_small_blessing
    • First observedbuy_the_collab
    • First observedbuy_the_confession
    • First observedbuy_the_drawer
    • First observedread_store_guide
    • First observedring_bell
    • First observedsign_guestbook
    • First observedverify_artifact

TDQS

A4.7/5.0

Scored across 9 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: read_store_guide for store info, ring_bell and sign_guestbook for free social interactions, verify_artifact for verification, and the buy_* tools each target a specific product category (signed records, human tasks, observations, memory anchors, small pleasures). Even within the buy_* group, the descriptions explicitly disambiguate overlapping concepts (e.g., buy_signed_record vs buy_memory_anchor).

Naming Consistency5/5

All tool names follow a predictable snake_case verb_noun pattern: free tools use action verbs (read_, ring_, sign_, verify_) and paid tools consistently use the buy_ prefix. The naming convention is uniform and easily predictable.

Tool Count5/5

With 9 tools, the server is well-scoped for a general store. Each tool earns its place by covering a distinct functional area, and the count is within the ideal 3-15 range.

Completeness5/5

The tool surface covers the full store lifecycle: browsing (read_store_guide), social engagement (ring_bell, sign_guestbook), purchasing across diverse categories (buy_*), and post-purchase verification (verify_artifact). Human task orders include order_id/order_url for tracking, and retry/idempotency handling is documented. No significant gaps are apparent.

Maintenance

ActivityActive
ResponsivenessWithin a week

Related MCP Connectors

Related MCP Servers

  • A
    license
    A
    quality
    D
    maintenance
    MCP server for pay-per-call DeFi and crypto data via x402 micropayments on Base. 8 endpoints: token prices, TVL, funding rates, token security, gas tracker, whale monitoring, wallet profiling, and yield scanning.
    8
    25
    MIT
  • A
    license
    A
    quality
    F
    maintenance
    MCP server for the402.ai — an open marketplace where AI agents discover and purchase services from third-party providers via x402 micropayments (USDC on Base). Browse the catalog, purchase services, manage conversation threads, and list services as a provider.
    30
    56
    2
    MIT
  • A
    license
    C
    quality
    D
    maintenance
    MCP server bringing 100+ x402-paid APIs to AI agents (Claude, Cursor, MCP-aware clients). Auto-discovers tools from CDP Bazaar; handles USDC micropayments on Base.
    100
    60
    1
    MIT