The Polymarket MCP Server gives AI assistants read access to Polymarket prediction markets via 23 tools, 5 resources, and 4 prompts — no API keys or configuration required.
Market Discovery & Filtering
List, filter, and paginate events and markets by volume, liquidity, tags, status, and date ranges
Full-text search across events, markets, and profiles
Browse category tags, event series, sports, and sports teams
Real-Time Price & Order Book Data
Get current buy/sell prices, midpoint prices, and last trade prices
Access full order book depth (single or batch up to 20 tokens)
View order book summaries (best bid, ask, spread) and minimum tick sizes
Retrieve CLOB market details (tokens, rewards, trading parameters)
Trades & Holders
View recent trade history (trader, side, size, price, timestamp)
Identify top position holders and their position sizes for any market
Guided Analysis Workflows
Deep-dive market analysis (probability, liquidity, order book depth, top holders)
Side-by-side market comparison
Trending markets discovery by volume
Sports prediction markets overview
Production-Grade Features
Rate limiting per API endpoint (Gamma: 4k/10s, CLOB: 9k/10s, Data: 1k/10s)
Smart in-memory caching (order books: 5s, markets: 30s, tags: 5min)
Exponential backoff retries and request timeouts
URI-based resource access for markets, events, order books, and tags
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Polymarket MCP Server What are the trending prediction markets by volume right now?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Prediction markets are the best real-time signal for what the world thinks will happen next. This server puts that signal directly into your AI assistant's toolkit — no API keys, no auth tokens, no setup hassle.
23 tools • 5 resources • 4 prompts • Zero config • Zero dependencies beyond the MCP SDK
Related MCP server: Polymarket MCP Server
Add to your claude_desktop_config.json (Settings > Developer > Edit Config):
{
"mcpServers": {
"polymarket": {
"command": "npx",
"args": ["-y", "@yigit/polymarket-mcp"]
}
}
}Restart Claude Desktop. Done.
claude mcp add polymarket -- npx -y @yigit/polymarket-mcpgit clone https://github.com/yigitabi5444/yigit_polymarket_mcp.git
cd yigit_polymarket_mcp
npm install && npm run build
node dist/index.js # runs over stdioThen point your MCP client at the built binary:
{
"mcpServers": {
"polymarket": {
"command": "node",
"args": ["/absolute/path/to/yigit_polymarket_mcp/dist/index.js"]
}
}
}Tool | What it does |
| List/filter events — paginate, sort by volume/liquidity, filter by tag/status |
| Single event by ID or slug |
| List/filter markets with rich filtering (volume, liquidity, dates, tags) |
| Single market by ID or slug |
| Full-text search across events, markets, and profiles |
| List all category tags |
| List event series (grouped collections) |
| Get a specific series by ID |
| List available sports |
| List teams for a sport |
Tool | What it does |
| Current price for a token (buy/sell side) |
| Midpoint price (best bid + best ask / 2) |
| Last executed trade price |
| Historical price time series (configurable interval + fidelity) |
| Full bid/ask depth for a token |
| Batch order books for multiple tokens |
| Best bid, best ask, and spread at a glance |
| CLOB market details by condition ID |
| Markets eligible for liquidity rewards |
| Simplified sampled markets |
| Minimum price increment for a token |
Tool | What it does |
| Recent trades for a market |
| Top holders / position breakdown for a market |
URI Pattern | Description |
| Market JSON by slug |
| Event JSON by slug |
| CLOB market by condition ID |
| Live order book for a token |
| All category tags (cached) |
Prompt | Description |
| Deep-dive: probability, liquidity, order book depth, top holders |
| Side-by-side comparison of multiple markets |
| Find the hottest markets by volume right now |
| Overview of sports prediction markets |
┌─────────────────────────────┐
│ MCP Client │
│ (Claude Desktop / Code) │
└─────────┬───────────────────┘
│ stdio (JSON-RPC)
┌─────────▼───────────────────┐
│ polymarket-mcp │
│ │
│ ┌──────────┐ ┌──────────┐ │
│ │ Tools │ │Resources │ │
│ │ (22) │ │ (5) │ │
│ └────┬─────┘ └────┬─────┘ │
│ │ │ │
│ ┌────▼─────────────▼─────┐ │
│ │ API Client │ │
│ │ ┌───────┐ ┌────────┐ │ │
│ │ │ Rate │ │ Cache │ │ │
│ │ │Limiter│ │ (TTL) │ │ │
│ │ └───┬───┘ └───┬────┘ │ │
│ │ │ │ │ │
│ │ ┌───▼─────────▼────┐ │ │
│ │ │ Retry + Backoff │ │ │
│ │ └──────────────────┘ │ │
│ └────────────────────────┘ │
└──────────┬───────────────────┘
│ HTTPS
┌──────────▼───────────────────┐
│ Polymarket APIs │
│ gamma-api · clob · data-api │
└──────────────────────────────┘List endpoints (get_markets, get_events) default to active=true, closed=false, order=volume descending — you get the hottest live markets out of the box, not ancient resolved ones from 2020. Override any default explicitly when you need historical data.
Raw Polymarket API responses contain 50+ fields per market (including gems like pagerDutyNotificationEnabled and mailchimpTag). This server strips the noise and returns a curated subset. JSON-encoded strings like outcomes and outcomePrices are parsed into real arrays — ["Yes", "No"] not "[\"Yes\", \"No\"]".
Feature | Implementation |
Rate limiting | Token-bucket per API endpoint (Gamma: 4k/10s, CLOB: 9k/10s, Data: 1k/10s) |
Caching | In-memory TTL cache (order books: 5s, markets: 30s, tags: 5min) |
Retries | Exponential backoff with jitter on 429s and 5xx errors (3 retries max) |
Timeouts | 15s request timeout on all API calls |
No auth | Only hits public endpoints — zero secrets to manage |
No deps | Uses native |
Type safety | Full TypeScript with strict mode, Zod validation on all inputs |
Environment Variable | Default | Description |
|
| Set to |
That's it. No API keys, no tokens, no config files. It just works.
npm install # install dependencies
npm run build # compile TypeScript
npm run dev # run with tsx (auto-reload)
npm test # run test suite
npm run test:watch # tests in watch modesrc/
├── index.ts # stdio entrypoint
├── server.ts # MCP server factory
├── config.ts # rate limits, cache TTLs, timeouts
├── api/
│ ├── client.ts # HTTP client with retry + rate limiting
│ ├── cache.ts # TTL cache implementation
│ ├── rate-limiter.ts # token-bucket rate limiter
│ ├── gamma.ts # Gamma API wrapper
│ ├── clob.ts # CLOB API wrapper
│ └── data.ts # Data API wrapper
├── tools/
│ ├── gamma/ # 6 Gamma tools
│ ├── clob/ # 4 CLOB tools
│ └── data/ # 2 Data tools
├── resources/ # 5 URI-based resources
├── prompts/ # 4 guided analysis prompts
└── types/ # TypeScript type definitionsYou: What are the hottest prediction markets right now?
Claude: uses
get_marketssorted by volume, thenget_order_bookfor depth analysis
You: What's the current probability that Bitcoin hits $200k this year?
Claude: uses
search("bitcoin 200k"), thenget_pricefor live odds
You: Compare the presidential election markets
Claude: uses the
compare_marketsprompt with relevant slugs
You: Show me the order book for the top sports market
Claude: uses
get_sports→get_markets→get_order_book
PRs welcome! Please:
Fork the repo
Create a feature branch (git checkout -b feature/awesome)
Add tests for new functionality
Make sure npm test passes
Submit a PR
MIT — do whatever you want with it.
Get CLOB-specific market details by condition ID. Returns tokens, rewards, tick sizes, and trading parameters.
| Name | Required | Description | Default |
|---|---|---|---|
| condition_id | Yes | Market condition ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states this is a read operation ('Get') and describes the return data (tokens, rewards, tick sizes, trading parameters), but doesn't disclose important behavioral traits like whether it requires authentication, rate limits, error conditions, or pagination behavior for the returned data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with two sentences that each earn their place. The first sentence states the core purpose, and the second sentence provides valuable information about the return data without any wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read tool with no output schema, the description provides basic purpose and return information but lacks important context. It doesn't explain the relationship to sibling tools, doesn't provide usage guidance, and with no annotations, leaves behavioral aspects like authentication and error handling unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents the single parameter. The description adds marginal value by emphasizing this is specifically for CLOB markets and mentioning what details are returned, but doesn't provide additional parameter semantics beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get CLOB-specific market details by condition ID' specifies the verb (get) and resource (CLOB-specific market details), and distinguishes it from general market tools like get_market. However, it doesn't explicitly differentiate from all siblings like get_market_trades or get_order_book.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With many sibling tools like get_market, get_market_trades, and get_order_book, the description doesn't indicate when this CLOB-specific tool is preferred over those general market tools or what makes it unique in context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a single Polymarket event by ID or slug. Returns full event details including nested markets.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Event ID | |
| slug | No | Event slug |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool returns 'full event details including nested markets', which gives some behavioral context about the output. However, it lacks details on error handling, rate limits, authentication needs, or whether it's a read-only operation (though implied by 'get').
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the purpose and includes key details without any wasted words. It is appropriately sized for a simple retrieval tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (2 parameters, no output schema, no annotations), the description is adequate but has gaps. It explains what is returned but lacks details on behavioral aspects like error cases or performance. For a read operation with full schema coverage, it meets minimum viability but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters ('id' and 'slug') documented in the schema. The description adds minimal value by mentioning 'by ID or slug', but does not provide additional semantics beyond what the schema already covers, such as format examples or mutual exclusivity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get a single Polymarket event'), the resource ('by ID or slug'), and the scope ('full event details including nested markets'). It distinguishes itself from sibling tools like 'get_events' (plural) by specifying retrieval of a single event.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by mentioning 'by ID or slug', but does not explicitly state when to use this tool versus alternatives like 'get_events' for multiple events or 'get_market' for market-specific data. No exclusions or prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List and filter Polymarket prediction events. Supports pagination, sorting, and filtering by status/tag.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of results to return | |
| offset | No | Pagination offset | |
| order | No | Sort field: volume, liquidity, startDate, endDate, createdAt | |
| ascending | No | Sort ascending (default: false) | |
| slug | No | Filter by event slug | |
| tag | No | Filter by tag label | |
| closed | No | Filter by closed status | |
| active | No | Filter by active status |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'Supports pagination, sorting, and filtering by status/tag,' which gives some behavioral context, but doesn't cover important aspects like rate limits, authentication requirements, error behavior, or what the output looks like. For a read operation with 8 parameters, this is insufficient disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence) and front-loaded with the core purpose. Every word earns its place—there's no fluff or redundancy. It efficiently communicates the tool's capabilities in minimal space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (8 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain what an 'event' is in this context, what the return format looks like, or any prerequisites for use. For a tool with rich filtering capabilities and many sibling alternatives, more context is needed to guide proper usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents all 8 parameters. The description adds minimal value beyond the schema by mentioning filtering by 'status/tag' (which maps to 'closed', 'active', and 'tag' parameters) and 'pagination' (which maps to 'limit' and 'offset'), but doesn't provide additional semantic context. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'List and filter Polymarket prediction events.' It specifies the resource (events) and the action (list and filter). However, it doesn't explicitly differentiate this tool from its many siblings (like 'get_markets', 'search', or 'get_event'), which would require a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With 18 sibling tools including 'get_markets', 'search', and 'get_event', there's no indication of which scenarios call for this specific event-listing tool over others. It mentions capabilities but not context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the last executed trade price for a Polymarket token.
| Name | Required | Description | Default |
|---|---|---|---|
| token_id | Yes | CLOB token ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states it 'Get[s] the last executed trade price', implying a read-only operation, but does not cover aspects like rate limits, error conditions, authentication needs, or what happens if no trades exist. This leaves significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and wastes no space, making it highly concise and well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a tool that retrieves financial data. It lacks details on return format, error handling, or behavioral traits, which are crucial for an agent to use it effectively in a context with many similar sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'token_id' documented as 'CLOB token ID'. The description adds no additional meaning beyond this, such as examples or format details, but the schema provides adequate baseline information, justifying a score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'last executed trade price for a Polymarket token', making the purpose specific and understandable. However, it does not explicitly differentiate from sibling tools like 'get_price' or 'get_midpoint', which might offer similar price-related data, so it misses full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'get_price' or 'get_midpoint' from the sibling list. It lacks context on prerequisites, exclusions, or specific use cases, offering only a basic statement of function without comparative advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a single Polymarket market by ID or slug. Returns full market details including outcomes, prices, volume, and liquidity.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Market ID | |
| slug | No | Market slug |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states it 'Returns full market details including outcomes, prices, volume, and liquidity'. It misses behavioral traits like whether it's read-only (implied but not stated), error handling for invalid IDs, rate limits, or authentication needs. This is inadequate for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the purpose and key details. It avoids redundancy, but could be slightly more structured by separating usage context from return details. Overall, it's concise with minimal waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description provides basic purpose and return details but lacks completeness. It doesn't cover error cases, response format beyond a list of fields, or how to handle the optional parameters (id vs slug). For a tool with 2 parameters and rich sibling tools, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents 'id' and 'slug' parameters. The description adds no additional meaning beyond implying these are identifiers for fetching a market, matching the schema. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('a single Polymarket market'), specifying it's by 'ID or slug'. It distinguishes from sibling tools like 'get_markets' (plural) by focusing on a single market. However, it doesn't explicitly contrast with 'get_clob_market' or other specific siblings, keeping it at 4 rather than 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by mentioning 'by ID or slug', but lacks explicit guidance on when to use this versus alternatives like 'get_markets' for multiple markets or 'get_clob_market' for CLOB-specific data. No exclusions or prerequisites are stated, leaving usage context partially inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get top holders/positions for a Polymarket market. Shows the largest positions and who holds them.
| Name | Required | Description | Default |
|---|---|---|---|
| condition_id | Yes | Market condition ID | |
| limit | No | Number of holders to return | |
| offset | No | Pagination offset |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes a read operation ('Get') but doesn't mention any behavioral traits like rate limits, authentication requirements, pagination behavior beyond the offset parameter, or what format the results will be in. The description is minimal and lacks important operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two clear sentences. The first sentence states the core purpose, and the second elaborates on what information is shown. There's no wasted verbiage, though it could be slightly more structured by front-loading key information about the resource being accessed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with good schema coverage but no output schema and no annotations, the description is minimally adequate. It explains what data is retrieved but doesn't describe the return format, error conditions, or how the 'top holders' are determined (e.g., by position size, by recent activity). The absence of output schema means the description should ideally provide more context about what to expect from the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear documentation for all three parameters. The description doesn't add any parameter semantics beyond what's already in the schema - it doesn't explain what 'holders' or 'positions' mean in the Polymarket context, nor does it provide examples or additional context for the condition_id parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get top holders/positions for a Polymarket market. Shows the largest positions and who holds them.' It specifies the verb ('Get'), resource ('top holders/positions'), and scope ('Polymarket market'), but doesn't explicitly differentiate from sibling tools like 'get_market' or 'get_market_trades' which might provide different market data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_market' (which might provide general market info) or 'get_market_trades' (which might show trading activity), leaving the agent to infer usage context from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List and filter Polymarket prediction markets. Supports rich filtering by volume, liquidity, dates, tags, and status. Sort by volume descending to find the most active markets.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of results | |
| offset | No | Pagination offset | |
| order | No | Sort field: volume, liquidity, startDate, endDate, createdAt | |
| ascending | No | Sort ascending (default: false) | |
| slug | No | Filter by market slug | |
| tag | No | Filter by tag label (e.g. 'politics', 'crypto') | |
| closed | No | Filter by closed status | |
| active | No | Filter by active status | |
| liquidity_min | No | Minimum liquidity (USD) | |
| liquidity_max | No | Maximum liquidity (USD) | |
| volume_min | No | Minimum volume (USD) | |
| volume_max | No | Maximum volume (USD) | |
| start_date_min | No | Minimum start date (ISO format) | |
| start_date_max | No | Maximum start date (ISO format) | |
| end_date_min | No | Minimum end date (ISO format) | |
| end_date_max | No | Maximum end date (ISO format) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions filtering and sorting capabilities but doesn't address important behavioral aspects like whether this is a read-only operation, potential rate limits, authentication requirements, pagination behavior beyond the schema parameters, or what format the results return. The description adds some context about filtering scope but leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two sentences that efficiently communicate core functionality. The first sentence establishes the main purpose and filtering capabilities, while the second provides a usage tip. There's no wasted verbiage, though it could be slightly more structured with clearer separation of filtering versus sorting information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 16 parameters, 100% schema coverage, but no annotations and no output schema, the description is minimally adequate. It covers the basic purpose and hints at usage but doesn't provide sufficient behavioral context for a complex filtering tool. The absence of output schema means the description should ideally address what kind of data is returned, but it doesn't.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the baseline is 3. The description adds marginal value by mentioning filtering by 'volume, liquidity, dates, tags, and status' which aligns with some parameters, and suggests sorting by 'volume descending' which relates to the 'order' and 'ascending' parameters. However, it doesn't provide additional semantic context beyond what's already documented in the comprehensive schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with 'List and filter Polymarket prediction markets', specifying both the action (list/filter) and resource (prediction markets). It distinguishes from some siblings like 'get_market' (singular) but doesn't explicitly differentiate from other listing tools like 'get_events' or 'search'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage guidance by mentioning 'rich filtering' capabilities and suggesting 'Sort by volume descending to find the most active markets'. However, it doesn't explicitly state when to use this tool versus alternatives like 'search', 'get_events', or 'get_sampling_markets', nor does it provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get recent trades for a Polymarket market. Shows who traded, which side, size, price, and timestamp.
| Name | Required | Description | Default |
|---|---|---|---|
| condition_id | Yes | Market condition ID | |
| limit | No | Number of trades to return | |
| offset | No | Pagination offset |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the data returned (who traded, side, etc.) but doesn't cover critical aspects like whether this is a read-only operation, potential rate limits, authentication needs, or how recent 'recent' is. For a tool with no annotations, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Get recent trades for a Polymarket market') and adds specific details about the data returned. There's no wasted text, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (3 parameters, no output schema, no annotations), the description is incomplete. It doesn't explain the return format, error conditions, or behavioral traits like pagination behavior. Without annotations or an output schema, the agent lacks sufficient context to use this tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents the parameters (condition_id, limit, offset). The description adds no additional meaning beyond implying that 'condition_id' identifies a market and that results are paginated via limit/offset. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('recent trades for a Polymarket market'), specifying what data is retrieved (who traded, side, size, price, timestamp). However, it doesn't explicitly differentiate from sibling tools like 'get_last_trade_price' or 'get_order_book', which also provide trade-related data, so it lacks sibling differentiation for a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, such as needing a valid condition_id, or compare it to siblings like 'get_last_trade_price' (which might give a single price) or 'get_order_book' (which shows pending orders). This leaves the agent with minimal context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the midpoint price for a Polymarket token (average of best bid and ask).
| Name | Required | Description | Default |
|---|---|---|---|
| token_id | Yes | CLOB token ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states what the tool calculates but doesn't disclose behavioral traits like whether it's a read-only operation, potential rate limits, authentication needs, error conditions, or what format the result returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's appropriately sized and front-loaded with the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with one parameter and no output schema, the description is minimally adequate but lacks important context about return format, error handling, and behavioral characteristics that would help an agent use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the token_id parameter as 'CLOB token ID'. The description doesn't add any parameter-specific information beyond what the schema provides, maintaining the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get'), the resource ('midpoint price for a Polymarket token'), and the calculation method ('average of best bid and ask'). It distinguishes from siblings like get_price or get_order_book by specifying the midpoint calculation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when the midpoint price is needed, but doesn't explicitly state when to use this tool versus alternatives like get_price or get_order_book. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full order book (bids and asks) for a Polymarket token. Shows market depth and liquidity at each price level.
| Name | Required | Description | Default |
|---|---|---|---|
| token_id | Yes | CLOB token ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions what data is returned (bids, asks, depth, liquidity) but lacks behavioral details such as rate limits, authentication requirements, pagination, or error conditions. This is a significant gap for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that efficiently conveys the tool's purpose and key features without unnecessary words. It is front-loaded with the core action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description provides basic purpose but lacks completeness for a data retrieval tool. It doesn't cover response format, error handling, or performance characteristics, leaving gaps in understanding how to interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the single parameter 'token_id' as a 'CLOB token ID'. The description adds no additional parameter semantics beyond implying it's for a Polymarket token, which aligns with the schema. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get'), the resource ('full order book for a Polymarket token'), and specific details ('bids and asks', 'market depth and liquidity at each price level'). It distinguishes this tool from siblings like get_order_book_summary or get_last_trade_price by emphasizing comprehensive depth data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing detailed order book data for a specific token, but it doesn't explicitly state when to use this versus alternatives like get_order_book_summary (for aggregated data) or get_market_trades (for transaction history). No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get order books for multiple Polymarket tokens in a single batch request.
| Name | Required | Description | Default |
|---|---|---|---|
| token_ids | Yes | Array of CLOB token IDs |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states it's a batch request. It lacks details on rate limits, permissions, response format, pagination, or error handling for a tool that likely queries financial data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words, clearly front-loading the core purpose. Every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is insufficient. It doesn't explain what an 'order book' contains, the response structure, or any behavioral traits like latency or data freshness, leaving significant gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'token_ids' well-documented in the schema. The description adds no additional meaning beyond implying these are for 'Polymarket tokens,' which is already suggested by the tool name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get order books') and resource ('multiple Polymarket tokens'), specifying it's a batch request. However, it doesn't distinguish this from the sibling 'get_order_book' tool, which presumably handles single tokens.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'batch request' but provides no explicit guidance on when to use this vs. the singular 'get_order_book' tool or other market-related siblings. No alternatives, prerequisites, or exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a summarized order book for a Polymarket token: best bid, best ask, and spread.
| Name | Required | Description | Default |
|---|---|---|---|
| token_id | Yes | CLOB token ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states what data is returned but doesn't mention important behavioral aspects like rate limits, authentication requirements, error conditions, or whether this is a real-time or cached view. The description is minimal and lacks operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the core purpose without any wasted words. It's appropriately front-loaded with the main action and delivers essential information in minimal space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with one well-documented parameter and no output schema, the description adequately covers what the tool does. However, it lacks context about the return format, data freshness, or how this differs from similar tools in the server, leaving some gaps for an agent to understand optimal usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'token_id' well-documented as 'CLOB token ID'. The description doesn't add any additional parameter semantics beyond what the schema provides, so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get a summarized order book') and specifies the resource ('for a Polymarket token'), including the key data points returned (best bid, best ask, and spread). However, it doesn't explicitly differentiate this tool from its sibling 'get_order_book' or 'get_order_books', which likely provide more detailed order book data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get_order_book' or 'get_order_books'. It doesn't mention prerequisites, exclusions, or specific contexts where this summary view is preferred over more detailed data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current price for a Polymarket token on the given side (buy or sell). Returns the best available price.
| Name | Required | Description | Default |
|---|---|---|---|
| token_id | Yes | CLOB token ID (from market's clobTokenIds) | |
| side | Yes | Order side: buy or sell |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'best available price' but lacks details on rate limits, authentication requirements, error handling, or whether this is a read-only operation. For a financial data tool, this omission is significant.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It front-loads the core purpose and includes the return value, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (fetching financial data), no annotations, and no output schema, the description is minimally adequate. It covers the basic purpose but lacks details on behavior, error cases, or output format, which are important for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description adds no additional meaning beyond what the schema provides, such as explaining 'token_id' sources or 'side' implications in market context. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get the current price') and resource ('Polymarket token'), specifying the domain (Polymarket) and what is returned ('best available price'). However, it doesn't explicitly differentiate from siblings like 'get_last_trade_price' or 'get_midpoint', which might provide similar price-related data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'get_last_trade_price' or 'get_midpoint'. The description mentions 'best available price' but doesn't clarify if this is for real-time quotes, order book analysis, or how it differs from other price-fetching tools in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get currently sampled Polymarket markets that are eligible for liquidity rewards.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves data ('get'), implying a read-only operation, but doesn't specify details like rate limits, authentication needs, or what 'currently sampled' entails (e.g., timeframes or update frequency). This leaves gaps for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the key information: the action, resource, and key qualifiers ('currently sampled', 'eligible for liquidity rewards'). There is no wasted text, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (simple retrieval with no parameters) and lack of annotations or output schema, the description is minimally adequate. It specifies what is retrieved but lacks details on behavior, output format, or usage context, leaving some gaps for the agent to navigate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description doesn't add parameter semantics, but with no parameters, this is acceptable, aligning with the baseline of 4 for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to retrieve ('get') specific markets ('Polymarket markets') that are currently sampled and eligible for liquidity rewards. It uses a specific verb and resource, though it doesn't explicitly distinguish from siblings like 'get_sampling_simplified_markets' beyond the 'eligible for liquidity rewards' qualifier.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites, exclusions, or compare it to sibling tools like 'get_markets' or 'get_sampling_simplified_markets', leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get simplified view of currently sampled Polymarket markets.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Get' implies a read operation, the description doesn't address important behavioral aspects like whether this requires authentication, rate limits, what 'simplified' means operationally, or what format the response takes. It provides minimal behavioral context beyond the basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point with zero wasted words. It's appropriately sized for a zero-parameter tool and front-loads the essential information about what the tool does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read operation with no output schema, the description provides the basic purpose but lacks important context. It doesn't explain what 'simplified' means, what data is included/excluded, or what the response format looks like. Given the absence of both annotations and output schema, more completeness would be helpful for an agent to understand what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters with 100% schema description coverage, so the baseline is 4. The description appropriately doesn't waste space discussing parameters that don't exist, though it could potentially mention that no filtering or configuration options are available for this simplified view.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get simplified view') and resource ('currently sampled Polymarket markets'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from its sibling 'get_sampling_markets' - the 'simplified' qualifier hints at a difference but doesn't clearly explain what makes it simpler.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With multiple market-related sibling tools (get_market, get_markets, get_sampling_markets, etc.), there's no indication of when this 'simplified view' is preferable or what distinguishes it from other market retrieval tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Polymarket event series (grouped collections of related events).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of results | |
| offset | No | Pagination offset |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states it's a list operation, implying read-only behavior, but doesn't cover critical aspects like pagination behavior (implied by limit/offset parameters but not explained), rate limits, authentication needs, error conditions, or what the output looks like (e.g., list of series objects). This leaves significant gaps for an agent to use it correctly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('List Polymarket event series') and adds clarifying context without waste. Every word earns its place, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a list operation with pagination), lack of annotations, and no output schema, the description is incomplete. It doesn't explain behavioral traits like pagination, output format, or error handling, which are essential for an agent to use it effectively. The description alone leaves too many unknowns for reliable tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for limit and offset parameters. The description adds no additional parameter semantics beyond what the schema provides—it doesn't explain how limit/offset interact with the listing or typical values. Since the schema does the heavy lifting, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and resource ('Polymarket event series'), with additional clarifying context about what series are ('grouped collections of related events'). It distinguishes from siblings like get_events or get_markets by specifying series rather than individual events or markets. However, it doesn't explicitly contrast with get_series_by_id, which might fetch a specific series by ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to prefer get_series over get_events or get_markets, nor does it reference the sibling get_series_by_id for fetching a specific series. There's no context about prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a specific Polymarket event series by ID, including all events in the series.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Series ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it's a read operation ('Get'), but doesn't disclose behavioral traits like authentication needs, rate limits, error handling, or what happens if the ID is invalid. For a tool with no annotation coverage, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose. Every word earns its place, with no redundancy or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter, no output schema, no annotations), the description is minimally adequate. It covers the purpose but lacks behavioral details that would be helpful for an agent, such as response format or error conditions. Without annotations, it should do more to compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the single parameter 'id' documented as 'Series ID'. The description adds no additional semantic context beyond this, such as format examples or where to find IDs. With high schema coverage, the baseline is 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get'), the resource ('a specific Polymarket event series'), and the scope ('including all events in the series'). It distinguishes itself from sibling tools like 'get_series' (likely listing multiple series) and 'get_event' (single event rather than series).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need a specific series by ID with its events, but doesn't explicitly state when to use this versus alternatives like 'get_series' (for listing) or 'get_event' (for individual events). No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available sports on Polymarket (e.g. NBA, NFL, EPL, MLB).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes a read operation ('List'), which implies it's non-destructive, but doesn't mention any constraints like rate limits, authentication needs, or what the return format looks like. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('List available sports on Polymarket') and adds helpful examples without unnecessary elaboration. Every word earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is adequate but minimal. It states what the tool does but lacks details on return values, error handling, or usage context. For a basic list operation, this is the minimum viable, leaving room for improvement in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the input requirements. The description doesn't need to add parameter details, and it appropriately avoids discussing parameters, maintaining a baseline score of 4 for tools with no parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('List') and resource ('available sports on Polymarket'), and provides concrete examples (NBA, NFL, EPL, MLB). It doesn't explicitly differentiate from sibling tools like 'get_sports_teams' or 'get_events', but the focus on sports listing is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get_sports_teams' or 'get_events', nor does it mention any prerequisites or context for usage. It simply states what the tool does without indicating when it's appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List teams for a given sport on Polymarket.
| Name | Required | Description | Default |
|---|---|---|---|
| sport | No | Sport code (e.g. 'nba', 'nfl', 'epl') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states it's a list operation, implying read-only behavior, but doesn't cover aspects like rate limits, authentication needs, pagination, or error handling. This is a significant gap for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. Every part of the sentence earns its place by specifying the action, resource, and context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what the output looks like (e.g., list format, fields), error cases, or behavioral traits. For a tool with no structured support, this leaves significant gaps for an AI agent to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the single parameter 'sport' documented as 'Sport code (e.g. 'nba', 'nfl', 'epl')'. The description adds no additional meaning beyond this, such as explaining what 'Polymarket' is or providing more context on sport codes. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List teams') and the resource ('for a given sport on Polymarket'), which provides a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'get_sports' or 'get_events', which might be related but serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context for usage, or exclusions, leaving the agent to infer based on the tool name and parameters alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available Polymarket category tags. Use these tags to filter markets and events.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool lists tags but doesn't disclose behavioral traits like whether it's read-only, how data is returned (e.g., format, pagination), rate limits, or authentication needs. The description is minimal and lacks essential operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with zero waste: the first states the purpose, and the second provides usage context. It's front-loaded and efficiently conveys necessary information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no annotations, no output schema), the description is adequate but minimal. It covers purpose and usage but lacks details on behavior, output format, or error handling, which could be helpful for an agent despite the low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate here, earning a baseline score of 4 for adequately handling the absence of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and resource ('all available Polymarket category tags'), making the purpose unambiguous. It distinguishes this tool from siblings by focusing on tags rather than markets, events, or other data, though it doesn't explicitly contrast with specific sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: to obtain tags for filtering markets and events. It implicitly suggests this is a prerequisite step for filtering operations, but doesn't explicitly state when not to use it or name specific alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the minimum tick size (price increment) for a Polymarket token.
| Name | Required | Description | Default |
|---|---|---|---|
| token_id | Yes | CLOB token ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves data ('Get'), implying a read-only operation, but doesn't mention any behavioral traits like error handling, rate limits, authentication needs, or what happens with invalid token IDs. This is a significant gap for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose with zero wasted words. It's appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., the tick size value format, possible errors, or example output), leaving the agent with gaps in understanding how to use the result. For a data retrieval tool in a complex domain like financial markets, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description doesn't add any meaning beyond the input schema, which has 100% coverage for the single parameter 'token_id'. The schema already describes it as a 'CLOB token ID', so the description provides no additional context about parameter usage or semantics. This meets the baseline of 3 when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('minimum tick size for a Polymarket token'), making the purpose specific and understandable. However, it doesn't distinguish this tool from its many siblings (e.g., get_price, get_market, get_order_book), which all retrieve different data about Polymarket tokens, so it doesn't achieve full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools that retrieve related market data (e.g., get_price, get_market, get_order_book), there's no indication of when tick size is needed specifically, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full-text search across Polymarket events, markets, and profiles. Use this to find markets on any topic.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query (e.g. 'election', 'bitcoin', 'AI') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the tool performs 'full-text search' but doesn't describe key behaviors such as search result format, pagination, rate limits, authentication needs, or error handling. For a search tool with zero annotation coverage, this leaves significant gaps in understanding how it operates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences that are front-loaded and efficient: the first states the tool's purpose and scope, and the second provides usage intent. There is no wasted text, making it appropriately concise and well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity as a search function with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., result format, limitations) and doesn't compensate for the absence of structured data. For a tool that likely returns varied search results, more context is needed to guide effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'query' documented as 'Search query (e.g. 'election', 'bitcoin', 'AI')' in the schema. The description adds no additional parameter information beyond what the schema provides, such as query syntax or examples. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs 'full-text search across Polymarket events, markets, and profiles' with the specific purpose to 'find markets on any topic.' This provides a clear verb ('search') and resource scope ('events, markets, and profiles'), though it doesn't explicitly differentiate from sibling tools like 'get_markets' or 'get_events' that might retrieve specific items rather than search broadly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating 'Use this to find markets on any topic,' which suggests it's for general discovery, but it doesn't provide explicit guidance on when to choose this over sibling tools like 'get_markets' (which might list all markets) or 'get_events' (which might list all events). No alternatives or exclusions are mentioned, leaving usage context somewhat vague.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0get_clob_marketget_eventget_eventsget_last_trade_priceget_marketget_market_holdersget_market_tradesget_marketsget_midpointget_order_bookget_order_book_summaryget_order_booksget_priceget_sampling_marketsget_sampling_simplified_marketsget_seriesget_series_by_idget_sportsget_sports_teamsget_tagsget_tick_sizesearchMost tools have distinct purposes, but there is notable overlap between get_event/get_market and get_events/get_markets, which could cause confusion about when to use each. Additionally, get_order_book, get_order_book_summary, and get_midpoint all relate to order book data, creating some redundancy in the set.
All tool names follow a consistent snake_case pattern with a clear 'get_' prefix, making them predictable and easy to parse. The naming scheme is uniform across all 22 tools, with no deviations in style or structure.
With 22 tools, the count is borderline high for a prediction market server, leaning toward heavy. While Polymarket has a complex domain, the tool set includes multiple similar tools (e.g., order book variants) that could have been consolidated, making it feel slightly over-scoped.
The tool set provides comprehensive read-only coverage for exploring Polymarket data, including events, markets, trades, order books, and metadata. However, it lacks write operations (e.g., placing trades or managing positions), which are core to a trading platform, leaving a minor but notable gap for full agent interaction.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Live prediction markets: Polymarket + Kalshi prices, odds, order books. Pay-per-call USDC, no key.
Live prediction-market odds, volume and movers across 8 platforms. Read-only, no auth.
Order-book depth & history for Polymarket, Kalshi & Limitless. Keyless demo, key for full access.
Polymarket MCP — prediction-market data via Gamma + CLOB public APIs.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/yigitabi5444/yigit_polymarket_mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
