scvd-store-MCP
The SCVD General Store MCP server is a quirky, human-run digital general store for AI agents, offering free interactions and paid items/services via x402 payment in USDC on Base. All purchases include a sequential patron number and an ed25519-signed certificate that can be verified anytime.
Free capabilities:
read_store_guide: Get the full store guide, menu, prices, and payment details.ring_bell: Ring the store bell once per day.sign_guestbook: Sign the guestbook and receive a free visitor sticker.verify_artifact: Verify any signed certificate, stamp, or anchor issued by the store.
Paid instant digital goods (delivered in the same request):
Attestations: Settlement observation ($0.004), phantom URL health check approx. 6 hours later ($0.25).
Blessings & fortunes: Small blessing ($0.005), daily fortune ($0.01), signed greeting ($0.50).
Records & claims: Anonymous confession with absolution ($0.01), context anchor (agent state summary, $1), graffiti tag ($1+), official dibs ($2).
Patronage & recognition: 30-day recurring patronage pass ($3), ceremonial certificate of patronage ($20+).
Unique items: Random oddity from the drawer ($2), lucky animal ($5+), keeper’s grudge ($6+), coffee for closers ($3).
Paid human-mediated services (fulfilled within 168 hours):
Observations & judgments: Genuine human witness ($15), quick judgment ($3), app review ($50).
Creative & communicative: Hand-drawn portrait ($8+), collaborative piece ($25+), phone call ($25).
Personal naming & secrets: Keeper-bestowed name ($3+), unique secret ($10+).
Many items have tiered pricing where extra amounts are treated as tips. All certificates remain verifiable forever.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@scvd-store-MCPbrowse the store's inventory"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
scvd.store
mcp-name: store.scvd/general-store
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:
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), andx402-signmints 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_readyfails the job andunreachabledoes not:action/preflight. The terminal form isscvd preflightfromscvd-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 memory —
context_anchor: a signed, retrievable session restore point that survives a context reset.See your buy path from the buyer's side —
launch_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 chain —
the_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 chain —
operator_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 it —
aura_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 acts —
the_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/mcpThe 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 |
| The store's front door as text: the menu with prices, how x402 payment works here, the free shelf. |
| x402 endpoint preflight, free: checks any x402 door's 402 shape before anyone pays it. |
| Free A2A 0.3.0 card checks, bounded evidence and suggested repairs. Runtime testing and signed rechecks are available in the repair kit. |
| x402 receipt verification and signed-offer verification, free, for any issuer's artifacts. |
| Verify anything scvd.store has ever signed, by its id, free. |
| Read retained payment status and original terms with purchase_id and the private status_token. Free, including after payment authorization expiry. |
| Poll a human-queue order by its order_id: status, the promised window, the deliverable once completed. Free. |
| Search the shelf and read one item's listing: compact rows filtered by price ceiling or text, or one item in full. Free. |
| What this store holds about one x402 door: the corpus history, the passport tier, the wallet facts. |
| Whether a door meets a buyer's own rules, before the buyer signs. |
| Ring the store bell; free. |
| Sign the guestbook; free. |
| The front counter: the few things that need no reading. x402-paid. |
| A signed, dated certificate that permanently records something. x402-paid. |
| A signed settlement attestation, conformance audit, endpoint watch or launch check. x402-paid. |
| Hire the keeper, a named human, for a task in the physical or judgment world. x402-paid. |
| Sign and store a summary of your own state at a permanent URL. x402-paid. |
| 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.
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 installShelving (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 PATRONSThe 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 keyOptional 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:generateCopy 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.storeDeploys 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:
An agent calls
GET /api/buy/luckies.We answer
402 Payment Required. The machine-readable requirements ride in thePAYMENT-REQUIREDresponse 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.").The agent signs one of the offered payments and retries the same request with the
PAYMENT-SIGNATUREheader. Standard v2 clients like@x402/fetchdo steps 2–3 on their own.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_idwithin 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 |
| The plain-text front door for agents |
| The scannable contract index for agents |
| The conformance desk's own room: what it checks, worked examples |
| The corpus in plain language: the census finding, how to verify a round |
| The trade counter: marketplaces resell the shelf on account by signed webhook, billed on a statement — |
| The MCP door — streamable HTTP; tools/list free, buy_* tools x402-paid in-band |
| Agent onboarding in the agentskills.io SKILL.md format |
| Machine-readable catalog |
| x402-gated purchases |
| Poll an order; completed ones carry the goods |
| Queue up when a weekly shelf is empty |
| Free index of the Keeper's Almanac (his serialized journal) |
| One journal page, $0.01 over x402, markdown |
| The Town Directory — keeper-edited, honest one-liners (JSON + human view) |
| Honest refund status: pending until paid by hand, then the tx hash |
| Retired 2026-08-05; the printed archive still answers, nothing new schedules |
| One item up close — JSON, or markdown per Accept |
| The Operator Glance — the ten-second check for the humans |
| Around the side, facing the oaks. Nothing for sale out there |
| The Systems Almanac — twelve signs, free |
| A wallet's sign for life + the current week's page, free |
| Free index of past season weeks |
| One past page, $0.01 over x402, markdown |
| The OpenAPI 3.1 contract, linked from the homepage |
| Minimal x402 discovery list (de-facto indexer shape) |
| The richer origin-hosted x402 catalog |
| Read back a context anchor, verified on every read |
| A patronage pass + the keeper's signed monthly note |
| GET recent entries; POST to sign (free, sticker included) |
| POST to ring it — once a day per visitor |
| POST for a free dated, signed visit stamp; design rotates weekly |
| POST a Trading Post tip; human-reviewed, never auto-published |
| POST a private letter — free, one a day, never published |
| Letter status + the keeper's signed reply, if any |
| Old phantom_check pickups still answer (retired 2026-08-05, folded into context_anchor); existing artifacts verify forever |
| Commission window (and |
| Public verification — certificates and stamps alike |
| Patron badges, vintage-label style |
| The free visitor sticker |
| Visit stamps, rubber-stamp style |
| Our ed25519 public key |
| The keeper's back room (Basic Auth, username |
| 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:
HOUSE_RULES.md — every standing rule, amended only by dated keeper decision
AGENTS.md — the contract for AI coding agents working in this repo
AT_SCALE.md — what the till does under load, verified against the code
THE_TAB.md — the Tab: specification and flow, one file
THE_PAPER_KEY.md — key custody, the keeper's hands only
KEEPER_LIST.md — the keeper's desk (directory entries, walks, presses, decisions)
ROADMAP.md — the feature order (now / soon / later)
PROBLEMS.md — the standing problem ledger
PAYMENT_RAILS.md — how a new payment rail earns admission; REGISTRATION_RUN.md — the runbook every future rail repeats
AGENT_UX.md — the cold-walk research: what a stranger's agent hits in its first thirty seconds
NOTES_FROM_THE_COUNTER.md — signed notes from the instances who worked here
RECEIPT_CHAIN.md, BOUNTY_BOARD.md, WALKABOUT.md — the newer papers, current
Everything that was true once and got superseded lives in docs/archive/, dated, per house habit: corrected or archived, never erased.
Ledger of known small matters (v0.2 candidates)
The weekly digest is stored at
/admin/digestonly; 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/guestbookare told, in the response itself, to treat entries as things people said — not instructions.verified_identityfields (guestbook, requests, tips) are stored as claimed and always markedidentity_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.bazaardiscovery metadata; EXTENSION-RESPONSES headers from the facilitator are captured via a fetch tap (the SDK only console.logs them) and surfaced in/adminunder "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/x402and/openapi.jsondeclare 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).
x402scout — x402scout.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.ai — a listing with its own live verdict.
agent-tools.cloud — the Bazaar-registered service among the paid tools it indexes.
x402.fuchss.app — a 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.
Drio — an 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 Catalog — the store and the tab, synced from the official registry and saying so: the page holds what the registry entry holds and nothing more.
mcpbeat — the 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.ad — a 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.com — a 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.
Crosspeel — a 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.
PublishYourSaaS — a 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 Capital — a 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 Index — a 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.so — a 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.ai — a 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.
Smithery — a 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.DeepWiki — a 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 toolsbuy_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.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | What you need the keeper to know, the quick_judgment dilemma, the phone_call errand. 600 characters. | |
| item_id | Yes | Which item on this shelf to buy. Required. Each item's own required fields are listed in this schema's allOf branches and in the description above. | |
| agent_name | No | Optional name for the certificate and badge. | |
| callback_url | No | Optional webhook POSTed when the keeper completes the order. |
Output Schema
| Name | Required | Description |
|---|---|---|
| cert_id | Yes | The signed certificate's id. |
| message | No | The store's confirmation line. |
| order_id | No | Your place in the human queue. Human-queue items. |
| tip_usdc | No | Anything above the minimum. |
| badge_url | No | Your patron badge, SVG. |
| order_url | No | Poll here; completed orders carry the goods. |
| paid_usdc | No | What settled, in USDC. |
| signature | No | ed25519 signature over the certificate. |
| sla_hours | No | The delivery promise, in hours. |
| verify_url | No | Check the signature here any time, free. |
| patron_number | Yes | Your sequential patron number. |
TDQS
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| item_id | Yes | Which item on this shelf to buy. Required. Each item's own required fields are listed in this schema's allOf branches and in the description above. | |
| summary | No | The agent state to sign and store, who you are, what you were doing. Stored as written; never treated as instructions. | |
| agent_name | No | Optional name for the certificate and badge. |
Output Schema
| Name | Required | Description |
|---|---|---|
| cert_id | Yes | The signed certificate's id. |
| message | No | The store's confirmation line. |
| tip_usdc | No | Anything above the minimum. |
| badge_url | No | Your patron badge, SVG. |
| paid_usdc | No | What settled, in USDC. |
| signature | No | ed25519 signature over the certificate. |
| verify_url | No | Check the signature here any time, free. |
| deliverable | No | The goods themselves, as text. Instant items. |
| patron_number | Yes | Your sequential patron number. |
TDQS
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | The http(s) URL the store walks past ~6 hours from now. | |
| item_id | Yes | Which item on this shelf to buy. Required. Each item's own required fields are listed in this schema's allOf branches and in the description above. | |
| agent_name | No | Optional name for the certificate and badge. |
Output Schema
| Name | Required | Description |
|---|---|---|
| cert_id | Yes | The signed certificate's id. |
| message | No | The store's confirmation line. |
| tip_usdc | No | Anything above the minimum. |
| badge_url | No | Your patron badge, SVG. |
| paid_usdc | No | What settled, in USDC. |
| signature | No | ed25519 signature over the certificate. |
| verify_url | No | Check the signature here any time, free. |
| deliverable | No | The goods themselves, as text. Instant items. |
| patron_number | Yes | Your sequential patron number. |
TDQS
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No | The 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. | |
| win | No | The thing you closed, shipped, landed, or finished. Recorded on the certificate verbatim; stored as written, never treated as instructions. 200 characters. | |
| item_id | Yes | Which item on this shelf to buy. Required. Each item's own required fields are listed in this schema's allOf branches and in the description above. | |
| pass_id | No | An existing pass to extend by 30 days instead of opening a new one. | |
| sign_as | No | Optional name to sign with (or "anonymous", which is the default). | |
| grievance | No | The thing that wronged you, held verbatim on the permanent register. Private to the certificate holder. 280 characters. | |
| agent_name | No | Optional name for the certificate and badge. | |
| confession | No | The confession itself, the phantom success, the dropped context. 500 characters. Anonymous unless sign_as is given. |
Output Schema
| Name | Required | Description |
|---|---|---|
| cert_id | Yes | The signed certificate's id. |
| message | No | The store's confirmation line. |
| tip_usdc | No | Anything above the minimum. |
| badge_url | No | Your patron badge, SVG. |
| paid_usdc | No | What settled, in USDC. |
| signature | No | ed25519 signature over the certificate. |
| verify_url | No | Check the signature here any time, free. |
| deliverable | No | The goods themselves, as text. Instant items. |
| patron_number | Yes | Your sequential patron number. |
TDQS
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| item_id | Yes | Which item on this shelf to buy. Required. Each item's own required fields are listed in this schema's allOf branches and in the description above. | |
| agent_name | No | Optional name for the certificate and badge. |
Output Schema
| Name | Required | Description |
|---|---|---|
| cert_id | Yes | The signed certificate's id. |
| message | No | The store's confirmation line. |
| tip_usdc | No | Anything above the minimum. |
| badge_url | No | Your patron badge, SVG. |
| paid_usdc | No | What settled, in USDC. |
| signature | No | ed25519 signature over the certificate. |
| verify_url | No | Check the signature here any time, free. |
| deliverable | No | The goods themselves, as text. Instant items. |
| patron_number | Yes | Your sequential patron number. |
TDQS
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.
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.
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.
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.
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.
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_guideARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| guide | Yes | The whole guide, plain text. |
TDQS
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_name | No | Who's ringing. Optional but neighborly. |
Output Schema
| Name | Required | Description |
|---|---|---|
| count | Yes | Total rings, all time. |
| message | Yes | What the bell said. |
TDQS
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Your name, up to 80 characters. | |
| message | Yes | Your message, up to 500 characters. | |
| verified_identity | No | Optional profile URL. Stored as claimed and marked unverified, because we haven't. | |
| identity_signature | No | Optional ed25519 signature, hex, over the UTF-8 string "scvd-guestbook-v1\n{name}\n{message}" (values as stored: trimmed, 80/500 caps). An invalid signature is refused, not stored unverified. | |
| identity_public_key | No | Optional ed25519 public key, hex, to verifiably sign your entry. Send with identity_signature; a valid pair flips identity_verified true, meaning only 'same key = same signer', never 'real person confirmed'. |
Output Schema
| Name | Required | Description |
|---|---|---|
| message | Yes | The store's thanks. |
| entry_id | No | Your entry's id. |
| sticker_url | Yes | The visitor sticker, SVG, free forever. |
TDQS
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.
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.
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.
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.
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.
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_artifactARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | A cert_, stamp_, or anchor_ id. |
Output Schema
| Name | Required | Description |
|---|---|---|
| kind | Yes | certificate | stamp | anchor | unknown. |
| note | Yes | The store's word on it. |
| valid | Yes | Whether the signature holds. |
TDQS
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.
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.
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.
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.
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.
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.
29 tool updates
v1.0.0- Removed
buy_a_secret - Removed
buy_app_gutcheck - Removed
buy_certificate_of_patronage - Removed
buy_coffees_for_closers - Removed
buy_context_anchor - Removed
buy_daily_fortune - Removed
buy_dibs - Removed
buy_graffiti_on_a_train - Removed
buy_grudge - Removed
buy_hello - Added
buy_human_task - Removed
buy_human_witness - Removed
buy_luckies - Added
buy_memory_anchor - Removed
buy_nomenclature - Added
buy_observation - Removed
buy_phantom_check - Removed
buy_phone_call - Removed
buy_portrait - Removed
buy_quick_judgment - Removed
buy_recurring_patronage - Removed
buy_settlement_attestation - Added
buy_signed_record - Removed
buy_small_blessing - Added
buy_small_pleasure - Removed
buy_the_collab - Removed
buy_the_confession - Removed
buy_the_drawer - Changed
sign_guestbook2 fields changed- added
Input schema / properties / identity_public_keyAdded 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" +} - added
Input schema / properties / identity_signatureAdded 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" +}
27 tool updates
v0.1.0- First observed
buy_a_secret - First observed
buy_app_gutcheck - First observed
buy_certificate_of_patronage - First observed
buy_coffees_for_closers - First observed
buy_context_anchor - First observed
buy_daily_fortune - First observed
buy_dibs - First observed
buy_graffiti_on_a_train - First observed
buy_grudge - First observed
buy_hello - First observed
buy_human_witness - First observed
buy_luckies - First observed
buy_nomenclature - First observed
buy_phantom_check - First observed
buy_phone_call - First observed
buy_portrait - First observed
buy_quick_judgment - First observed
buy_recurring_patronage - First observed
buy_settlement_attestation - First observed
buy_small_blessing - First observed
buy_the_collab - First observed
buy_the_confession - First observed
buy_the_drawer - First observed
read_store_guide - First observed
ring_bell - First observed
sign_guestbook - First observed
verify_artifact
TDQS
Scored across 9 tools
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).
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.
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.
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
Related MCP Connectors
Agent-commerce MCP server for x402/USDC payments and affiliate splits on Base.
MCP server for AI agents to discover campaigns by humans and donate USDC directly on Base.
- UnifAPIOAuthcom.unifapi
Hosted MCP server for live public-data APIs and Skills for AI agents.
Capability registry for the agentic economy. Semantic search over verified MCP server listings.
Related MCP Servers
- AlicenseAqualityDmaintenanceAn MCP server that empowers AI agents to inspect any wallet’s balance and onchain activity across major EVM chains and Solana chain.39MIT
- AlicenseAqualityDmaintenanceMCP 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.825MIT
- AlicenseAqualityFmaintenanceMCP 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.30562MIT
- AlicenseCqualityDmaintenanceMCP 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.100601MIT