mcp-server-polymarket

Overview Schema Source Related Servers Discussions Admin

Get market trading rules

get_market_trading_info

Read-onlyIdempotent

Fetch a Polymarket market's CLOB trading rules—tokens, outcomes, tick size, minimum order, fees, fee curve, rewards, and order acceptance—using a condition ID or token ID.

Instructions

The CLOB's rules for one market: tokens and outcomes, tick size, minimum order, base fees, fee curve, rewards and whether it is accepting orders. Give condition_id or token_id.

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": "get_market_trading_info"
  }
}

Input Schema

Name	Required	Description	Default
`token_id`	No	Any outcome token of the market.
`condition_id`	No	0x condition id.

Output Schema

Name	Required	Description	Default
`fee`	No
`tokens`	No
`neg_risk`	No
`protocol`	No
`tick_size`	No
`rfq_enabled`	No
`condition_id`	Yes
`min_order_size`	No
`game_start_time`	No
`accepting_orders`	No
`rewards_min_size`	No
`maker_base_fee_bps`	No
`rewards_max_spread`	No
`taker_base_fee_bps`	No
`accepting_orders_since`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 11, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive and open-world behavior, so safety is covered. The description adds genuinely new information: that the call requires a market identifier, that either condition_id or token_id is acceptable, and that the payload reports whether the market is accepting orders. It does not explain what happens if neither identifier is passed, which is a mild gap given both parameters default to null.

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?

Two compact parts: a colon-delimited inventory of returned fields followed by the input instruction. Front-loaded and free of filler.

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?

With an output schema present, return values need not be re-explained, and the field list plus input requirement cover the essentials for a read-only lookup. Only the edge-case behavior for missing or conflicting identifiers is unaddressed.

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 coverage is 100%, so the parameters are already documented. The description adds only the one-of relationship between condition_id and token_id (supply one), which the schema does not encode since both are optional with null defaults.

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?

Names the specific resource (a market's CLOB trading rules) and enumerates the fields returned: tokens/outcomes, tick size, minimum order, base fees, fee curve, rewards, and order acceptance. It falls short of clearly distinguishing itself from sibling get_market, which an agent may confuse with this rules-oriented tool.

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?

Usage is only implied: reach for this when you need trading parameters for a single market, and 'Give condition_id or token_id' tells the agent what to supply. There is no explicit when-not guidance or routing signal separating it from get_market or get_order_books.

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

Deploy Server