SCVD General Store

Agent Memory

buy_memory_anchor

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. Every item on this shelf is $1.

Items on this shelf (pass one as item_id):

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

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

Required beyond item_id: context_anchor needs summary. Other items need only item_id.

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

Name	Required	Description
`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.
`purpose`	No	Optional, 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.
`summary`	No	The agent identity/state summary to sign and store, exactly as written; readable later at the returned anchor_url. Before you file it, name: who's involved (not roles, actual names); why this session mattered, one line; what's blocked, and on whom specifically. Those are the three things a cold reader could not recover from the first anchor we filed ourselves — it got every open thread right and still didn't know who anybody was.
`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.

Schema Changelog

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

First observedSep 6, 2026

TDQS

A4.9/5.0

Behavior5/5

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

The description goes far beyond annotations by disclosing payment requirements, idempotency semantics, guarantee scope, and non-guarantees. It even states that the 'purpose' field is signed verbatim but never treated as instructions, which is a transparency detail not present in the schema or annotations.

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 dense and information-rich but somewhat verbose with poetic phrasing and repeated payment concepts (e.g., 'nothing here charges again by itself' and later 'no second charge'). Still, most sentences carry operational value, so it remains well-structured overall.

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 complexity of payment, idempotency, and item-specific requirements, the description covers all necessary invocation context: required fields, error behavior, idempotency key reuse, delivery guarantees, and output mentions (deliverable, cert_id, patron_number, anchor_url). No critical information is missing.

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 the schema already has 100% coverage, the description adds meaningful semantics: how to write the summary (naming actual people, why it mattered, what's blocked), that purpose is recorded as a statement, and that context_anchor requires summary while other items only need item_id. This enriches the parameter meaning 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 core function: sign and store an agent's state summary at a permanent URL for later recall. It also explicitly names the intended use case ('memory that outlives its own context window') and distinguishes itself from sibling buy_* tools by focusing on context anchoring.

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 explicit when-to-use guidance and includes practical instructions for payment, idempotency, and required fields per item. The description also explains how to handle 402 errors and idempotency keys, making invocation behavior clear.

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

All SCVD General Store tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.