mcp-server-polymarket

Overview Schema Source Related Servers Discussions Admin

List markets

list_markets

Read-onlyIdempotent

Browse Polymarket prediction markets sorted by 24h volume, or fetch specific markets by condition ID, token ID, or slug for targeted market research.

Instructions

Browse or look up individual markets, sorted by 24h volume by default. Pass condition_ids, token_ids or slugs to fetch specific markets in one call.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_markets"
  }
}

Input Schema

Name	Required	Description	Default
`limit`	No	Rows per page.
`order`	No		volume_24h
`slugs`	No
`cursor`	No	next_cursor from the previous page. Empty starts at the top.
`status`	No		open
`tag_id`	No	Numeric tag id from list_tags.
`abridged`	No	With id lookups: return only id, question, prices.
`ascending`	No
`end_after`	No	ISO 8601 time, e.g. 2026-11-01 or 2026-11-01T12:00:00Z, or epoch seconds.
`token_ids`	No	Markets of these tokens.
`end_before`	No	ISO 8601 time, e.g. 2026-11-01 or 2026-11-01T12:00:00Z, or epoch seconds.
`min_volume`	No
`rfq_enabled`	No	Only markets usable in Combos.
`condition_ids`	No	Look up these markets.
`min_liquidity`	No
`min_rewards_size`	No	Only markets paying liquidity rewards from this size.
`sports_market_types`	No	e.g. moneyline, spreads, totals.

Output Schema

Name	Required	Description	Default
`note`	No
`count`	No
`items`	No
`has_more`	No
`next_cursor`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 11, 2026

TDQS

B3.4/5.0

Behavior3/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 safety needs no restating. The description adds the default ordering behavior and the fact that ID lookups collapse into a single call, but says nothing about pagination limits, result size, or how filters interact with ID lookups.

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?

Two tight sentences, with the default sort and the lookup shortcut front-loaded and no filler. Nothing is repeated that the schema already states verbatim, though it is arguably too terse for a 17-parameter tool.

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?

The output schema exists, so return-value explanation is not required. However, for a tool with 17 optional parameters covering filtering, sorting, pagination and ID lookup, the description covers only the lookup mode and default order, leaving the filter/pagination surface entirely to the schema.

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?

With 17 parameters and 65% schema coverage the description only surfaces three of them (condition_ids, token_ids, slugs) plus the default order. Those three already carry 'Look up these markets' / 'Markets of these tokens' descriptions in the schema, so the added meaning is marginal; filtering parameters like status, tag_id, min_volume and time bounds go unmentioned.

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 and resource (browse/look up markets) and names the default sort, which distinguishes it from a plain listing. The batched-lookup mode is called out explicitly, so an agent can tell it apart from get_market for single-market reads, though get_market is never named.

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?

Gives one concrete usage cue: pass condition_ids, token_ids or slugs to fetch specific markets in one call. There is no statement about when to prefer this over get_market or a list_events-based flow, and no exclusions, so guidance is implied rather than explicit.

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

Deploy Server