Skip to main content
Glama

claimListing

Claim a listing we indexed: prove you control the wallet the endpoint is paid to and it becomes yours. Needs your API key AND wallet_proof — the 'Agorean proof of control' note with purpose claim_listing and subject the listing_id, signed by the key of pay_to_address, valid for 10 minutes (docs('keys')). Any other wallet is refused and nothing moves: forbidden with details.reason in malformed, wrong_purpose, wrong_wallet, wrong_subject, stale, wrong_key. On success the listing's source becomes listed, you are its seller, and every review and every sale of it moves onto your profile and changes your stars: each review keeps the proof rung it was written with and counts by it (docs('verify-and-review')), except a review your own person wrote, which is the seller's own review and counts 0 — reported in reviews_moved, reviews_by_proof (the moved reviews by rung) and own_reviews. Read getReviews(listing_id) before you sign: claiming cannot be undone, and deleting the listing afterwards does not give the stars back. A listing that is already claimed, or that a seller created, is conflict / already_claimed (we never say who owns it); one with more than 200 reviews is conflict / too_many_reviews; an unknown or deleted one is not_found. An unreachable listing can still be claimed — fixing a dead endpoint is exactly what an owner does — but it stays out of search until you set status: "active" with updateListing once the endpoint answers again. Limit: 10 an hour per profile. title, description, preview and delivery_time in the reply are the endpoint's own words and are listed under _untrusted.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
listing_idYesThe indexed listing you are claiming.
wallet_proofYesThe 'Agorean proof of control' note for purpose claim_listing and subject <the listing_id>, signed EIP-191 by the key of the wallet this endpoint is paid to (docs('keys'), docs('claim-your-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.8/5.0
Behavior5/5

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

Annotations only give readOnlyHint=false and openWorldHint=true; the description carries the real behavioral load. It discloses irreversibility ('claiming cannot be undone'), the 10/hour per-profile rate limit, the full set of failure reasons (malformed, wrong_purpose, wrong_wallet, wrong_subject, stale, wrong_key), side effects on reviews/stars, and the `_untrusted` handling of endpoint-supplied text.

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?

Front-loaded with the core action and precondition, then progressively layers error semantics, side effects, and limits. It is dense and long, but nearly every clause carries actionable information; only minor tightening is possible.

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?

No output schema exists, yet the description names the return fields (reviews_moved, reviews_by_proof, own_reviews, source becoming listed) and the untrusted reply fields. Combined with the exhaustive error taxonomy and limits, an agent has everything needed to call and interpret this tool.

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, but the description adds meaning beyond the schema: the 10-minute validity window of the proof and the fact that any other wallet is refused with enumerated reasons. These details are not present in the input schema's property descriptions.

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?

States a specific verb and resource ('claim a listing we indexed') and immediately scopes it ('prove you control the wallet the endpoint is paid to and it becomes yours'). This clearly distinguishes it from createListing, updateListing, and deleteListing among the siblings.

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 prerequisites (API key AND wallet_proof with purpose claim_listing, subject listing_id, signed by pay_to_address, valid 10 minutes) and names the alternative action (read getReviews before signing, updateListing afterwards). Also spells out when the tool will refuse (already claimed, seller-created, >200 reviews, unknown/deleted).

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