polymarket-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct data item (event, market, order book, price history, user activity, etc.) with precise descriptions that show clear differences. No two tools overlap in functionality.
Naming Consistency5/5
All tools follow a consistent 'polymarket_verb_noun' pattern, e.g., get_event, list_markets, search. Verbs like get, list, search are used logically and uniformly.
Tool Count5/5
14 tools cover all major read operations for a prediction market: browsing, searching, detailed views, prices, order books, user data. This is well-scoped for the domain.
Completeness5/5
The tool set provides comprehensive coverage for querying Polymarket: event/market discovery, live prices, historical data, order books, and user positions/value. No obvious gaps for read-only access.
Average 4.1/5 across 14 of 14 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 commits in the last 12 weeks
- Last stable release on June 17, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds that results are sorted by 24h volume and are active/open, which is useful but does not go beyond the annotations' safety profile.
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?
The description is a single concise sentence that front-loads the purpose with 'What's hot right now,' containing no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple input schema and existing output schema, the description provides the core behavior but lacks details on pagination, maximum limit, or how results relate to other tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'limit' has a default of 10 but is not mentioned or explained in the description; schema coverage is 0%, so the description misses the chance to clarify how limit affects results.
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?
The description clearly states the tool returns active, open markets sorted by 24h volume descending using the phrase 'What's hot right now,' effectively distinguishing it from sibling tools like polymarket_list_markets.
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?
The description implies usage for trending markets but does not explicitly state when to use this tool versus alternatives like polymarket_list_markets or polymarket_search, nor provides any exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and openWorldHint. The description adds value by specifying that outcomes/prices/tokenIds are parsed, providing behavioral context beyond the annotations.
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?
The description is extremely concise: three sentences, no redundant information. Each sentence adds value—purpose, usage hint, and parameter guidance.
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?
Given the presence of an output schema, the description covers the essential aspects: what is returned (child markets with parsed data), how to identify (id/slug), and when to use. It lacks mention of any limits or edge cases, but is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by stating 'Provide an id or a slug,' clarifying that either can be used as an identifier. However, it does not detail behavior when both are provided or format requirements.
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?
The description clearly states the tool retrieves event details with all child markets, including parsed outcomes/prices/tokenIds. It distinguishes from siblings like 'polymarket_get_market' by focusing on events with multiple markets.
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?
It mentions usefulness for multi-candidate/neg-risk events, which implies a use case but does not explicitly state when not to use or provide alternatives. The guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds that limit is capped at 20 by the API, which is useful, but otherwise provides no further behavioral context (e.g., pagination, data freshness). Adequate but minimal beyond annotations.
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?
The description is a single sentence followed by a clear parameter list. No redundant information, all sentences add value. Efficient and well-structured.
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?
For a simple read-only tool with two parameters and an existing output schema, the description covers the core functionality and parameter details. It does not explain the output structure, but the output schema presumably does. Slightly incomplete regarding edge cases or behavior when API returns errors.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully explains both parameters: condition_id as 'on-chain condition id' and its mapping to the Data API's market param, and limit as 'Top-N holders per token, capped at 20.' This adds meaningful context beyond the bare schema types.
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?
The description clearly states 'Top holders per outcome token for a market,' specifying the resource (holders) and action (retrieve top ones). It distinguishes from sibling tools like polymarket_get_order_book and polymarket_get_market by focusing on holders per outcome token.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description only lists parameters but does not explain scenarios or exclusions. Given multiple related tools, explicit usage direction is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is clear. The description adds that the value is in USDC and aggregates positions, but does not discuss edge cases (e.g., empty wallet, network errors). No contradiction with annotations.
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?
The description is extremely concise: two sentences for the tool and one for the parameter. No wasted words or redundant information. Every sentence serves a purpose.
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?
For a simple value retrieval tool with one parameter and an output schema (per context signals), the description is sufficiently complete. It states what is returned (total current value in USDC). It does not explain how to interpret the output, but the presence of an output schema mitigates this need.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no description in input schema), so the description must compensate for the single 'wallet' parameter. It specifies 'EVM address (0x...)' which clarifies format and prefix. This adds meaningful information beyond the schema's title and type.
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?
The description explicitly states 'Total current value (USDC) of a wallet's Polymarket positions.' This uses a specific verb ('get' implied) and resource (value of positions), clearly differentiating it from siblings like polymarket_get_user_positions (which returns individual positions) or polymarket_get_user_activity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like polymarket_get_user_positions or polymarket_get_market. The description does not mention prerequisites, limitations, or when not to use it. Given the number of sibling tools, explicit differentiation would be beneficial.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations by disclosing that the 'active' filter is 'best-effort' and under-documented, and notes the 'volume_num_min' parameter's naming nuance. No contradictions with annotations (readOnlyHint=true, openWorldHint=true).
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 description starts with a clear summary sentence and lists arguments in a readable bullet-like format. It is appropriately sized for 13 parameters, though the 'Args:' section could be slightly more concise.
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?
Given the tool's complexity (13 parameters), presence of an output schema, and annotations, the description covers essential use cases and quirks. It may lack format details for some parameters but is sufficient for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description explains most parameters including their purpose and examples (e.g., order sort fields, date bounds as ISO-8601). This compensates well, though some parameters like 'tag_id' are only described as 'numeric tag id' which is minimal.
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?
The description clearly states 'Browse and filter markets' and explains default behavior. However, it does not explicitly differentiate from sibling tools like 'polymarket_search' or 'polymarket_trending_markets', so the purpose is clear but lacks distinction from alternatives.
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?
The description implies usage by specifying defaults (active, open markets by 24h volume) but does not provide explicit guidance on when to use this tool versus alternatives, nor does it state prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it as readOnlyHint=true (safe read) and openWorldHint=true (dynamic data). The description adds valuable behavioral context: 'Gamma's cached price can lag the live book — `live_midpoint` is the freshest value,' which warns about potential staleness. No contradictions with annotations.
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?
The description is three sentences: a clear headline, a process explanation, and input guidance. Every sentence adds value without redundancy or wasted words.
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?
Given the tool's simplicity (2 optional params, no required) and the presence of an output schema, the description adequately covers input behavior, caching notes, and the resolution process. It is sufficiently complete for an AI agent to use.
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 0%, so the description must compensate. It explains that `slug` is preferred and `query` is free-text for searching, and it will pick the most liquid match. This adds meaning beyond the schema but could be more specific about format or constraints.
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?
The description clearly states it provides 'Live odds for one market in a single call' and positions itself as 'the recommended starting point.' It explains the mechanism (resolves market by slug or free text, fetches CLOB midpoint) and differentiates from siblings by being a single-call solution.
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?
The description advises to 'Provide a slug (preferred) or a free-text query' and mentions that Gamma's cached price can lag. However, it does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. Description adds context by listing specific activity types (TRADE, SPLIT, etc.), enhancing transparency. Does not describe pagination or ordering but provides reasonable additional behavioral context.
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?
Highly concise: one sentence for purpose followed by a clear parameter list. No redundant or unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Input parameters are well-covered, but given that an output schema exists (as per context signals), the description does not hint at the structure of returned data. For a user activity tool, knowing output fields (timestamps, market details) would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, description compensates by explaining wallet as EVM address, limit as 1-100 with default 20, and type as optional with examples. Adds meaning beyond schema, though formal enum for type is missing.
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?
Description clearly states 'Recent on-chain activity (trades, splits, merges, redeems...) for a wallet,' providing a specific verb and resource. Distinguishes from sibling tools like polymarket_get_user_positions and polymarket_get_user_value by focusing on activity types.
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?
Implies usage for fetching recent activity but does not explicitly state when to use this tool versus alternatives like polymarket_get_user_positions or polymarket_get_user_value. No when-not or exclusions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds that results are sorted descending by default and provides the range for limit, but does not detail behavior for invalid wallets, rate limits, or response structure beyond what the output schema may provide.
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?
The description is extremely concise: a one-line summary followed by a structured Args block. Every sentence adds value with no redundancy. The important information (purpose and parameter details) is front-loaded.
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?
Given the presence of an output schema and the tool's simplicity (read-only, single wallet), the description covers the key aspects. However, it could briefly note that only current holdings are retrieved (not historical) or that the wallet must exist, but overall is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates: 'wallet' is explained as an EVM address with example format, 'limit' includes range (1-100) and default (20), and 'sort_by' lists all enum values with default and notes descending order. This is excellent documentation.
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?
The description clearly states it retrieves 'Public current holdings for a wallet address (0x...)', specifying the resource (holdings) and the scope (by wallet). This directly distinguishes it from sibling tools like 'get_user_activity' or 'get_user_value', which 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives. While the purpose is clear, there is no mention of exclusions or context that would help an agent decide between related tools such as 'get_user_activity' or 'get_user_value'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds behavioral context by explaining that events use specific parameter names (volume_min/liquidity_min) and that the structure is similar to list_markets. No contradictions.
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?
The description is two sentences plus a note, no unnecessary words. It is front-loaded with purpose and immediately provides relevant differentiation. Highly efficient.
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?
Given the existence of an output schema and annotations, the description covers essential usage: what events are, filtering capabilities, and parameter differences. It assumes knowledge of list_markets, which may be a slight gap, but overall sufficient for a list/filter tool.
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 0%, placing burden on description. The description clarifies the naming nuance for volume_min and liquidity_min but does not explain the other 11 parameters (e.g., start_date_min, tag_id). Some benefit, but insufficient for full parameter understanding.
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?
The description clearly states 'Browse and filter events (groups of related markets)', identifying the verb (browse/filter) and resource (events). It distinguishes from sibling list_markets by noting 'Same shape as list_markets' and highlighting a key difference in parameter naming.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on parameter naming differences between events and markets, aiding correct usage. It implies when to use this tool vs list_markets by defining events as 'groups of related markets', though it could more explicitly state when to choose one over the other.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it as readOnly and openWorld. The description adds useful behavioral details: token_id is a CLOB token id, downsampling to ≤500 points, and that interval defaults to '1d'. No contradiction with annotations.
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 description is somewhat lengthy but well-structured: purpose first, then token_id note, then parameter details, then downsampling. Every sentence adds value, though it could be slightly condensed.
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?
Given the moderate complexity (5 params with interplay), the description covers all necessary aspects: parameter behavior, defaults, edge cases (downsampling), and result flag. Output schema exists, so return values need no explanation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining each parameter: token_id, interval values, fidelity, and start_ts/end_ts. It provides context on their interactions and defaults.
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?
The description clearly states it provides 'Historical probability time-series for one outcome token', directly indicating the tool's function and output. It distinguishes itself from sibling tools like polymarket_get_live_price by focusing on historical data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains how to use parameters like interval and start_ts/end_ts, and notes that interval is ignored when explicit time bounds are given. It does not explicitly mention when not to use this tool, but the purpose is clear enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description reinforces a safe read operation. It adds behavioral context by listing returned fields and emphasizing freshness over cached data. No contradictions or missing behavioral traits beyond annotations.
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?
The description is extremely concise, consisting of two sentences. It front-loads the core purpose in the first sentence and adds critical detail in the second. No redundant or irrelevant information.
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?
Given there is one parameter and an output schema exists, the description adequately covers what the tool returns and its freshness advantage. It could be slightly more explicit about its relationship to sibling tools, but overall it is complete for an agent to understand when and how to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining that token_id is a CLOB token id (one of a market's clobTokenIds) and explicitly clarifying it is NOT a slug or conditionId. This adds crucial meaning beyond the schema type.
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?
The description clearly states the tool returns 'live odds' for one outcome token from the CLOB, specifies the token_id parameter is a CLOB token id (not slug or conditionId), and lists the returned fields (midpoint, best bid/ask, spread, probability_pct). It distinguishes itself from related tools like Gamma's cached prices, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool by stating it provides 'fresher than Gamma's cached prices', suggesting it is for real-time needs. However, it does not explicitly mention when not to use it or provide direct alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and openWorldHint. The description adds that the tool returns 'full detail' and clarifies the id parameter's dual interpretation (numeric vs 0x as condition_id). This enhances transparency beyond annotations.
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 description is concise with one clear sentence followed by structured param explanations. Minor improvement could be formatting the args as a list, but it remains efficient and front-loaded.
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?
Given the presence of an output schema (covering return values) and annotations, the description adequately covers usage, parameter semantics, and the tool's scope. No critical gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description thoroughly explains each parameter with examples and nuance (e.g., 'A "0x..." value is treated as a condition id'). This provides essential meaning missing from the schema.
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?
The description clearly states the tool 'Resolve[s] one market in full detail', specifying three alternative identifiers (id, slug, condition_id). This distinguishes it from sibling tools like polymarket_list_markets which return multiple markets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'provide one' among the three parameters, implying mutual exclusivity. It lacks explicit guidance on when not to use this tool versus alternatives, but the purpose and parameter choices make it clear for a single-market lookup.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. Description adds valuable behavioral context: each returned event includes markets with parsed outcomes and probabilities. No contradiction.
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?
Concise and well-structured: purpose, usage context, return content, then parameter list. Every sentence adds value with no redundancy.
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?
Complete for a search tool with good annotations and output schema. Covers purpose, usage, parameters, and return structure. No gaps given the presence of output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description explains each parameter thoroughly: query with examples, limit_per_type cap, events_status filter, keep_closed_markets default. This adds significant meaning beyond the schema.
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?
Clearly describes tool as 'natural-language search across Polymarket events, markets, and tags'. Distinguishes from siblings (get_tool, list_tool) by being the primary entry point for free-text queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states it's the primary entry point for 'find me markets about X', giving clear context. Does not explicitly mention when not to use or list alternatives, but the context implies for specific known IDs the get_tools are appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true and openWorldHint=true. The description adds that it provides best bid/ask, midpoint, spread, top levels, and that prices/sizes are parsed to floats. No contradictions; behavioral traits are fully consistent.
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 succinct sentences that front-load core purpose and immediately explain key parameters. No wasted words; every sentence earns its place.
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?
Given the presence of an output schema (covers return values), the description fully covers purpose, parameters, and behavior. It is complete for a simple order book tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds meaningful context: token_id is 'a CLOB token id' and depth 'caps the number of price levels per side (default 10, max 50)'. This adds value beyond the schema's type declarations.
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?
The description clearly states 'Live order book for one outcome token: best bid/ask, midpoint, spread, top levels.' It uses a specific verb and resource, and distinguishes from siblings like get_live_price (single price) or get_market (market details).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing order book depth for a token, provides context for token_id and depth parameters, and the sibling list helps differentiate. However, it does not explicitly state when not to use this tool or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![polymarket-mcp MCP server](https://glama.ai/mcp/servers/fzlzjerry/polymarket-mcp/badges/card.svg)](https://glama.ai/mcp/servers/fzlzjerry/polymarket-mcp)

Score Badge

Copy to your README.md:

[![polymarket-mcp MCP server](https://glama.ai/mcp/servers/fzlzjerry/polymarket-mcp/badges/score.svg)](https://glama.ai/mcp/servers/fzlzjerry/polymarket-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/fzlzjerry/polymarket-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server