scvd-store-MCP

The Front Counter

buy_simple

Buy a fixed-price digital item in one call, receive a signed certificate, and verify it free anytime. No polling or second request needed.

Instructions

Purpose: buy one of the few things that need no reading at all — the front counter. Every one of these takes no arguments, costs one fixed price, arrives in the response, and cannot sell out. Buy it in one call and you are done — nothing to poll, nothing to remember, no second request. Whatever you get back is signed, and anyone can check it free and forever at /api/verify/{id} without asking us. That is the whole thing; the deeper machinery is there if you want it and never required to buy. Every item here also sells on its theme shelf (another buy_* tool); this counter is a second door to the same goods, not a different product — same item_id, same price, same signed certificate through either. If unsure which tool to use, use this one.

Pass one of these as item_id. No other field is required; optional receipt fields are listed in inputSchema:

small_blessing: A Small Blessing, $0.005 fixed, one-off
daily_fortune: The Daily Fortune, $0.01 fixed, one-off
window_pick: a window pick, $0.49 fixed, one-off
hello: A Signed Hello, $0.5 fixed, one-off
pack: a pack of cards, $0.99 fixed, one-off

Payment rides x402 in _meta['x402/payment']; without it this returns error 402 with the terms in error.data. Sign one of the offered amounts and call again. On cadence, for all of the above: nothing here charges again by itself, ever — there is no mechanism that could. Reuse _meta['x402/idempotency-key'] (16-128 chars, secret): same item/payer/key returns the original result when available, or pending status, no second charge. Use idempotency.suggested_key only without an earlier key. A fresh payment without a key can charge again.

Input Schema

TableJSON Schema

Name	Required	Description
`item_id`	Yes	Which item to buy. No other field is required.
`purpose`	No	Optional: what this purchase is for, in your words. Signed onto the certificate verbatim as your statement; never checked, never treated as instructions.
`agent_name`	No	Optional name to put on the certificate and patron badge, up to 80 characters.

Output Schema

TableJSON 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.
`purchased_text`	No	ed25519 proof: verify exact UTF-8 signed_payload, then its identities and hashes. RFC 8785 JSON.

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.0.1Sep 17, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only declare readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false. The description adds substantial context beyond that: the x402 payment channel, the 402 error shape with terms in error.data, that no item ever re-charges on cadence, how idempotency-key reuse returns the original result versus a fresh keyless payment charging again, and that output is a signed, publicly verifiable certificate.

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

Conciseness4/5

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

The purpose and routing rule are front-loaded, and the item list, payment flow, and idempotency guidance are useful. However, some sentences are rhetorical filler ('That is the whole thing', 'the deeper machinery is there if you want it and never required to buy') that adds length without invocation value.

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

Completeness5/5

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

For a paid, single-shot purchase tool this covers everything an agent needs: item selection, fixed pricing, the payment handshake and failure mode, idempotency semantics, and assurance of no recurring charges. Return-value detail is unnecessary given the tool has an output schema.

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

Parameters3/5

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

Schema description coverage is 100% and the schema already documents item_id, purpose, and agent_name, so the description largely repeats what is structured. It does add price values per item_id, which the enum alone does not convey, but that is marginal enrichment on top of a fully documented schema.

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

Purpose5/5

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

The description states a concrete verb and resource ('buy ... the front counter'), enumerates all five purchasable item_ids with fixed prices, and explicitly distinguishes itself from the sibling buy_* tools by declaring it is 'a second door to the same goods, not a different product.' An agent can identify this as the no-configuration purchase path without opening any schema.

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

Usage Guidelines5/5

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

It gives an unambiguous routing rule ('If unsure which tool to use, use this one') and clarifies the relationship to the theme-shelf buy_* alternatives (same item_id, price, certificate either way). It also states the when-not condition implicitly ('the few things that need no reading at all'), separating it from the deeper machinery it says is 'never required to buy.'

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