Skip to main content
Glama
agent-next

polymarket-paper-trader

List markets

list_markets
Read-onlyIdempotent

Retrieve active Polymarket markets ranked by volume or liquidity to find the highest-activity markets for paper-trading research. Read-only live API query that changes nothing.

Instructions

List active Polymarket markets, highest volume or liquidity first.

Queries the live Polymarket API and changes nothing. Use search_markets for a keyword, get_markets_by_tag for a category, or kalshi_markets for Kalshi.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum markets to return, clamped to 1-100. Default 20.
sort_byNo'volume' or 'liquidity', highest first. Default 'volume'.volume

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.4.13
    • addedInput schema / properties / limit / description
      Added value: +"Maximum markets to return, clamped to 1-100. Default 20."
    • addedInput schema / properties / sort_by / description
      Added value: +"'volume' or 'liquidity', highest first. Default 'volume'."
  2. First observedv0.4.1

TDQS

A4.2/5.0
Behavior3/5

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

'Queries the live Polymarket API and changes nothing' largely restates the existing readOnlyHint=true and openWorldHint=true annotations, so it adds little beyond structured data. The one genuinely additive detail is the ordering guarantee ('highest volume or liquidity first'), though that mostly mirrors the sort_by default. No pagination or rate-limit context.

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?

The critical scoping information is front-loaded in sentence one, and the routing sentence is dense and useful. The middle sentence about the live API and no side effects is the weakest link, partly duplicating annotations, but it costs little.

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?

With an output schema present and 100% schema description coverage on both parameters, the description only needs to cover purpose, scope, and sibling routing – all of which it does. Nothing required to call the tool correctly is missing.

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 description coverage is 100% – both limit (clamped 1-100, default 20) and sort_by ('volume'/'liquidity', default 'volume') are fully documented in the schema. The description's re-statement of the volume/liquidity ordering is consistent but not additive, so the baseline 3 applies.

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?

States a specific verb and resource ('List active Polymarket markets') plus the default ordering, which alone separates it from get_market, search_markets, and kalshi_markets. An agent can identify the tool's output shape (a ranked list of active markets) without opening the schema.

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

Usage Guidelines5/5

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

Explicitly routes to alternatives with the selecting condition: search_markets for a keyword, get_markets_by_tag for a category, kalshi_markets for the other exchange. This is a complete when-to-use-this-vs-that map, including the sibling that covers a different venue.

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