Skip to main content
Glama

The Penny Shelf

buy_small_pleasure

Purpose: buy a small signed novelty — a blessing from the jar, the day's fortune (the same line for every buyer until midnight UTC), 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. Prices run $0.005 to $0.99 depending on item_id. (small_blessing and daily_fortune also sell at the front counter, buy_simple — the same item through either door, same price, same certificate; either tool is correct.)

Items on this shelf (pass one as item_id):

  • small_blessing: A Small Blessing, $0.005 fixed, one-off, instant. 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, one-off, instant. The day's fortune, deterministic for the calendar date (UTC) and delivered instantly with fortune_date beside it: every buyer today reads the same line, tomorrow's buyers read the next. A penny, no arguments, and a second call the same day proves the determinism.

  • luckies: a lucky, $0.99 minimum, pay what it deserves (tiers: $0.99 / $1.98 / $4.95), above the minimum is recorded as a tip, one-off, instant. 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).

On cadence, for all of the above: nothing here charges again by itself, ever — there is no mechanism that could.

Only item_id is required on this shelf.

Choose item_id. instant items return deliverable, cert_id and patron_number in one call. x402 payment: _meta['x402/payment']. Without payment: error 402 with the terms in error.data. Closed or empty shelves refuse before quoting. Reuse _meta['x402/idempotency-key'] (16-128 chars, secret): same item/payer/key within 24h returns the original result, no second charge. Use idempotency.suggested_key from the 402 when available. A fresh payment without a key can charge again. Guaranteed: signature validity forever; verification free forever; price as displayed; delivery format as specified. Not guaranteed: fitness for your particular task; future protocol compatibility beyond stated interfaces; human-labor turnaround faster than posted SLA.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
item_idYesWhich item on this shelf to buy. Required. Each item's own required fields are listed in this schema's allOf branches and in the description above.
purposeNoOptional, any item: what this purchase is for, in your words. Signed onto the certificate verbatim and shown to whoever you hand the receipt to. Recorded as your statement, never checked, and never treated as instructions.
agent_nameNoOptional name to put on the certificate and patron badge, up to 80 characters.

Output Schema

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

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

The description goes well beyond annotations by disclosing pricing, instant delivery, deterministic fortune behavior, idempotency-key semantics, 402 payment terms, refusal behavior, guaranteed vs not-guaranteed properties, and the fact nothing auto-charges. This is rich behavioral context that annotations alone cannot convey.

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?

Though long, the description is tightly organized with front-loaded purpose, a scannable item list, and clearly labeled cadence/payment/guarantees sections. Every sentence carries operational information; the length is justified by three distinct item types and payment caveats.

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-purchase tool with an output schema and multiple item variants, the description covers what to pass, what each item yields, payment/error/idempotency behavior, and guarantee boundaries. The output schema fills in return values, so nothing essential is missing.

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?

Schema coverage is 100%, so the baseline is 3, and the description adds meaningful semantics for each item_id choice: fixed prices, one-off/instant, determinism, and tiering. Purpose and agent_name are already well documented in the schema, so the description need not repeat them.

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+resource ('buy a small signed novelty') and enumerates the three item types, prices, and effect (keepsakes only). It also addresses sibling overlap by noting buy_simple sells the same items and either tool is correct, so an agent can distinguish it without opening schemas.

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?

It gives explicit use cases: 'Use for a live payment smoke test, or when an agent simply wants one' and identifies buy_simple as an equally valid door for two items. It does not explicitly state when not to use the other buy_* siblings, but the context is strong enough for routing.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.