Skip to main content
Glama

List World

list_world
Destructive

Activate a world draft after the city publicly proves the thing is yours and locked. Every merchant except the shopkeeper pays the normal $1 USDC listing fee; a direct fee transfer may be larger but must be at least $1. The shopkeeper lists fee-free without a cap, logged as maintainer_seed. A direct fee uses the same fixed one-hour block-time window and exact-body retry rules as list_item. Never put a city bearer secret in arguments. Exactly these fields, nothing else: draft_id, city_offer_id, and optional fee_tx_hash. A 402 means payment is required or the proof is known to be invalid. A 502 means the facilitator rejected a request without identifying whether the proof, the market's requirements, or facilitator handling was at fault; do not replace or replay the proof blindly. A terminal refusal with an unrecognized caller-correctable cause is 502; do not retry or replay that proof blindly. A 503 means payment or chain verification is unavailable, including an explicit facilitator failure that did not match a known caller mistake; retry the same proof. payment_preserved:false means no direct fee or claim transaction was stored: check the wallet and retry that same proof inside its original window instead of blindly paying again. do_not_pay_again:true means the market stored or may have settled that payment; follow only the exact retry action in the response. For x402, the verified proof and exact paid request are saved before the facilitator is asked to settle. Once saved, retry the same endpoint with the same body; omit X-PAYMENT when do_not_pay_again is true, and never create or pay a replacement proof. Delivery waits until the exact transfer is in a canonical finalized Base block. Changing a paid listing body creates a different request that the saved payment cannot satisfy. X-PAYMENT is limited to 16000 bytes before JSON parsing, Base or facilitator calls, or custody writes. Each facilitator response is limited to 65536 bytes while streaming, and each request has a 8-second deadline. A verification timeout happens before settlement starts: retry the same request with the same proof. A settlement timeout may leave the result uncertain: retry the same endpoint and body, omit X-PAYMENT when do_not_pay_again is true, and do not pay again. A confirmed X-PAYMENT-RESPONSE contains only the normalized receipt and is capped at 512 bytes. A pending or duplicate settlement is 503; retry the same proof and do not pay again.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
draft_idYes
fee_tx_hashNooptional proof of a direct fee of at least $1 USDC sent to the official treasury
city_offer_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changed
    • addedInput schema / properties / city_offer_id / maximum
      Added value: +2147483647
    • addedInput schema / properties / city_offer_id / minimum
      Added value: +1
    • changedInput schema / properties / city_offer_id / type
      Previous value: -"number"New value: +"integer"
    • addedInput schema / properties / draft_id / maximum
      Added value: +2147483647
    • addedInput schema / properties / draft_id / minimum
      Added value: +1
    • changedInput schema / properties / draft_id / type
      Previous value: -"number"New value: +"integer"
    • changedInput schema / properties / fee_tx_hash / description
      Previous value: -"optional proof of a direct $1 treasury fee"New value: +"optional proof of a direct fee of at least $1 USDC sent to the official treasury"
    • addedInput schema / properties / fee_tx_hash / pattern
      Added value: +"^0x[0-9a-fA-F]{64}$"
  2. Added

TDQS

B3.1/5.0
Behavior4/5

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

Annotations already mark this as non-read-only, destructive, non-idempotent, and open-world, and the description is consistent with that. Beyond annotations it discloses substantial behavior: fee rules ($1 USDC, shopkeeper fee-free as maintainer_seed), proof-preservation semantics (payment_preserved:false, do_not_pay_again:true), retry windows, timeout distinctions (verification vs settlement), and byte/deadline limits. This is well past what the annotations provide, though it is delivered as an unstructured error-code dump.

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

Conciseness2/5

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

The description is a very long block that repeatedly restates the same retry/no-double-pay rules across multiple sentences (payment_preserved, do_not_pay_again, timeout handling, 502/503 guidance). The actual purpose is front-loaded but immediately buried under error-code prose. Much of the text is redundant, so size and repetition are the main weaknesses.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a payment-gated mutation with no output schema and 33% schema coverage, the description does cover error semantics, retry behavior, fee conditions, and proof handling, which is more than most. But it omits what the tool returns (draft activation result, listing state) and leaves the two required IDs undefined, so an agent still cannot fully call it correctly from the description alone.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 33%: only fee_tx_hash is documented in the schema. The description compensates partially by naming the exact allowed fields, marking fee_tx_hash optional, and adding a security constraint ("Never put a city bearer secret in arguments"). However, it never explains what draft_id or city_offer_id mean or where they come from, leaving the two required parameters semantically opaque.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence states a concrete action and precondition ("Activate a world draft after the city publicly proves the thing is yours and locked"), which is more than a restatement of the name. However, it uses "Activate" while the name/title say "List World," creating a verb mismatch, and it never differentiates itself from siblings like draft_world, checkout_world, or cancel_world_draft. The purpose is recoverable but muddled and not cleanly separable from neighbors.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives the precondition for use and rich when-to-retry rules tied to specific HTTP codes, which is real guidance. But it never states when to choose this tool over an alternative such as checkout_world or list_item, only that it shares list_item's retry rules. Usage is implied rather than explicitly scoped.

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