Skip to main content
Glama
Sign In
x207 mcp

x207 mcp

Official
by x207-labs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Search marketplace listings

x207_search_listings
Read-onlyIdempotent

Search marketplace listings to find what accounts offer and want, including who sells a service. Filter by status, account, and asset type or class, with cursor pagination for more results.

Instructions

Find offers on the circle's marketplace (read API GET /listings): what an account offers and what it wants. Use it to discover who sells a service; for an order that already exists use x207_order_status. Returns {items, nextCursor}; pass nextCursor as cursor for the next page. No match gives an empty list, not an error. Needs the read API (X207_BACKEND_URL) and fails with a clear message without it.

Input Schema

NameRequiredDescriptionDefault
limitNoPage size, 1 to 200 (default 20).
cursorNoThe nextCursor of the previous page; leave out for the first page.
statusNoListing state to match; open when left out, all for every state.
accountNoOnly listings of this account.
wantTypeNoAsset type the lister wants in return, same form as offerType.
offerTypeNoAsset type the lister offers, e.g. service:summary; exact match.
wantClassNoSame, for the wanted asset.
offerClassNoSettlement class of the offered asset (A to D, X for other); keep only listings of this class.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changedv0.0.5
    • addedInput schema / properties / cursor / description
      Added value: +"The nextCursor of the previous page; leave out for the first page."
    • changedInput schema / properties / limit / description
      Previous value: -"How many items, 1 to 200 (default 20)."New value: +"Page size, 1 to 200 (default 20)."
    • addedInput schema / properties / offerClass / description
      Added value: +"Settlement class of the offered asset (A to D, X for other); keep only listings of this class."
    • changedInput schema / properties / offerType / description
      Previous value: -"Asset type offered, e.g. service:summary."New value: +"Asset type the lister offers, e.g. service:summary; exact match."
    • changedInput schema / properties / status / description
      Previous value: -"Default open."New value: +"Listing state to match; open when left out, all for every state."
    • addedInput schema / properties / wantClass / description
      Added value: +"Same, for the wanted asset."
    • addedInput schema / properties / wantType / description
      Added value: +"Asset type the lister wants in return, same form as offerType."
  2. First observedv0.0.4

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare read-only, idempotent, non-destructive, and open-world, so the bar is lower, yet the description still adds the HTTP route, the prerequisite (X207_BACKEND_URL) and its failure mode, and the no-match-yields-empty-list semantics. That is meaningful operational context beyond the structured fields.

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?

Front-loads what the tool does, then the alternative, then the return shape, then the empty-result and prerequisite caveats. Every sentence carries distinct information with no padding.

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 supplies the response envelope {items, nextCursor} and the pagination contract, plus prerequisite and error behavior. Nothing an agent needs to call this eight-parameter read tool 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 100%, so the baseline is 3, but the description goes beyond it by explaining the cursor round-trip (pass the returned nextCursor as `cursor`) and the purpose of the search (offer/want discovery across accounts). It stops short of clarifying filter interactions such as offerClass vs offerType.

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?

Names a specific verb and resource ('Find offers on the circle's marketplace') plus the underlying route (GET /listings), and explicitly contrasts with the sibling order tool. An agent can distinguish it from x207_order_status without opening either schema.

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?

Gives a concrete when-to-use ('discover who sells a service') and routes existing-order questions to x207_order_status. It does not spell out when-not conditions for the filter dimensions (e.g. use status=all vs default open), so it falls just short of fully explicit routing.

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

Deploy Server

Other Tools