Click on "Deploy 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., "@Prediction Market Odds Compare Polymarket and Kalshi odds on the Fed holding rates in October."
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.
Live MCP URL (Streamable HTTP, no auth): https://prediction-odds-mcp.vercel.app/mcp
Health check: https://prediction-odds-mcp.vercel.app/health
An MCP server that gives Grok Bot (or any MCP client) live, read-only odds from Polymarket and Kalshi:
Search markets
Live implied probabilities with order books
Side-by-side comparison of the same question on both venues
Short markdown briefings
It uses only public read endpoints, needs no API keys and has no trading functions. Every output cites its sources and fetch timestamps.
Tool | Purpose | Key inputs |
| Open markets on either or both venues: implied YES %, bid/ask, 24h change, volume, close date, ID, link |
|
| Live odds and top-5 YES order book for one market |
|
| Polymarket vs Kalshi for matching questions, with the probability gap |
|
| Headline odds, biggest 24h moves, cross-venue check |
|
| Top open markets by 24h volume |
|
Related MCP server: polymarket-mcp
"What are the odds the Fed holds in October? Compare Polymarket and Kalshi."
"Give me a prediction-market briefing on Bitcoin."
"What's trending on Polymarket and Kalshi today?"
"Show the live order book for the Kalshi market on an October Fed hold."
"Search both venues for World Cup winner odds."
Implied probability = the midpoint of the best YES bid and ask when both exist and the spread is 10¢ or less. Otherwise it's the last trade, then Polymarket's indicative outcome price.
Polymarket: Gamma API for search and metadata. CLOB /midpoint and /book for live prices on single-market lookups.
Kalshi: Trade API v2. Prices are in dollars (legacy cent fields are also supported). Volume is in contracts. In the order book, a NO bid at p is shown as a YES ask at 1 − p.
24h change: Polymarket oneDayPriceChange. For Kalshi, the current implied probability minus previous_price.
Matching (compare_markets): two markets pair only if all of these agree:
the same numbers (strikes, thresholds and years; 25 ≠ >25 ≠ 50+)
the same months
the same comparator (above, below, exact or range)
the same action (cut, hike or hold; "no change" and "hike by 0bps" both count as hold)
title similarity of at least 0.3
Pairs are one-to-one. The output always warns that resolution rules can differ between venues.
Caching: odds 30 s, searches 2 min, Kalshi event index 15 min.
Kalshi search: Kalshi has no text-search endpoint, so the server pages through open events (titles only, ~5 requests/s, parlay events skipped). Each call spends at most 8 s (KALSHI_INDEX_BUDGET_MS) extending the index, so the first one or two calls after a cold start may say "still indexing". It completes in about 3 calls (~9k events).
Rate limits: on HTTP 429, the server retries once (honouring Retry-After, capped at 3 s), then falls back to the cached copy, marked STALE, or a partial result with a clear note.
Identification: requests send a descriptive User-Agent.
npm install
npm test # unit tests (vitest; network mocked)
npm run build
npm start # Streamable HTTP at http://localhost:3000/mcp
npm run start:stdio # stdio
npm run smoke # live: calls every tool against the local serverPush to GitHub and import it at vercel.com/new (Framework preset: Other). No environment variables are required.
The MCP URL is https://<project>.vercel.app/mcp (served by api/mcp.ts, via the rewrite in vercel.json).
Check it with node scripts/smoke.mjs https://<project>.vercel.app/mcp.
Serverless instances each keep their own cache and Kalshi index. The 8 s indexing budget keeps every request well inside the 30 s function limit.
No credentials needed.
List tools. You should see 5.
trending_markets with {"limit": 3}: a table from both venues, ending with a "Sources: … fetched " line.
search_markets with {"query": "Fed rate"}: markets from both venues. If it says Kalshi is "still indexing", repeat after a few seconds.
compare_markets with {"query": "Fed decision October 2026"} (or any current headline event): paired rows with Poly %, Kalshi % and the gap.
get_market_odds with a slug or ticker from step 3: odds and a top-5 order book.
market_briefing with {"topic": "Bitcoin"}: a short briefing.
Invalid input, such as a query of 1 character, returns a validation error.
Information only. This is not financial advice. Prediction markets may be restricted where you live. This server is not affiliated with Polymarket or Kalshi.
MIT
Side-by-side odds for the same question on Polymarket and Kalshi, with the probability gap. Auto-matching requires the same strikes/numbers, dates and comparator (above/below/exact/range) plus title similarity; or pass polymarketSlug + kalshiTicker.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No | ||
| kalshiTicker | No | ||
| minSimilarity | No | ||
| polymarketSlug | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so safety is covered; the description adds genuinely useful behavior the annotations cannot convey — auto-matching only succeeds when strikes/numbers, dates, comparator and title similarity align, otherwise explicit IDs are needed. It does not explain what happens when matching fails or how results are ordered.
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?
Two sentences, purpose front-loaded, no filler. The second sentence is dense with matching criteria but each clause carries real operational weight.
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?
With no output schema and only read-only annotations, the description carries the burden and mostly meets it: the comparison output and matching preconditions are stated. Remaining gaps are the undocumented limit/minSimilarity semantics, which an agent would have to guess.
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 0% for 5 parameters, so the description must compensate and does so only partially: it explains polymarketSlug/kalshiTicker and implies query drives auto-matching, but limit and minSimilarity are never defined, and no formats (slug shape, ticker shape) are given.
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 names a specific verb and resource pair — side-by-side odds for the same question on Polymarket and Kalshi — plus the added output value (the probability gap). It is clearly distinguishable from siblings like get_market_odds (single venue) and search_markets, since comparison across two venues is the defining act.
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?
It lays out two concrete invocation paths: auto-matching from a query (with the conditions that must hold), or explicit polymarketSlug + kalshiTicker. That tells the agent when each mode applies, though it never names an alternative tool or states when not to use this one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Live odds and top-of-book for one market. Polymarket: market slug (uses Gamma + CLOB midpoint/book). Kalshi: market ticker.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Polymarket slug or Kalshi ticker (from search_markets) | |
| venue | Yes |
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 covered. The description adds useful context on provenance (Gamma + CLOB midpoint/book for Polymarket) and that results are live/top-of-book, but says nothing about error behavior for unknown slugs/tickers, caching or staleness of 'live' 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?
Two short sentences, front-loaded with what the tool returns, then venue-specific identifier semantics. Nothing is padded, though the 'uses Gamma + CLOB midpoint/book' clause is implementation detail of limited selection value.
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?
No output schema exists, and the description does state what comes back (live odds plus top-of-book). With only two required parameters and read-only annotations, this is close to complete; only failure/staleness behavior is unaddressed.
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 coverage is 50% and the id field already documents 'Polymarket slug or Kalshi ticker', which the description largely restates. The venue enum is self-explanatory in the schema. The clarification that Polymarket uses Gamma + CLOB adds marginal meaning but not parameter syntax or constraints.
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?
States a specific verb+resource+scope: 'Live odds and top-of-book for one market'. 'One market' implicitly separates it from multi-market siblings (search_markets, trending_markets, compare_markets), though no sibling is named explicitly.
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?
Usage is implied rather than stated: an agent infers this is the single-market lookup once a venue and id are known, but there is no explicit 'use this when…' or 'use search_markets instead if…' language. The id provenance hint lives in the schema, not the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A short markdown briefing: headline odds, biggest 24h moves and a cross-venue check, for a topic or for the most active markets overall.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| topic | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true and openWorldHint=true, so the safety profile is covered. Beyond that, the description discloses the output shape (markdown with three named sections), which is real value given there is no output schema. It stops short of noting latency, cost, or freshness of the cross-venue check.
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?
A single sentence, front-loaded with the deliverable ("A short markdown briefing") and then the contents via a colon list. Every clause maps to either the output or the input mode, so nothing is padding.
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?
The output side is well covered (no output schema exists, and the description names the sections). The input side is incomplete: limit is never explained, and the no-topic default is only implied. For a low-complexity tool with two optional params this is adequate but leaves a gap an agent would need to guess at.
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 0%, so the description must carry parameter meaning. It addresses topic only indirectly via "for a topic," and says nothing at all about limit (range 1-20), which controls how many markets are surfaced. With two undocumented parameters, half the semantics are missing.
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 names a concrete deliverable (a short markdown briefing) and enumerates its contents: headline odds, biggest 24h moves, and a cross-venue check. That distinguishes it from the raw-data siblings (get_market_odds, compare_markets, trending_markets) as a synthesized digest, though it never names those siblings explicitly.
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?
"for a topic or for the most active markets overall" implicitly signals that topic is optional and that calling with no arguments yields the default active-markets view, which is useful. However, it gives no explicit guidance on when to prefer this briefing over get_market_odds, compare_markets, or trending_markets when a user asks a narrow odds question.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search open markets on Polymarket and Kalshi by topic (e.g. 'Fed rate', 'Bitcoin 150k', 'World Cup'). Returns implied YES probability, bid/ask, 24h change, volume, close date, ID and link.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| venue | No | default both |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=true), so the description's real contribution is the payload it returns: implied YES probability, bid/ask, 24h change, volume, close date, ID and link. That materially helps an agent judge whether results suffice. It still omits ordering, pagination, and what happens on an empty or unknown-topic query.
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?
Two sentences, front-loaded with the action and scope, followed by the result shape. Every clause carries information; nothing is redundant with the title.
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?
With no output schema, the description correctly enumerates return fields, and it covers venues and scope. For a 3-param tool it is nearly self-sufficient, missing only the limit/pagination and result-ordering behavior an agent might need.
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 coverage is only 33% (just the venue enum's 'default both'), so the description must compensate. It partially does: the topic examples clarify the query parameter and the venue names imply the 'both' default, but limit (1-25) and the venue enum values themselves get no explanation, leaving real gaps.
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?
States a specific verb+resource ('Search open markets'), scopes it to two named venues, and gives concrete query examples ('Fed rate', 'Bitcoin 150k'). The 'by topic' framing implicitly separates it from trending_markets and get_market_odds, but no sibling is named explicitly.
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 query examples hint at the kind of input to supply, but there is no statement of when to use this versus trending_markets, get_market_odds, compare_markets, or market_briefing, and no exclusions or prerequisites. The agent must infer routing from sibling names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Top open markets by 24h volume on Polymarket, Kalshi or both.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| venue | No | default both |
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 covered. The description adds genuine context beyond that: ranking is by 24h volume and the results are limited to currently open markets across two venues. It omits pagination/truncation behavior and what happens when limit is omitted, so it adds value but not richly.
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?
One sentence, zero waste, and the ranking criterion and data scope are front-loaded. Nothing in it is padding or repetition of the tool name.
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?
With only two optional params, no output schema and annotations covering safety, the description is close to sufficient. Still missing: default limit value, what fields each market entry contains, and how ties or fewer-than-limit results are handled. Adequate but with clear gaps for a ranked-list 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?
Schema coverage is 50%: venue is documented only as 'default both' and limit has no description at all. The description partially compensates by naming the two venues and implying a volume-ranked ordered list where limit selects the count, but it never states a default limit or that the max is 25. Baseline 3 is appropriate given mixed 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?
States a specific resource and ranking criterion ('top open markets by 24h volume') plus the venue scope ('Polymarket, Kalshi or both'). That is far more precise than the vague title 'Most active markets'. It does not explicitly name how it differs from siblings like search_markets, but the ranking/volume framing makes the distinction fairly inferable.
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 says what the tool returns but never says when to reach for it instead of search_markets, get_market_odds, compare_markets or market_briefing. There are no exclusions, no prerequisites, and no mention of the default venue behavior driving selection. Usage is only implied by the word 'top'.
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.
v1.0.0compare_marketsget_market_oddsmarket_briefingsearch_marketstrending_marketsScored across 5 tools
Each tool has a fairly clear role: search_markets for discovery, get_market_odds for a single market, compare_markets for cross-venue gap, trending_markets for volume leaders, and market_briefing for a digest. The only mild overlap is between trending_markets and market_briefing (both surface active markets) and between search_markets and trending_markets, but descriptions clarify the intent.
Three tools follow a clean verb_noun pattern (search_markets, get_market_odds, compare_markets), but market_briefing and trending_markets are noun/adjective-first phrases. The mixed convention is still readable but breaks the predictable pattern.
Five tools is well-scoped for a read-only odds aggregation service, covering discovery, detail, comparison, and summarization without redundancy. Each tool earns its place.
The surface covers search, per-market odds, cross-venue comparison, trending, and briefing—solid lifecycle for a read-only data domain. Minor gaps include historical/time-series odds and order-book depth, which agents could not fully work around but aren't central to the stated purpose.
Hosted MCP for Kalshi prediction markets: search, odds, order books, settlement rules, and trading.
Polymarket in your AI: market rules, real fill costs, who is trading, top traders. Read-only.
Your agent needs the crowd's number — live odds on elections, policy, macro prints and sport, from the venues where people put money behind the opinion. **What you can ask for** • "What are the current odds on this event?" • "List the open markets on this topic across both venues." • "Show recent trades and how the price moved." • "What is the implied probability now versus a week ago?" **How to use it** Point any MCP client at https://mcp.aisa.one/prediction-market-data/mcp and sign in with OAuth — there is no key to create or paste. 5 tools: Kalshi markets and trades, Polymarket markets, events and activity. **Why this rather than the source** Both venues in one shape, so the same question can be priced twice. **It is also a door to the rest** The same login reaches 26 sources and 580+ operations. Read the odds here, then ask the same agent for the market data or the news behind them — without adding a second server. **What it costs** Finding and inspecting an operation is free. Running one is billed per call at API prices, with no seat and no monthly minimum, and every call takes max_price_usd so an agent cannot overspend by accident. **Where else it reaches** https://mcp.aisa.one/finance/mcp for equities, crypto and prediction markets in one place.
Read-only MCP server for live Polymarket, Kalshi, Limitless odds; Manifold sentiment.
