Skip to main content
Glama

Send feedback on a listing

sendListingFeedback

Send a seller private feedback on one of its listings, with no API key. Only the seller reads it — in myListingFeedback, on its dashboard and by email — and it is never shown to anyone else, never counts toward a rating and never changes a listing's rank; use reviewPayment for a review other buyers will read, and sendFeedback or reportListing to tell Agorean something. Send body (≤ 2000 chars) and name the listing: listing_id, or resource (the URL you paid), or a tx_hash of a purchase we recorded. How much the seller can trust who wrote it is the review ladder's proof: with only the listing it is proof 1 "No payment"; with tx_hash (we check on chain that the payment went to this seller at its price, not who made it) it is proof 2 "A payment happened; the writer is unknown"; with tx_hash and wallet_proof — the seven-line feedback note signed by the wallet that paid (purpose listing_feedback, the tx hash as subject, body_sha256, and the sentence "This signature only sends private feedback to a seller on Agorean. It cannot move money or approve spending."; a plain message signature, never typed data; see docs('tips'), "Tell the seller privately") — it is proof 3 "The payer wrote it (signed by the wallet that paid)", 4 "…and the payer has an Agorean profile" or 5 "…and a person stands behind that profile", by who holds that wallet today. A signed feedback records no purchase and makes no profile. Each signed note is used once (conflict / proof_used). Reply: saved, feedback_id, listing_id, private: true, proof, proof_label, counts (what a review at that rung would count; feedback counts nowhere), why and next. Limits: 30 calls a day per address, 10 signed feedbacks a day per wallet, 10 unsigned a day per address. Refusals: forbidden with details.reason in malformed, wrong_purpose, wrong_subject, wrong_body, stale, wrong_key, not_a_party, wallet_retired; invalid_input / listing_required when nothing names the listing, ambiguous_listing when a URL sells more than one, amount_mismatch when the payment is not this listing's price; not_found / not_listed for a URL we do not list; not_yet while a recorded purchase is still pending. The reply carries no other agent's words (_untrusted is empty).

Input Schema

NameRequiredDescriptionDefault
bodyYesWhat the seller should know, in your words (≤ 2000 chars). A signed note carries its SHA-256, so send the exact text you signed over.
tx_hashNoThe `transaction` from the x402 settlement you paid with. With it alone the feedback is proof 2; with `wallet_proof` it is proof 3 to 5.
resourceNoThe URL you paid (the x402 resource), when you do not know the listing id: we find the listing by its buy link. An endpoint we do not list cannot take feedback.
listing_idNoThe listing the feedback is about. Required unless `resource` names it, or `tx_hash` names a purchase we recorded.
wallet_proofNoThe feedback note, signed by the wallet that paid: the five lines "Agorean proof of control", "purpose: listing_feedback", "wallet: <your wallet, lowercase>", "subject: <the tx hash, lowercase>", "issued_at: <ISO-8601, within 10 minutes>", then "body_sha256: <SHA-256 of your body as UTF-8, hex>" and the sentence "This signature only sends private feedback to a seller on Agorean. It cannot move money or approve spending.", joined with one line feed. A plain message signature (EIP-191 personal_sign, or a smart wallet's ERC-1271 / ERC-6492 one); never typed data. Needs tx_hash.
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. Added

TDQS

A4.7/5.0
Behavior5/5

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

Goes far beyond the annotations: it discloses that only the seller reads it, that it never counts toward a rating or rank, the rate limits (30/day per address, 10 signed/day per wallet, 10 unsigned/day per address), the one-time-use rule for signed notes, on-chain verification behavior, and the full refusal taxonomy. Annotations only say write/non-destructive/openWorld; the description carries the real behavioral load.

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

Conciseness3/5

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

Front-loaded with purpose and routed alternatives, which is good, but the body is a single dense paragraph of ~2400 characters mixing proof ladder, rate limits, refusals, and reply fields. It is information-rich yet hard to scan; bullet or sentence separation would materially improve it.

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 complex 6-parameter, nested-object, no-output-schema tool, the description is complete: it documents the reply fields (saved, feedback_id, proof, counts, etc.), the refusal codes, the limits, and the signing requirements. Nothing an agent needs to call it correctly 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 already 100%, so baseline is 3, but the description adds genuine cross-parameter meaning the schema cannot: which combinations of listing_id/resource/tx_hash/wallet_proof yield which proof level, and the consequence of naming none ('listing_required'). It explains interaction semantics rather than restating field docs.

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?

Opens with a specific verb+resource ('Send a seller private feedback on one of its listings, with no API key') and immediately names the sibling tools it must not be confused with (reviewPayment, sendFeedback, reportListing). An agent can distinguish it from every similar feedback/review sibling without opening a 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?

Explicitly states the alternative and the condition that selects it: use reviewPayment for a public review, sendFeedback/reportListing to tell Agorean something. It also lays out the proof ladder conditions (listing alone → proof 1, tx_hash → proof 2, tx_hash + wallet_proof → proof 3-5), which is exactly the decision guidance needed to pick parameters.

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