PolyOrderbooks MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| POLYORDERBOOKS_API_KEY | Yes | Your API key. The server exits at startup if this is missing, rather than failing later on the first tool call. | |
| POLYORDERBOOKS_BASE_URL | No | Overrides the API base URL. Defaults to https://api.polyorderbooks.com. Only needed for a self-hosted or staging deployment. | https://api.polyorderbooks.com |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| search_marketsA | Find Polymarket markets by keyword. Start here — the other tools need a market slug, and slugs are not guessable. Coverage is Polymarket crypto markets: up/down contracts at 5m, 15m and 4h, price thresholds like "bitcoin-above-80k", and related event markets. Resolved markets are excluded unless include_closed is true, which is usually what you want for historical analysis. For a whole family of markets rather than one, search_series is more reliable than guessing slug patterns here. |
| search_seriesA | A series is a recurring family of markets — "btc-up-or-down-5m" is every BTC 5-minute up/down contract ever created. Use this when the question is about a kind of market rather than a specific one: it is more reliable than guessing at slug patterns with search_markets. Take the series slug, then use search_events to find its individual rounds. |
| search_eventsA | An event groups markets that resolve together — "what-price-will-solana-hit-august-17-23-2026" holds every price threshold for that week, and "btc-updown-5m-1787685000" is one 5-minute round. Use this to find the set of related markets to compare, then search_markets to get the markets themselves. Date filters are useful here: events carry an end_date. |
| get_marketA | Full detail for a single market by slug or id, including its outcome tokens, resolution status and winning outcome. Use this to get token ids before calling the token-level tools. |
| get_order_book_historyA | Full L2 bid and ask ladders over time for a market — every price level and the size resting at each. This is data Polymarket does not archive: its /book endpoint returns only the current state, so depth exists only where it was captured live. One thing to expect when reading the results: binary markets go one-sided as they resolve. In the final minute of a 5-minute market most snapshots have an empty bid or ask side, because nobody offers the losing outcome. That is real market behaviour rather than missing data, so guard before indexing the first level of a ladder. Responses are large. Keep the window narrow or the resolution coarse: a one-hour window at 1s is 3,600 buckets per token, and a market has two tokens. |
| get_price_historyA | Price series per outcome token over time. Prices are probabilities in [0, 1]. Polymarket serves its own price history down to 1-minute buckets and that is free — use this tool when you need finer than a minute, or when you want prices aligned to the same timeline as order book depth. For 1-minute or coarser history alone, Polymarket's public API is equivalent. |
| get_market_metricsA | Derived market quality metrics — spread, liquidity and volume — as a time series. Cheaper than pulling full order books when the question is about market quality rather than specific price levels. Note that spread is only meaningful while both sides of the book are populated, which stops being true near settlement. |
| get_usageA | Current plan, rate limits, history window and requests used. Call this when a request fails with a limit error, or before planning a large extraction, to see what the key is allowed to do. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 8 tools
Each tool targets a distinct entity or data type: search_markets, search_series, and search_events operate at different granularities of Polymarket structure, and the get_* tools cleanly separate market detail, order book depth, price history, metrics, and usage info. The descriptions explicitly call out when to use one search tool over another, so an agent should not confuse them.
All tool names follow a consistent snake_case verb_noun pattern: search_* for discovery and get_* for retrieval. There is no mixing of camelCase, bare verbs, or inconsistent naming styles.
Eight tools is well-scoped for a read-only historical data server: three search tools for navigation, four retrieval tools for different data dimensions, and one usage/limits tool. Every tool has a clear role and none feels redundant.
The server covers the full exploration workflow: search series/events/markets, get market detail, then fetch order book history, price history, or derived metrics. It also includes a usage tool for rate-limit planning, and the search tools handle closed/resolved markets for historical analysis, leaving no obvious dead ends.