Skip to main content
Glama
Arjein

Polymarket MCP Server

by Arjein

get_clob_markets

Fetch a paginated list of actively trading Polymarket CLOB prediction markets, including condition IDs, outcome token IDs, and trading parameters. Use the cursor to page through results.

Instructions

Retrieve a paginated list of all prediction markets actively trading on the Polymarket CLOB API.

Provides comprehensive details for each market, including the on-chain condition IDs, corresponding outcome token IDs, and trading configuration parameters.

Args: next_cursor (Optional[str]): The pagination cursor string returned from a previous request. Omit this argument to fetch the first page of results.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
next_cursorNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

B3.4/5.0
Behavior3/5

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

No annotations, so the description carries the full behavioral burden. It discloses the pagination model and that only actively-trading markets are returned, which is useful. But it omits auth/permission requirements and rate-limit behavior; the output schema covers return format, so this is adequate-but-incomplete.

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?

Three short, front-loaded paragraphs; the core purpose leads and the param note is compact. Minor redundancy between the opening line and the detail sentence, but nothing wasteful.

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

Completeness4/5

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

An output schema exists, so return-value explanation is unnecessary and correctly absent. The description covers what the list contains and how to page through it; the main gap is sibling differentiation for a tool family with heavy overlap.

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 0%, so the description must compensate, and it does: it fully explains next_cursor as a cursor from a prior request and instructs omitting it to get the first page. This adds meaning the schema does not.

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 (Retrieve/list) and resource (prediction markets actively trading on the Polymarket CLOB API) with clear scope. The 'comprehensive details' framing hints at how it differs from get_clob_simplified_markets, but it never names a sibling to disambiguate.

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

Usage Guidelines2/5

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

The only usage guidance is about the pagination parameter ('omit to fetch the first page'). There is no when-to-use, when-not-to-use, or routing to alternatives like get_clob_simplified_markets, get_clob_market, or search_markets, despite many overlapping siblings.

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