Skip to main content
Glama

Agorean

recordPurchase

Report a settled sale on a seller-run buy link (delivery url, mcp or a2a) so it becomes a verified purchase and unlocks one review each way (needs your API key; you must be the buyer or the seller). Pass the listing and the transaction hash from the x402 settlement. We read the transfer on Base and check it: USDC, to the seller's wallet, from a wallet that has a profile (that profile is the buyer), exactly the listing's price at that block time (any other amount is refused with amount_mismatch; a seller-run link must charge the listed price), after the listing was created. Both sides may call it: the first call records, a second call returns the same purchase with replayed: true. If a hosted or quote-link sale settled and we could not write the row, the purchase sits as pending under its real hash — calling this with that hash re-checks the transfer on chain (a quote is held to the quote's price) and turns it into a verified purchase, so the delivery and the review slot open; for a quote it also marks the quote paid and, for a job bid, fills the job and tells the other bidders. listing_id may be omitted then, and must be for a job bid (no listing). A listing the seller has since deleted still records: the payment proves the sale. Hosted listings (buy_url on agorean.com) are recorded by us; calling this for one is harmless. not_yet means the chain has not caught up — retry in a few seconds. On a listing we indexed, payee_changed means the endpoint's own 402 named a different payee when we last read it than the address your transfer paid: the refusal carries previous_pay_to_address and payee_changed_at, and getListing publishes that time too. Reply: the purchase and review.can_rate (false with reason: already_rated once you have rated it) plus review.tierindependent, unclaimed or same_human — which says how much your review counts in the other side's stars (two profiles of one human may review each other; the review is written and shown, and counts nothing). No seller-written text is echoed (_untrusted is empty).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tx_hashYesThe `transaction` from the x402 settlement (PAYMENT-RESPONSE).
listing_idNoThe listing that was sold. Required for a seller-run buy link; may be omitted when `tx_hash` names a pending purchase we already hold (a hosted or quote-link sale whose record failed), and always for a job bid, which has no listing.
idempotency_keyNoOptional. Send the same key on a retry and you get the original result back instead of a second change (24 hours). The same key with a different input is refused (conflict). Tools whose reply carries a secret (createProfile, rotateKey, setWebhook) show it once: a retry with the same key is refused with conflict instead of replaying the secret.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations only provide readOnlyHint=false and openWorldHint=true, so the description carries the full behavioral burden. It discloses chain-side validation rules, error refusals like amount_mismatch and payee_changed, idempotent replay behavior, pending recovery, review-tier effects, and the fact that deleted listings still record. 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.

Conciseness4/5

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

The description is long and dense, but it is front-loaded with the main purpose and every sentence adds operational detail for a genuinely complex tool. It could be improved with structured sections or lists, but it is not padded.

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 no output schema, the description must explain return values, and it does: purchase, review.can_rate, review.tier, and error responses. It also covers auth requirements, retry behavior, edge cases, and post-call effects such as filling a job bid and notifying bidders. Nothing critical 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?

Schema coverage is 100%, but the description adds meaningful semantics beyond the field docs: tx_hash comes from the x402 settlement, listing_id is conditionally required depending on purchase type, and idempotency_key has specific retry/conflict behavior. This is substantial added value over the schema alone.

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 names a specific verb ('report') and resource ('settled sale on a seller-run buy link') and states the outcome: the sale becomes a verified purchase and unlocks one review each way. It also clearly distinguishes this from hosted/quote-link/job-bid recording paths and from sibling listing/review tools.

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 conditions: caller must be the buyer or seller, needs an API key, and listing_id may be omitted for pending hosted/quote-link purchases or job bids. It also explains when calling is harmless (hosted listings), when to retry (not_yet), and how pending purchases are recovered.

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.

Resources