marketplace

prepare_listing

Prepare a SELL listing or Dutch auction. Verifies the seller OWNS the position and it's transferable (not voted/attached), builds the Seaport order with the Interface fee injected by the server, and returns the one-time NFT approval + EIP-712 typed data to sign. Never signs or holds keys.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "marketId": "<marketId>",
      "kind": "<kind>",
      "currencySymbol": "<currencySymbol>",
      "seller": "<seller>"
    },
    "name": "prepare_listing"
  }
}

Input Schema

Name	Required	Description
`ask`	No	listing: price the seller nets — must be positive
`kind`	Yes
`name`	No	name markets only, e.g. 'alice' or 'alice.base.eth' — tokenId is derived
`endAsk`	No	dutch_auction: floor price (must be below the start)
`seller`	Yes
`tokenId`	No	required for token markets (e.g. vehydx)
`marketId`	Yes
`startAsk`	No	dutch_auction: starting (high) price
`durationDays`	No
`currencySymbol`	Yes	one of the market's settlementCurrencies (see list_micro_markets). A symbol resolves per market, so the same symbol can name different contracts: 'AERO' is the NEW Aero token (0x3f5b…a4Ee) on saero and the legacy Aerodrome token (0x9401…8631) on veaero. Check the address in list_micro_markets.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 30, 2026

changedInput schema / properties / currencySymbol / description

Previous value: -"one of the market's settlementCurrencies (see list_micro_markets)"New value: +"one of the market's settlementCurrencies (see list_micro_markets). A symbol resolves per market, so the same symbol can name different contracts: 'AERO' is the NEW Aero token (0x3f5b…a4Ee) on saero and the legacy Aerodrome token (0x9401…8631) on veaero. Check the address in list_micro_markets."

First observedSep 1, 2026

TDQS

A3.7/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses ownership/transferability verification, server-side fee injection, and that the result is one-time NFT approval plus EIP-712 typed data. 'Never signs or holds keys' clarifies the safety boundary. Missing details like order expiry or idempotency keep it from a 5.

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

Conciseness5/5

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

Three dense sentences, front-loaded with the action, then preconditions, then return shape. No wasted words.

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 10-parameter mutation-preparation tool with no annotations and no output schema, the description usefully describes the return payload and preconditions. However, it does not help the agent choose between pricing parameters per kind or between tokenId and name, which is the main remaining ambiguity.

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

Parameters2/5

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

Schema coverage is 60%, leaving several parameters (startAsk/endAsk/durationDays/tokenId vs name selection) undocumented, and the description adds no parameter-level meaning at all — it only implies the listing/dutch_auction split already captured by the enum. The pricing and duration semantics must be inferred entirely from the schema.

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

Purpose4/5

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

States a specific verb ('Prepare') and resource ('SELL listing or Dutch auction'), so the agent knows this is the sell-side preparation tool. It contrasts implicitly with prepare_offer/prepare_cancel but never names a sibling explicitly.

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

Usage Guidelines4/5

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

The usage context is clear: sell a position, and the position must be owned and transferable (not voted/attached). It gives no explicit exclusions or named alternative (e.g. 'to buy, use prepare_offer'), so it stops short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All marketplace tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?