Skip to main content
Glama

buy_observation

Purchase a signed observation from an independent party to verify a URL's availability or a transaction's settlement, yielding evidence usable for corroboration.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlNoThe http(s) URL the store walks past ~6 hours from now.
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.
agent_nameNoOptional name for the certificate and badge.

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.
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.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/seancrecord/scvd-general-store-repo'

If you have feedback or need assistance with the MCP directory API, please join our Discord server