MCP server for Polymarket prediction markets. Provides tools to search, browse, and analyze prediction markets and events on Polymarket.
17 tools with consistent naming (verb_noun convention), comprehensive descriptions (all 50+ chars), and explicit JSON Schema via Zod. All tools are READ_ONLY search/list/get operations. Schemas are well-defined with proper types, constraints, and descriptions. No input validation gaps detected in schema definitions. Output is formatted as text (markdown), which is reasonable for discovery tools but lacks structured JSON. Error handling is present but generic ('Error fetching X: {message}'). No tool annotations (readOnlyHint, idempotentHint) despite all being read-only. Missing documented output schemas in descriptions, LLMs do not know the exact fields returned.
Get markets closing soon. Returns markets that are approaching their resolution dates, sorted by closing time.
Get competitive markets. Returns markets where the outcomes are closely contested (competitive pricing).
Get detailed information about a specific event by its slug. Returns full event details including all related markets, tags, and description.
Get events filtered by category. Returns events in the specified category with full details about markets and trading information.
Get events filtered by series. Returns events in the specified sports/entertainment series (e.g., NBA, NFL, UFC).
Get events filtered by tag. Returns events associated with a specific tag.
Tool annotations missing: All 17 tools are READ_ONLY and should declare readOnlyHint=true in their definitions. This enables agents to optimize call ordering and understand safety guarantees without reading descriptions.
Output schemas not documented: Tool descriptions do not specify what fields are returned or their types. E.g., list_markets returns 'market information including questions, outcomes, prices, volume, and liquidity' (prose), but no formal output schema. LLMs cannot plan downstream calls without knowing exact field names.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 60 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 10 | - | v1 |
Get high liquidity markets. Returns markets with the most available liquidity for trading.
Get detailed information about a specific market by its ID. Returns market details including outcomes, prices, volume, liquidity, and trading data.
Get most engaged markets. Returns markets with the highest comment/discussion activity.
Get order book for a market. Returns bid and ask orders with prices and sizes, plus market microstructure data.
Get price history for a market. Returns historical price data with statistics including high, low, average, and current prices.
Get recently resolved markets. Returns markets that have recently closed and been resolved.
Get trending prediction markets. Returns markets sorted by the specified metric (volume or price change).
List prediction market events. Returns event information including volume, liquidity, market count, and descriptions.
List prediction markets from Polymarket. Returns market information including questions, outcomes, prices, volume, and liquidity.
Search for prediction market events by keyword. Events group related markets together. This is useful for finding markets on specific topics.
Search for prediction markets by keyword. Searches market questions, descriptions, and events. This searches through events for comprehensive coverage.
Generic error handling: All tools return 'Error fetching X: {errorMessage}' with isError=true. No recovery guidance. If a market not found error occurs, the LLM has no suggestion (e.g., 'try search_markets() instead'). Errors should categorize retryability and guide next steps.
Text-based output instead of structured JSON: All tools return markdown-formatted text (e.g., '# Polymarket Markets\n\nFound X markets.\n\n...'). This forces LLMs to parse unstructured prose, wasting tokens and inviting parsing errors. Structured JSON (array of market objects with typed fields) would enable reliable downstream tool chaining.
Pagination offset-based without next_cursor: Tools like list_markets, list_events, and search_* use offset-based pagination. Code returns 'Next offset: {nextOffset}' as prose in the response, which is unreliable for LLM parsing. Should return a standardized next_cursor or offset in a structured field that agents can reliably extract.