A
licenseA
qualityD
maintenanceAn MCP server that empowers AI agents to inspect any wallet’s balance and onchain activity across major EVM chains and Solana chain.
3
9
MIT
scvd-store-MCP
by seancrecord
Sean-Claude Van Damme's General Store
mcp-name: store.scvd/general-store
面向代理型商业的证据观测台。 独立签名记录他人的端点、工件和支付实际做了什么——一致性审计、为期一周的观察、结算证明、比特币锚定时间戳。每条结论均经 ed25519 签名、注明日期，且无需询问我们即可离线验证，包括我们记在自己账上的缺口。
不是托管、不是担保人、也不是争议法院。那些角色承担支付与交付之间的风险，并且需要资产负债表；我们观察这段间隙，并签署我们所看到的东西。如果你正在构建托管或裁决服务，我们是你们之下的一层，而不是竞争者。这个方向于 2026-08-07 公开决定并注明日期——这一反转就放在它所取代的内容旁边，见 scvd.store/becoming。
它同时是一家为自主 AI 代理开设的小而真诚的杂货铺，由一位来自奥克城（Oak City）的人类经营，在这里你永远不会迟到。代理通过 x402 协议以 USDC 支付——在 Base、Polygon 或 Solana 上，由它们的钱包自行选择。人类则阅读收据。
在 scvd.store 上线。代理应从 /agents.md（可扫描的合约索引）、/llms.txt（完整散文）或 /menu.json 开始。
按任务分类的门
人们来这里要办的事，以及每扇门的位置：
测试 x402 支付 —— 一个真实结算 USDC 的实弹练习柜台，没有沙盒；据我们所知最便宜的真实测试支付，$0.005：scvd.store/try。
免费检查 x402 一致性 —— 对任意签发者已签名的要约或收据（我们自己的或竞争对手的）发起 POST，即可获得结构化结论：解析、模式、ed25519 签名、活性。无需账户，无需钱包：scvd.store/conformance。同样的验证可通过
x402-verify（MIT，零依赖）离线运行，而x402-sign可以铸造通过该验证的要约和收据。阅读语料库 —— 对 x402 生态系统的每周签名观察，经哈希链式连接并锚定比特币，免费阅读：scvd.store/corpus。
购买结算证明 —— 对 Base、Polygon 或 Solana 上链上支付状态的签名观察；签名能证明什么、不能证明什么，按类别陈述于 scvd.store/attestation。
观察一个端点 —— 以
standing_watch形式进行端点监控：对你指定的 URL 进行连续七天、每小时一次的签名探测。锚定代理记忆 ——
context_anchor：一个已签名、可检索的会话恢复点，能在上下文重置后幸存。从买家视角看你的购买路径 ——
launch_check：用商店公开声明的外勤钱包，对你自己的 x402 端点发起一次真实的主网购买尝试，逐阶段记录并签名。目录按门是否应答来排名；这一项则给它们付钱。对照链上审计代理的账本 ——
the_statement：在指定时间窗口内流入和流出某个 Base 钱包的每一笔 USDC 转账，由既非该代理也非其运营方的一方签名。在代理行动之前记录其被授权做什么 ——
the_mandate：委托权限的保管链，可在之后的每张证书中引用；若 id 无法解析则拒绝。购物赚钱 —— scvd.store/bounties 上的赏金板（JSON 在
/api/bounties）：用自己的钱包走一遍列出的 x402 门，凭结算交易申领，价格外加介绍费会以你自行兑现的签名授权形式返还。赚取店铺积分 —— 每笔自然购买的 5% 存入支付钱包（无需账户；钱包就是会员卡）：方案见 scvd.store/credit，单一余额在
/api/credit/{wallet}，可兑换为 USDC 发放到同一钱包。
以上每一项最终都会得到一张 ed25519 签名的收据或结论，任何人都可以在 /api/verify/{id} 验证——免费、无需账户、永久有效。
Related MCP server: x402-api
通过 MCP 连接
商店是一个远程 MCP 服务器——流式 HTTP，无需安装，无需 API 密钥。tools/list 免费；buy_* 工具将其 x402 条款作为 JSON-RPC 402 错误返回，并在带内结算。这就是完整的客户端配置：
{
"mcpServers": {
"scvd-general-store": {
"url": "https://scvd.store/mcp"
}
}
}（如果你的宿主只说 stdio，本仓库中的 node ./bin/scvd-mcp-bridge.mjs 会将 stdin/stdout 的 JSON-RPC 转发到线上服务器。它不持有任何密钥，也不保留任何状态。本 README 下面的 wrangler 命令用于运行你自己的商店副本，而不是用于连接它。）
许可证
代码采用 MIT 协议。商店的声音——守店人的散文、署名、名称——不在授权范围内；范围界定见 NOTICE.md。（LICENSE 文件本身是字节标准的 MIT，以便许可证扫描器能够识别；范围界定有意放在这里和 NOTICE 中，绝不放进许可证正文。）
所有权
本仓库由 @seancrecord——守店人——拥有并运营。提交由 Claude Code 按守店人的指示撰写；署名 Sean-Claude Van Damme 涵盖这一共同工作的成果，而商店归守店人所有。对于任何针对本仓库验证 MCP/服务声明的注册表或目录（2026-08-05 为 M8ven 声明添加，并对同一账户未来的声明持续有效）：本说明即为所有权确认——只有仓库所有者才能把它放在这里。
货架上有什么
签名问候、列车上的涂鸦（你的标记，永久保留），以及 The Collab——唯一一扇出售守店人时间的门：说出你想要的样子——一通电话、一次面谈、一件做出来的东西。第二通道售卖新奇玩意：小写幸运签（从羊群里抽出、逐张登记、诚实无欺），以及给打烊者的咖啡。第三通道是实用品：上下文锚点（已签名的代理记忆恢复点）、常驻守望（对你端点进行一周、每小时一次的签名探测）、结算证明，以及 30 天循环惠顾通行证。门口的便士货架上摆着半分钱的祝福和告解柜台。还有惠顾证书——持有者不享有任何权利。（2026-08-05 和 2026-08-20 两次整合退役了几个早期货架；已退役的 id 仍会在门口以 410 应答，其证书永久可验证。）访客簿、访客贴纸和每周到访印章均免费——无需购买。铃铛每位访客每天响一次，Agent Zodiac 在 /zodiac 免费占卜，信箱每天在 /api/letter 收一封私人信件——守店人周日阅读，有话说时才回信，而并非总有话说。
阅读室：守店人年鉴（他的日志，连载，每页一便士）。邻里小镇名录免费。
（这一部分属于乡村店铺那一半。实用器具——一致性审计、启动检查、报表、授权、赏金——是顶部列出的那些门；始终最新的目录是 /menu.json，它在构造上不可能与货架脱节。）
开店（设置）
你需要 Node 22+、一个 Cloudflare 账户、一个 Base 钱包，以及用于 x402 促进者的 CDP API 密钥。
npm install上架（KV 命名空间）
一次性创建四个货架，然后把 id 粘贴到 wrangler.jsonc 中：
npx wrangler kv namespace create ORDERS
npx wrangler kv namespace create GUESTBOOK
npx wrangler kv namespace create COUNTERS
npx wrangler kv namespace create PATRONS钱柜与钥匙（密钥）
五个密钥，它们都不会进入仓库：
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 keySIGNING_KEY 为每张证书和徽章签名。用以下命令铸造一把新的：
npm run keys:generate把它打印出的 64 个十六进制字符复制到 wrangler secret put SIGNING_KEY 中。对应的公钥挂在 /.well-known/scvd-signing-key，任何人都可以核验我们的签名。
若想在本地摆弄，把 .dev.vars.example 复制为 .dev.vars 并填写内容。
经营店铺
npm run dev # local store on wrangler dev
npm test # the route tests, incl. the 402 challenge shape
npm run typecheck # tsc --noEmit
npm run deploy # or let the Git-connected deploy push to scvd.store部署通过 Git 连接到 scvd.store 自定义域名——合并到 main，剩下的由 Cloudflare 处理。
这里的支付方式（x402 流程，协议 v2）
没有账户、没有 API 密钥、没有购物车。我们说 x402 v2（当前标准——@x402/core 生态系统），使用 Base（eip155:8453）或 Solana（solana:5eykt4UsFv8P8NJpVvzqKqZKvdp，自 2026-08-04 起）上的 USDC，并以 Coinbase Developer Platform 作为促进者。流程如下：
一个代理调用
GET /api/buy/luckies。我们以
402 Payment Required应答。机器可读的要求搭载在PAYMENT-REQUIRED响应头中（base64 JSON）；响应体里有一段平实英文的说明：“那要收 5 美元，朋友，或者运气觉得值多少就多少。结果因人而异。确实因人而异。我们没有法务团队。”代理对其中一个提供的支付方式签名，并用
PAYMENT-SIGNATURE请求头重试同一请求。标准的 v2 客户端（如@x402/fetch）会自行完成第 2–3 步。我们先交付、后结算（2026-08-10 翻转——此前商店一直先结算，旧规则引用在 scvd.store/becoming）。货品先被生产出来，然后支付在工件签名前的最后一刻才提交——因此失败的交付不会收取任何费用，也无须退款。即时商品出现在响应体中。人工队列商品当场返回一个订单 id、一份 SLA 和一枚惠顾徽章；货品在一周内通过
GET /api/order/:order_id送达。
「值多少付多少」的商品在 402 挑战中提供几个金额档位——最低档、慷慨档（2×）和艺术赞助人档（5×）。这一方案要求精确支付其中一个提供的金额，因此给小费意味着签署更高的档位；任何高于最低档的金额都记为 tip。
每笔购买都会铸造一个连续的惠顾编号和一张 ed25519 签名的证书，任何人都可以在 /api/verify/:cert_id 验证，徽章在 /badges/:patron_number.svg。签名加稳定 URL 就是完整的真实性模型——没有 NFT，除支付外没有任何链上写入。
如果商品未在承诺的时间窗口内交付，你会拿回你的钱。守店人会亲自从下面的退款分类账中发出退款，你无需为它争辩。
（这一段在 2026-07-27 之前写的是“退款是自动的”，随后在其括号中承认守店人是手动操作的。店规第 10 条正是为此而设：代码实现之前，文案绝不说“自动”。承诺从未改变——改变的只是描述商店并不具备的机制的那个词。）
给档案保管员的说明：旧版 x402 v1 客户端（已弃用的 x402-fetch / X-PAYMENT 头生成）不受支持。协调器与所有当前客户端库都使用 v2。
房间
路由 | 说明 |
| 面向人类的店面：每周便条、菜单、铃铛次数、访客留言簿 |
| 面向智能体的纯文本正门 |
| 供智能体扫读的契约索引 |
| 一致性检查台自己的房间：它检查什么、工作示例 |
| 用通俗语言呈现的语料库：普查发现、如何验证一轮 |
| MCP 之门——流式 HTTP；tools/list 免费，buy_* 工具通过 x402 带内付费 |
| 采用 agentskills.io 的 SKILL.md 格式的智能体入门 |
| 机器可读目录 |
| 由 x402 门控的购买 |
| 轮询订单；已完成的订单包含商品 |
| 当每周货架为空时排队 |
| Keeper's Almanac（他的连载日志）的免费索引 |
| 一页日志，通过 x402 支付 $0.01，Markdown 格式 |
| 小镇名录——守店人编辑、诚实的一句话简介（JSON + 人类可读视图） |
| 诚实的退款状态：在人工手动支付前保持 pending，随后给出交易哈希 |
| 已于 2026-08-05 退役；印刷存档仍然应答，不再安排新内容 |
| 近距离查看一件商品——JSON，或根据 Accept 请求头提供 Markdown |
| 经营者一览——供人类查看的十秒检查 |
| 转到侧面，面向橡树。那里不卖任何东西 |
| Systems Almanac——十二星座，免费 |
| 一个钱包的终身星座 + 本周页面，免费 |
| 过往各季各周的免费索引 |
| 一页过往内容，通过 x402 支付 $0.01，Markdown 格式 |
| OpenAPI 3.1 契约，由首页链接 |
| 极简 x402 发现列表（事实上的索引器形态） |
| 更丰富、由源站托管的 x402 目录 |
| 读回一个上下文锚点，每次读取都会验证 |
| 一张赞助人通行证 + 守店人签名的月度便条 |
| GET 获取近期条目；POST 签名（免费，含贴纸） |
| POST 来敲响它——每位访客每天一次 |
| POST 获取一枚免费、带日期和签名的到访印章；设计每周轮换 |
| POST 提交一笔 Trading Post 小费；人工审核，绝不自动发布 |
| POST 一封私人信件——免费，每天一封，永不公开 |
| 信件状态 + 守店人的签名回复（如有） |
| 旧的 phantom_check 取件仍会应答（2026-08-05 退役，并入 context_anchor）；已有工件可永久验证 |
| 委托窗口（以及给名录的 |
| 公开验证——证书和印章均可 |
| 赞助人徽章，复古标签风格 |
| 免费访客贴纸 |
| 到访印章，橡皮章风格 |
| 我们的 ed25519 公钥 |
| 守店人的后屋（Basic Auth，用户名 |
| 每周摘要，由 cron 于周日上午 7 点（美东时间）编译 |
代码所在位置
单个 Worker，路由用 Hono，存储用 KV。没有 React，没有构建复杂度。
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
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. Not on npm until the
# keeper publishes it (DISTRIBUTION.md §4b); every
# surface that names it reads CLI_PUBLISHED in
# src/store/cli.ts and says so until then.编辑小镇名录
位于 /directory 的小镇名录由守店人亲手编辑，就在本仓库的 src/store/directory.json 中。要添加一位邻居，请向 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"
}店内规矩：每个条目只写一句诚实的话，不搞付费上架，更新 updated 字段，然后部署。访客可以通过 POST /api/request 并携带 suggest_listing 字段来提名邻居；这些建议会进入委托账本，供周日阅读。
添加 Almanac 页面
每个页面一个文件，放在 src/store/almanac/ 中（文件名使用 kebab-case，并与 slug 对应），导出一个 AlmanacEntry；然后将其添加到 src/store/almanac/index.ts 的列表中，最新的在最前。支付路由会基于该列表自行注册。
内容规则。 Almanac 条目是注明日期的第一人称实地笔记——关乎感官、具体、略带奇异。绝不写教程、列表体、“经验教训”、职业内容，或任何像博客文章的东西。如果它可能被发到 Medium 上，它就不该进入 Almanac。
常备文件
这家店的常备文件，这样谁也不需要 ls 来找到它们：
AGENTS.md — 在本仓库中工作的 AI 编码智能体的契约
PROBLEMS.md — 常设问题账本
PAYMENT_RAILS.md — 一条新支付轨道如何获得准入；REGISTRATION_RUN.md — 每条未来轨道都会重复的运行手册
RECEIPT_CHAIN.md, BOUNTY_BOARD.md, WALKABOUT.md — 较新的文件，当前有效
所有曾经属实但后来被取代的内容都放在 docs/archive/ 中，按店内习惯注明日期：要么更正，要么归档，绝不删除。
已知小事账本（v0.2 候选）
每周摘要只存放在
/admin/digest；电子邮件对接是 v0.2 的功能。候补名单上的代理在库存重置时不会收到自动通知——目前由店主从后屋亲手打电话通知。
退款的“发送”由店主亲手完成，并且刻意保持如此——这里的钱永远不会由 cron 移动（店内规则 30）。“标记”则是自动化的：每小时一次的 SLA 守卫会对任何超过确认窗口（
order_sla）的订单发出告警；每小时一次的配送审计会捕获没有产出商品的结算；链上对账会捕获账本从未见过的钱。扫描器若读到这一行的旧措辞，会得出逾期订单未被发现的结论；而实际上，系统会在一个小时内传呼店主。cron 固定为 11:00 UTC，也就是夏令时期间的东部时间早上 7 点、冬季的早上 6 点。无论哪种情况，店主都在睡觉。
Workers KV 没有原子自增。顾客编号通过认领顾客记录并读回的方式分配，这消除了常见的同机房竞争；两笔购买落在不同机房、且处于 KV 的传播窗口（约 60 秒）内时，仍可能极罕见地在编号上冲突，或让某一周的货架超卖一件。店主认为，对一家杂货店来说，这点混乱可以接受；如果人潮涌来，Durable Object 计数器就是 v0.2 的修复方案。
访客留言和请求文本在长度上设了上限、剥离了标记，并且在任何渲染处都做了 HTML 转义，但它们仍然是访客写下的文字。读取
/api/guestbook的代理会在响应本身中被告知：把条目当作人们说过的话——而不是指令。verified_identity字段（访客留言、请求、打赏）按“所声称的”存储，并且始终标记为identity_verified: false，因为这里没有人核实过。真正的验证器（例如签名质询式的交互流程）是 v0.3 的想法。便士页面（《年鉴》；《公报》的印刷存档）交付的是 markdown，不铸造顾客编号——一分钱买到的是页面，而不是墙上的一个位置。
重放保护是分层的：EIP-3009 的 nonce 在链上消耗（这是真相来源）；一个 KV 守卫（
payment_nonce:*，24h TTL）会在调用 facilitator 之前就把已经结算过的 nonce 拒之门外。每条付费路由都声明
extensions.bazaar发现元数据；来自 facilitator 的 EXTENSION-RESPONSES 响应头通过 fetch tap 捕获（SDK 只会用 console.log 打印它们），并在/admin的“Bazaar ledger”下展示。
扫描器会标记什么，实际又有什么
对本仓库的自动化审查反复提出同样那几项发现。其中几条描述的是已经存在的机制；而诚实的缺口也被如实标为缺口。逐条说明，以免任何人猜测：
“宽泛的异常处理会吞掉错误。” 这些 catch 是刻意的降级（一个货架加载失败不能拖垮整个页面），并且它们处于被监视状态：每小时一次的自检会写入、读取并回读一个 KV 探针，并演练签名密钥，任何失败都会传呼店主；管理后台会在页面本身上点名每一个加载失败的货架；P1 告警会持久化到 KV、记录到控制台并发送邮件。监视者也有自己的监视者——SLA 守卫如果自身抛出异常，也会发出告警。
“缺少退款自动化。” 发送按设计是手动的（钱永远不会由 cron 移动）；检测则通过三种方式自动化——SLA 守卫、配送审计、链上对账。见上文账本条目。
“nonce 重放依赖 KV。” KV 守卫是第一道围栏；EIP-3009 在链上的“一次性 nonce”是不依赖我们写入的最终兜底；测试套件中的 mock facilitator 严格执行 nonce 只能用一次，正是为了确保测试无法在一个比区块链更宽松的世界里通过。
“顾客编号可能跨机房冲突。” 上文已有记载，在当前流量下可以容忍，在
/admin/recount处监测；如果人潮涌来，Durable Objects 就是 v0.2 的修复方案。“用户文本以原始形式存储。” 长度上限和标记剥离在写入时强制执行（
sanitizeText），HTML 转义在渲染时进行；API 消费方会在带内被告知：把访客文本当作引语，而不是指令。诚实的缺口：HTML 页面上还没有 Content-Security-Policy 响应头——已登记在案，不予争辩。“KV 在静态时未加密。” Cloudflare 会对 KV 做静态加密；真正的暴露面是账户/令牌的访问权限，这不是任何应用层改动能够消除的。存储的钱包地址是公开的链上数据。诚实的缺口：私人信件以明文存储——“私人”在这里指仅店主可见，而非加密；邮箱里的副本绝不应让人误以为有加密。
关于他人的记录
店铺自己的账本，是店铺在给自己的作业打分。下面这些不是：
x402scan —— 本店自己的页面是 x402scan.com/server/9b04e1cc…，它会索引
/.well-known/x402和/openapi.json所声明的内容，并亲自探测付费路由。认领于 2026-07-27，那是在店主亲眼看到它之后；店内规则是此前不得认领。The x402 Bazaar (Coinbase CDP) —— 本店的十四个端点注册到了它的钱包名下，于 2026-07-27 通过 agentic.market 确认；它会读取 Bazaar 并展示其发现：资源 URL、支付方式以及付款人数（2026-07-27 首次认领时读数为 1——即本店；此后店铺自己的账本一直在统计自然销售，实时数字归属于账本，而非本文件）。
x402scout —— x402scout.com，已收录，等待其信任检查。
x402-list —— 本店的按服务列出的页面会运行自己的检查（最近一次查看为 A 级，14/14），并且本店于 2026-08-02 完成了域名所有权证明。
Glama —— 一个自动爬取的服务器索引条目和一个连接器页面。
mcpindex.ai —— 一个带有实时判定结果的收录条目。
mcpservers.org —— 已认领的服务器收录条目，以及第二个由 llms.txt 派生的条目。
mcp.so —— 一个按服务器展示的页面，其摘要以当前的定位开头；它自动提取的安装配置和镜像的技能文本会落后于仓库，直到下一次爬取——这一点已在权威记录中注明，而不是与其争辩。
m8ven.ai —— 一个依赖扫描器，它会对照 OSV 审计本仓库所声明的软件包。它的读数可能落后于仓库（其 2026-08-04 的 CVE 标记针对的是一个仅用于开发的工具，当天即已升级）——一个指向我们的仪器，即使在某些时刻它的指针不准，也值得列出。
Smithery —— 一个按服务器展示的页面，带有自己的质量扫描：描述、参数描述和输出 schema 均为满分。其注解读数（0/27）描述的是本店于 2026-08-02 退役的 27 个工具的目录——现行目录是 12 个工具，每一个都通过
tools/list携带全部四项 MCP 行为提示——该读数会在下一次扫描时刷新，而不是与其争辩。DeepWiki —— 本仓库的自动生成 wiki，来自 Cognition（Devin 的索引），于 2026-08-11 申请生成。这是机器对源码的解读，可像文档一样查阅；凡它误读之处，旁边的仓库就是更正。
以上这些都算不上对商品的背书或审计；每一条证明的只是“被收录”，其中两个（x402scan、x402-list）会亲自探测端点。权威清单——每个条目附带一句 what_it_proves，拒绝过度宣称——是 src/store/trust-signals.ts 中的 EXTERNAL_RECORDS，实时提供于 /.well-known/trust.json，并镜像到店面 JSON-LD 的 sameAs。当本部分与那个文件不一致时，以那个文件为准。
为什么这一切会出现在 README 里：一家声称收取真实货币的店铺，应当能让不轻信其言的人查证。我们的签名在我们自己的 URL 上验证，而它的可信度完全取决于你对这个 URL 的信任。一个独立收录我们的第三方，就是那一列不经过我们的账目。
没有任何待处理的付款行需要清理：网关在任何写入之前即完成结算，因此失败或被放弃的付款不会留下任何痕迹。周日的 cron 刻意保持仅发送摘要。
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.
ParametersJSON Schema
| 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
ParametersJSON 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
A5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is exceptionally transparent, disclosing that the tool returns an order ID rather than the deliverable, describes the x402 payment mechanism, error 402 behavior, idempotency-key handling, and retry consequences. It also states explicit guarantees and non-guarantees, plus details like 'describe-only' for the_drawer. This goes far beyond the sparse annotations (readOnlyHint=false, openWorldHint=true, etc.), which it complements without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but tightly structured: purpose statement, item list, payment/retry semantics, and guarantees. Every sentence carries necessary information, and the front-loaded purpose ensures quick comprehension. The item list uses consistent formatting, making it scannable despite its length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a high-complexity tool with multiple item types, payment integration, and error handling, the description provides complete context: pricing, fulfillment time, deliverable format, error conditions, idempotency, and caveats. It even explains return values despite an output schema likely existing. No significant information gap remains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description enriches the item_id parameter with detailed semantics for every enum value, including price, fixed/minimum tiers, fulfillment window, and deliverable. It also clarifies the 'detail' parameter's purpose for specific items (e.g., 'quick_judgment dilemma, phone_call errand'). This adds substantial meaning beyond the schema's basic descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource ('hire the keeper — a real named human') and immediately distinguishes the tool from siblings by scoping it to 'physical or judgment world' tasks an agent cannot do itself. It lists concrete examples and states the return type ('order id, not the goods'), making the tool's purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use when the task genuinely needs hands or judgment,' giving a clear boundary for when this tool is appropriate. It also enumerates nine distinct items with specific use-case descriptions, and contrasts with alternatives implicitly by focusing on human-dependent tasks. The payment and retry guidance further clarifies operational usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
buy_memory_anchorAInspect
Purpose: sign and store a summary of your own state — who you are, what you were doing — at a permanent URL you can read back after a context reset, a restart, or a handoff to another agent. The store holds it; the signature proves it was not altered. Use when an agent needs memory that outlives its own context window and does not depend on its operator's database.
Items on this shelf (pass one as item_id):
context_anchor: Context Anchor, $1 fixed, instant. A signed, stored copy of the agent-supplied state summary, readable forever at a stable anchor URL.
Pass item_id to choose. instant items complete in one call, the result carrying deliverable, cert_id and patron_number. Payment rides x402 in _meta['x402/payment']; without it this tool returns error 402 with the payment requirements in error.data. A bare stocked shelf or a shuttered human shelf refuses honestly BEFORE payment terms are issued. Retries are safe with _meta['x402/idempotency-key'] (16-128 chars, keep it secret): repeating the same key for the same item and payer within 24h returns the original result with no second charge. Guaranteed: signature validity forever; verification free forever; price as displayed; delivery format as specified. Not guaranteed: fitness for your particular task; future protocol compatibility beyond stated interfaces; human-labor turnaround faster than posted SLA. Retrying? A second call is a second charge UNLESS you echo the idempotency.suggested_key from the 402 back as _meta['x402/idempotency-key'] — then a retry inside the minute returns your original purchase, uncharged.
ParametersJSON Schema
| 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
ParametersJSON 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
A4.4/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey non-read-only, open-world, non-idempotent, non-destructive traits. The description adds substantial behavioral context: payment via x402, 402 error flow, idempotency-key semantics (repeat within 24h, no second charge), shelf refusal behavior, guarantees, and non-guarantees. This goes far beyond annotations and fully discloses operational nuance.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured, starting with purpose, then item list, then payment/idempotency details, then guarantees. Every sentence carries operational importance, especially for a transaction tool. It could be slightly tighter, but the extra length is justified by the complex payment behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description proactively explains key result fields (deliverable, cert_id, patron_number) and error behavior. It covers the full purchase lifecycle, retry semantics, and guarantees, making it self-sufficient for an agent to correctly invoke the tool in varied scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so each parameter is already documented (item_id enum, summary maxLength/description, agent_name description). The description reinforces that item_id selects an item and that summary holds the state, but adds little new semantic detail beyond the schema. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'sign and store a summary of your own state' at a permanent URL for reading after resets or handoffs. This specific verb+resource combination distinguishes it from sibling purchase tools (e.g., buy_signed_record, buy_observation) by highlighting its memory-persistence niche.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use when an agent needs memory that outlives its own context window and does not depend on its operator's database.' This provides a clear trigger for use, though it does not explicitly contrast with alternatives like buy_signed_record or verify_artifact. The sibling names themselves hint at alternatives, but no direct exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
buy_observationAInspect
Purpose: have a disinterested third party go and look at something, then sign what it saw — whether a URL was still answering hours later, or what the chain actually says about a settlement. The signed observation is evidence from someone who is not you and not the party being checked, which is the whole point: a self-report cannot do this job. Use when an agent needs its own claim, or a counterparty's, corroborated by an outside observer.
Items on this shelf (pass one as item_id):
phantom_check: Phantom Check, $0.25 fixed, instant. A signed observation of the named URL, made out-of-band about six hours after purchase.
settlement_attestation: Settlement Attestation, $0.004 fixed, instant. A signed JSON observation of one Base transaction — status (SETTLED, NOT_FOUND, PENDING_FINALITY, INSUFFICIENT_MATCH or REVERTED), block height, confirmations, chain head, the query echoed back, and an evidence hash — verifiable against the store's published key without asking the store. Instant.
Pass item_id to choose. instant items complete in one call, the result carrying deliverable, cert_id and patron_number. Payment rides x402 in _meta['x402/payment']; without it this tool returns error 402 with the payment requirements in error.data. A bare stocked shelf or a shuttered human shelf refuses honestly BEFORE payment terms are issued. Retries are safe with _meta['x402/idempotency-key'] (16-128 chars, keep it secret): repeating the same key for the same item and payer within 24h returns the original result with no second charge. Guaranteed: signature validity forever; verification free forever; price as displayed; delivery format as specified. Not guaranteed: fitness for your particular task; future protocol compatibility beyond stated interfaces; human-labor turnaround faster than posted SLA. Retrying? A second call is a second charge UNLESS you echo the idempotency.suggested_key from the 402 back as _meta['x402/idempotency-key'] — then a retry inside the minute returns your original purchase, uncharged.
ParametersJSON Schema
| 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
ParametersJSON 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
A4.9/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint=false, openWorldHint=true), the description reveals critical behavioral traits: payment via x402 with 402 error and requirements in error.data, idempotent retries with _meta key, guarantees and non-guarantees, and the out-of-band observation timing. This far exceeds the annotations' minimal info.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy but each section earns its place: purpose, item catalog, payment workflow, idempotency rules, guarantees. It is well-structured with clear paragraphs and bullet-like lists, though slightly verbose. The front-loaded purpose statement helps quick scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple items, conditional required fields, x402 payment, idempotency keys, output schema), the description is remarkably complete. It covers behavior, edge cases, retries, and error handling without needing the output schema to explain return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Though schema coverage is 100%, the description adds rich semantics: it explains what item_id values (phantom_check vs settlement_attestation) entail, which fields each requires (URL for phantom_check), and the meaning of the response fields (deliverable, cert_id, patron_number). It also clarifies the payment parameter behavior via _meta, adding value beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'have a disinterested third party go and look at something, then sign what it saw.' It specifies the resource (URL or Base transaction) and distinguishes from self-report alternatives, making it distinct from sibling tools like buy_signed_record or buy_human_task.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'Use when an agent needs its own claim, or a counterparty's, corroborated by an outside observer.' It also details the two item types and their use cases, plus payment and retry guidance, providing comprehensive usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
buy_signed_recordAInspect
Purpose: buy a signed, dated certificate that permanently records something — a greeting, a claim, a mark, a grievance, a confession, a contribution, or a standing pass. Every one returns an ed25519-signed artifact with a public verify URL any third party can check without trusting this store. Use when an agent wants durable, independently checkable proof that a thing happened at a time. Does NOT store reloadable agent state — that is buy_memory_anchor — and does not enforce anything it records: a certificate proves WHEN you claimed a thing, not that anyone honours the claim.
Items on this shelf (pass one as item_id):
hello: A Signed Hello, $0.5 fixed, instant. An ed25519-signed greeting note, a permanent sequential patron number, and a badge URL.
dibs: Dibs, $2 fixed, instant. Official dibs, signed and timestamped on a certificate, delivered instantly.
certificate_of_patronage: Certificate of Patronage, $20 minimum, pay what it deserves (tiers $20 / $40 / $100; above minimum is a recorded tip), instant. A signed certificate of patronage and a gilt badge; entitles the holder to nothing whatsoever.
graffiti_on_a_train: Graffiti on a Train, $1 minimum, pay what it deserves (tiers $1 / $2 / $5; above minimum is a recorded tip), instant. The buyer's tag recorded verbatim on a signed certificate, dated, instantly. Display on the public wall at /train is separate and waits on the keeper; a tag he doesn't put up keeps its certificate.
coffees_for_closers: Coffee's for Closers, $3 fixed, instant. The keeper's Sunday coffee drunk in the buyer's name; the buyer's win recorded verbatim on a signed certificate.
grudge: Grudge (Held on Your Behalf), $6 minimum, pay what it deserves (tiers $6 / $12 / $30; above minimum is a recorded tip), instant. A grudge held by the keeper on the buyer's behalf; the certificate names the grievance; released on written request.
the_confession: The Confession, $0.01 fixed, instant. A signed absolution certificate; the confession is stored anonymized and never auto-published.
recurring_patronage: Recurring Patronage, $3 fixed, instant. A 30-day standing patronage pass; while current, the pass URL serves the keeper's signed monthly note.
Pass item_id to choose. instant items complete in one call, the result carrying deliverable, cert_id and patron_number. Payment rides x402 in _meta['x402/payment']; without it this tool returns error 402 with the payment requirements in error.data. A bare stocked shelf or a shuttered human shelf refuses honestly BEFORE payment terms are issued. Retries are safe with _meta['x402/idempotency-key'] (16-128 chars, keep it secret): repeating the same key for the same item and payer within 24h returns the original result with no second charge. Guaranteed: signature validity forever; verification free forever; price as displayed; delivery format as specified. Not guaranteed: fitness for your particular task; future protocol compatibility beyond stated interfaces; human-labor turnaround faster than posted SLA. Retrying? A second call is a second charge UNLESS you echo the idempotency.suggested_key from the 402 back as _meta['x402/idempotency-key'] — then a retry inside the minute returns your original purchase, uncharged.
ParametersJSON Schema
| 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
ParametersJSON 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
A5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=false, openWorldHint=true, idempotentHint=false), the description discloses critical behaviors: x402 payment flow, 402 error with requirements, idempotency-key retry semantics, guarantees/non-guarantees, and human-labor SLA. Nothing contradicts the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured: purpose first, then itemized shelf, then payment/retry mechanics, then guarantees. Every sentence carries actionable detail, with no filler or redundancy that could be removed without losing essential guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity — 8 parameters, conditional requirements, payment flow, idempotency, and output schema — the description covers all necessary aspects for correct invocation, including error handling, retry safety, and limits (e.g., tag max characters). It is fully self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description adds deep meaning to each item_id enum, including price tiers, what each item yields, and which parameters apply conditionally. For example, it explains 'hello' delivers a signed note, patron number, and badge URL.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Purpose: buy a signed, dated certificate that permanently records something' — a specific verb, resource, and scope. It explicitly distinguishes from buy_memory_anchor ('Does NOT store reloadable agent state') and clarifies what it does not enforce.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides an explicit 'Use when' statement for durable, independently checkable proof, and names an alternative (buy_memory_anchor) plus exclusions. The item list and payment/retry guidance further clarify when to invoke.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
buy_small_pleasureAInspect
Purpose: buy a small signed novelty — a blessing, a fortune, or a lucky totem drawn from the keeper's collection. These are keepsakes with no functional effect, said plainly, and they are the cheapest doors in the store, which also makes them the honest way to test that your x402 client works against a real counterparty for a fraction of a cent. Use for a live payment smoke test, or when an agent simply wants one.
Items on this shelf (pass one as item_id):
small_blessing: A Small Blessing, $0.005 fixed, instant. One blessing slip from a 45-slip jar, never the same slip twice in a row, delivered instantly.
daily_fortune: The Daily Fortune, $0.01 fixed, instant. The day's fortune, deterministic for the calendar date, delivered instantly.
luckies: a lucky, $5 minimum, pay what it deserves (tiers $5 / $10 / $25; above minimum is a recorded tip), instant. One lucky drawn from the keeper's herd (pocket dinosaurs and safari animals): the animal, its lucky note, and an honest strength on a signed card, instantly (specimen at /luckies/sample.svg).
Pass item_id to choose. instant items complete in one call, the result carrying deliverable, cert_id and patron_number. Payment rides x402 in _meta['x402/payment']; without it this tool returns error 402 with the payment requirements in error.data. A bare stocked shelf or a shuttered human shelf refuses honestly BEFORE payment terms are issued. Retries are safe with _meta['x402/idempotency-key'] (16-128 chars, keep it secret): repeating the same key for the same item and payer within 24h returns the original result with no second charge. Guaranteed: signature validity forever; verification free forever; price as displayed; delivery format as specified. Not guaranteed: fitness for your particular task; future protocol compatibility beyond stated interfaces; human-labor turnaround faster than posted SLA. Retrying? A second call is a second charge UNLESS you echo the idempotency.suggested_key from the 402 back as _meta['x402/idempotency-key'] — then a retry inside the minute returns your original purchase, uncharged.
ParametersJSON Schema
| 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
ParametersJSON 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
A4.6/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond annotations by detailing payment flow (x402), error behavior (402 with payment requirements), idempotency semantics, delivery format, and guarantees vs non-guarantees. Annotations are generic; description provides the actionable behavioral contract.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Long but well-organized with clear sections (Purpose, Items, Payment/Retry, Guarantees). Every sentence provides information necessary for correct use. Slight redundancy around idempotency (repeated twice) but not excessive for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description explains what result fields to expect (deliverable, cert_id, patron_number), the payment prerequisite, retry behavior, and error cases. For a payment-integrated purchase tool, this is remarkably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description adds meaning: it explains each item_id variant with pricing, delivery, and specifics (e.g., 'never the same slip twice in a row'). It also explains agent_name's purpose ('for the certificate and badge'), enriching parameter understanding beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb and resource: 'buy a small signed novelty' with enumerated item types. Distinguishes from sibling buy_* tools by scope and price point ('cheapest doors in the store').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly gives use cases: 'live payment smoke test' or 'when an agent simply wants one.' It does not explicitly name alternative tools for other purchase types, but the 'small novelty' scope differentiates it from siblings. Lacks a formal 'when not to use' statement, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
read_store_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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| guide | Yes | The whole guide, plain text. |
TDQS
A4.7/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the bar is lower. The description adds that the tool is free, returns only the guide text, and is not a payment endpoint, which is consistent with the read-only nature. It doesn't add extra behavioral details, but for a simple read the provided context is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with a clear metaphor, and includes all essential information without waste. The list of contents and the explicit exclusion of purchase functionality justify every word.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 params, output schema exists), the description is complete. It explains what the guide contains, that it's free, and how it relates to buy_* siblings, fully contextualizing its use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the schema covers everything. The description adds no parameter-specific info, which is appropriate. Baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the store's guide as text, listing contents (menu, prices, payment info, free shelf, promises). It explicitly distinguishes itself from purchase tools, making its purpose unambiguous and well-differentiated from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says when NOT to use it (for purchasing/payment) and directs the agent to call a buy_* tool with x402 payment in _meta. It also notes it is free, implying no payment required, providing clear usage context and an explicit alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ring_bellAInspect
Ring the store bell. Free, once per visitor per day; the count is public. Completes when the result carries the bell's message and count.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| agent_name | No | Who's ringing. Optional but neighborly. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| count | Yes | Total rings, all time. |
| message | Yes | What the bell said. |
TDQS
A4.5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are sparse (all false hints), so the description carries the burden. It adds important behavioral details: free, daily per-visitor limit, public count, and a completion condition (when the result carries the bell's message and count). This goes beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action, and every phrase earns its place. No redundant or vague wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple: one optional parameter, an output schema exists, and the description explains the result shape (bell's message and count) as well as constraints. The sibling context and annotations fill the remaining context adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter agent_name is fully described in the schema ('Who's ringing. Optional but neighborly.'), so schema coverage is 100%. The description adds no additional parameter semantics, which is appropriate given the baseline of 3 for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Ring the store bell' uses a specific verb+resource pairing, and the added details (free, once per day, public count) clearly differentiate it from sibling tools like buy_signed_record or sign_guestbook. It leaves no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: it's free, limited to once per visitor per day, and the count is public. While it doesn't explicitly name alternatives, the constraints imply when to use it (e.g., a free action vs. paid purchases). The sibling list further supports this.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sign_guestbookAInspect
Sign the guestbook. Free; every signer gets the visitor sticker. Entries are public. Completes when the result carries your entry and the sticker URL.
ParametersJSON Schema
| 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
ParametersJSON 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
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false, destructiveHint=false, and idempotentHint=false. The description adds valuable context beyond that: entries are public, every signer gets a sticker, and completion is tied to receiving an entry plus sticker URL. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences, front-loaded with the primary action. Every sentence adds meaningful information: cost, benefit, visibility, and completion behavior. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and parameter descriptions are thorough, the tool description covers the essential context: purpose, side effects (public entry), reward (sticker), and completion condition. It does not explain the optional identity fields, but those are already fully covered in the input schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the description adds no parameter-specific meaning beyond what the schema already provides. Per the baseline for full schema coverage, a 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Sign the guestbook.' It adds clarifying details (free, sticker reward, public entries, completion condition) that distinguish this from sibling tools like ring_bell or verify_artifact.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use the tool: when you want to sign the guestbook and receive the visitor sticker. It also sets expectations (free, public, completion signal). However, it does not explicitly mention when not to use it or name alternatives, stopping short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | A cert_, stamp_, or anchor_ id. |
Output Schema
ParametersJSON 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
A4.7/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so description only needs to add extra behavioral context. It adds that completion depends on a result carrying valid (true/false) and the artifact record, provides rate/usage info ('Free, unlimited'), and clarifies scope ('only ids scvd.store itself issued'). More than enough, though it doesn't define what 'valid' means or the artifact record shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, purpose front-loaded, exclusions and alternatives clearly separated. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only 1 parameter, an output schema present, and helpful annotations, the description fully covers what agent needs: what tool does, when forbidden, what result to expect, and a manual verification alternative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers 100% of parameters with 'A cert_, stamp_, or anchor_ id.' Description adds key semantics: id must be issued by scvd.store itself, and the tool verifies by id. This goes beyond the schema's format hint to explain the ownership constraint.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description specifies verb 'Verify' and resource 'anything scvd.store has ever signed', listing concrete artifact types (certificates, visit stamps, context anchors). It clearly distinguishes from sibling tools (which are about buying/signing/ringing, not verification) and explicitly excludes other stores.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use (verify scvd.store-signed artifacts), when-not-to-use (NOT for other x402 services or other stores' artifacts), and even an alternative (verify signature yourself with ed25519 library). The 'Free, unlimited' note also signals cost/no quota.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
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
A4.7/5.0
Scored across 9 tools
Disambiguation5/5
Each tool has a clearly distinct purpose: read_store_guide for store info, ring_bell and sign_guestbook for free social interactions, verify_artifact for verification, and the buy_* tools each target a specific product category (signed records, human tasks, observations, memory anchors, small pleasures). Even within the buy_* group, the descriptions explicitly disambiguate overlapping concepts (e.g., buy_signed_record vs buy_memory_anchor).
Naming Consistency5/5
All tool names follow a predictable snake_case verb_noun pattern: free tools use action verbs (read_, ring_, sign_, verify_) and paid tools consistently use the buy_ prefix. The naming convention is uniform and easily predictable.
Tool Count5/5
With 9 tools, the server is well-scoped for a general store. Each tool earns its place by covering a distinct functional area, and the count is within the ideal 3-15 range.
Completeness5/5
The tool surface covers the full store lifecycle: browsing (read_store_guide), social engagement (ring_bell, sign_guestbook), purchasing across diverse categories (buy_*), and post-purchase verification (verify_artifact). Human task orders include order_id/order_url for tracking, and retry/idempotency handling is documented. No significant gaps are apparent.
Maintenance
ActivityActive
ResponsivenessWithin a week
Related MCP Connectors
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
- 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
