This server gives AI agents quant tools for prediction markets (Kalshi/Polymarket): EV/Kelly/Bayes calculators, market boards, NFL modeling, arbitrage scanning, and Pro edge signals.
Calculate expected-value edge and get BUY/SELL/SKIP reads.
Size positions with full/half/quarter/eighth Kelly and risk ratings.
Update probabilities with Bayesian evidence chains.
Convert between probability, American odds, and decimal odds.
Compare market prices to historical base rates and get gap signals.
Grade same-game combo/parlay quotes against fair value with verdicts.
Access live market data: Fed rate odds, Kalshi 15-minute boards, perps, liquidation estimates.
Find cross-venue arbitrage between Kalshi and Polymarket.
Use in-season NFL tools: power ratings, win probability, Ladder, prop board, ladder arb.
Unlock Pro live edge engines: commodity edge, mispricing scans, NFL edges, and alerts.
Provides edge detection and trade signals for Bitcoin price prediction markets on Kalshi, including commodity edge and alert feeds.
Provides analysis of MLB prediction market contracts on Kalshi and Polymarket, including arbitrage detection, model edges, and mispricing scans.
Provides analysis of NBA prediction market contracts on Kalshi and Polymarket, including arbitrage detection, model edges, and mispricing scans.
Provides analysis of NHL prediction market contracts on Kalshi and Polymarket, including arbitrage detection, model edges, and mispricing scans.
Canonical home: predictionmarketspicks.com/mcp — docs, setup, the live wall and the per-tool track record. This repo is the bridge and the offline calculators; the server lives on the site.
A hosted Model Context Protocol server that gives AI agents quant tools for Kalshi and Polymarket prediction markets — expected value, Kelly sizing, Bayesian updating, probability conversion, cross-platform price gaps, Fed rate odds, Kalshi's 15-minute markets and perps (with liquidation estimates), live edge signals, and the in-season NFL model: power ratings, win probability, The Ladder, the weekly prop board and game/prop edges.
Every signal our engines publish is graded against the market that priced it: 1,612 decided signals, +$98.40 net on a flat one-contract stake, as of Aug 18, 2026 — published per tool, including the engines that lose money. → predictionmarketspicks.com/track-record
Endpoint (Streamable HTTP): https://predictionmarketspicks.com/api/mcp/mcp
Registry name: com.predictionmarketspicks/quant (MCP registry)
32 tools — 25 free, 5 Pro, 2 free-with-depth-caps. No key needed for the free set. Eight of the free tools are the fantasy draft desk, parked until the 2027 offseason (see below), so 17 free tools answer in-season (the 2026 Senate map and per-race odds joined 2026-09-17; the Kalshi 15-minute board and the two perps tools joined 2026-09-26).
Fantasy draft landing page: predictionmarketspicks.com/draft — the eight draft tools, connect instructions, and the model behind the board. The desk is parked for the 2026 season and reopens for the 2027 offseason.
Any host that speaks Streamable HTTP (Claude Code, Claude.ai, ChatGPT, Cursor) — point it at the URL. Nothing to install:
claude mcp add --transport http predictionmarketspicks https://predictionmarketspicks.com/api/mcp/mcpHosts that only speak stdio — this package bridges one to the other:
{
"mcpServers": {
"predictionmarketspicks": {
"command": "npx",
"args": ["-y", "@predictionmarketspicks/mcp"]
}
}
}That relays the hosted server verbatim — all 32 tools, live data, tool schemas and result payloads untouched. Set PMP_API_KEY in the server's env to unlock the Pro tools; without one you get the free tools at free depth.
npx @predictionmarketspicks/mcp # bridge to the hosted quant server (default)
npx @predictionmarketspicks/mcp --draft # bridge to the fantasy-draft server (parked until the 2027 offseason)
npx @predictionmarketspicks/mcp --local # 6 calculators, offline, no network at all--local is a self-contained build of the six stateless calculators. It makes no network calls, so it runs in an air-gapped sandbox — but it cannot serve the live engines, the NFL model, or anything that reads a market.
Other hosted surfaces (same registry, same tool objects, different selection — no separate install):
Server | Endpoint | Exposes |
|
| All 32 tools |
|
| The 8 draft tools — parked until the 2027 offseason |
|
| The 6-tool weather loop: |
|
| The 8-tool commodities desk: |
Related MCP server: SimpleFunctions
Free tools need no key. Pro tools read the live PMP edge engines and require a PredictionMarketsPicks API key ($14.99/mo). Deeper results on the list-shaped tools unlock instantly and free — no key to copy, nothing to install: unlock here.
--localTool | What it does |
| Expected-value edge on a contract from market price + your probability; returns edge % and a BUY / SELL / SKIP read. |
| Kelly position size (full / half / quarter / eighth) from win probability, price, and bankroll, with a risk rating. |
| Update a prior with one or more pieces of evidence; returns the posterior and the per-step chain. |
| Convert between implied probability, American odds, and decimal odds. |
| Compare a market price to the historical base rate for a class of events; returns the gap in points + sample quality. |
| Grade a same-game multi-leg combo: EV %, fair vs offered odds, correlation-aware joint probability, negative-correlation trap flag. |
Tool | What it does |
| Live Kalshi-implied odds of a Fed rate cut, hold or hike at each remaining 2026 FOMC meeting, plus the next meeting and the current fed funds rate. |
| Every Kalshi 15-minute series live — crypto, gold, silver, oil, natural gas, copper, currencies — with the open window's YES price, close time, settlement source, and how the last 96 windows settled. |
| Every Kalshi perp — price, volume, open interest, max leverage, and what funding has cost a long since launch. |
| Where a leveraged Kalshi perp position liquidates (an estimate from Kalshi's published risk parameters), with fees and funding over the hold. |
Tool | What it does |
| Cross-venue price gaps between Kalshi and Polymarket on the same contract. Largest gap free; whole board on Pro. |
| US macro-health composite (0–100) and regime, plus six category scores. Composite always free. |
Tool | What it does |
| PWR for all 32 NFL teams — points per game above an average team on a neutral field, with rank and tier. |
| Turn an NFL spread + total into win probability, projected score, and over/cover probability — or pass two teams to derive the spread. |
| The Ladder — every Kalshi strike vs our whole distribution (spreads, season wins, props) with the derived verdict: SHAPE, LOCATION or PRICED. |
| This week's NFL prop prices venue by venue — every Kalshi strike vs the book consensus, DraftKings/FanDuel lines, Novig/ProphetX, and where the best price for each side actually is. |
| Ladder Arb Scanner — Kalshi college football + NFL spread/total ladders priced out of order on the same side of the same game: locked arbitrage (buy the low strike, sell the high one) and crossed-mid inversions with the resting orders that capture them. |
draft_board · best_available · who_do_i_draft · compare_players · player_outlook · explain_player · sleepers_and_busts · adp_market_gaps
The 2026 draft season closed on Sept 10, 2026. These eight tools stay registered (and free) but currently answer with a redirect to the in-season NFL tools above — nfl_prop_board, nfl_ladder, nfl_edge — rather than a draft answer. The desk reopens, with the 2027 board, for the 2027 offseason.
commodity_edge · scan_mispricings · nfl_edge · nfl_prop_edge · edge_alerts
Trade tickets from the silver, gold, oil and bitcoin engines; Polymarket contracts trading away from the PMP model; NFL game and prop edges; the alerts feed. edge_alerts is the one hybrid: Pro keys get the feed in real time, and without a key the same feed arrives delayed 24h.
All tool descriptions and outputs use prediction-market terminology (trader / position / contract / market analysis).
This repo is the public home of the server: the manifest, the bridge, the offline calculator build, and the docs. The hosted service and its live data are operated by PredictionMarketsPicks — MIT license covers this repository, and no install is required to use the server.
npm install
npm run smoke # offline calculator self-test, no network
npm run smoke:bridge # bridge self-test against the hosted endpoint
npm start -- --local # stdio server, 6 calculatorsOr run the offline build with Docker:
docker build -t pmp-mcp-quant .
docker run --rm -i pmp-mcp-quantBuilt by PredictionMarketsPicks — independent quant tools and edge analysis for Kalshi and Polymarket, published by The 7 Oracles. Educational analysis, not financial advice.
MIT — see LICENSE.
Compare a market price against the historical base rate for a class of events and get the gap in percentage points plus a signal and sample-size quality. Pass either a known base-rate id (one of: incumbent_reelected, fed_hold_unemp_below_4, fed_cut_cpi_above_3, recession_called_12mo, sp500_positive_year, bitcoin_above_100k_eoy, gdp_growth_above_2, cpi_above_3, senate_incumbent_wins_primary, vix_below_20_eoy, interest_rate_cut_next_meeting, major_sports_upset) or your own baseRateValue. Use for "how does this price compare to history", "is the market ignoring the base rate", "historical frequency vs market".
| Name | Required | Description | Default |
|---|---|---|---|
| baseRateId | No | Known base-rate id to look up (includes sample size + source). | |
| marketPrice | Yes | Current market price in cents / implied probability % (0–100). | |
| baseRateValue | No | Your own base rate in % (0–100), used when no baseRateId is given. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description adds that it returns gap, signal, and sample-size quality, providing useful output context beyond the annotation.
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, front-loaded with the main function and a list of example use cases, with no 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?
Given no output schema, the description explains the output types (gap, signal, sample-size quality). It could detail the return format, but the core functionality is well-covered.
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 each parameter is well-documented. The description reinforces the options but doesn't add significant new meaning beyond the 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 compares a market price against a historical base rate, outputs gap, signal, and sample-size quality. It distinguishes itself from sibling tools like bayes_update, calculate_ev, and kelly_size by focusing on base rate comparison.
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?
Provides explicit use case examples and explains when to pass baseRateId vs baseRateValue. While it doesn't explicitly state when not to use, the examples and alternative input paths give clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update a prior probability with one or more pieces of evidence using Bayes theorem. Given a prior and a list of evidence items (each with P(evidence | true) and P(evidence | false)), returns the posterior probability and the per-step chain. Use for "update my estimate with new information", "posterior probability", "how does this news change the odds".
| Name | Required | Description | Default |
|---|---|---|---|
| prior | Yes | Prior probability the hypothesis is true, in % (0–100). | |
| evidence | Yes | One or more evidence items, applied in order. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true. Description adds that evidence is applied in order and returns per-step chain, which is 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first defines function and output, second gives use cases. No fluff, front-loaded with purpose.
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?
Tool is simple; description covers input, output, and usage. Missing edge case discussion (e.g., prior=0) but acceptable for this complexity level.
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 has 100% coverage with descriptions. Description adds ordering semantics ('applied in order') not present in schema, providing extra clarity.
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?
Clearly states verb (update), resource (prior probability with evidence), and method (Bayes theorem). Distinguishes from siblings like base_rate_gap and calculate_ev by focusing on sequential evidence update.
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?
Provides explicit example queries (e.g., 'update my estimate with new information') indicating when to use. Lacks explicit when-not or direct comparisons to siblings, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate the expected-value edge on a Kalshi or Polymarket prediction-market contract. Given the current market price (in cents, i.e. the implied probability) and your own probability estimate, returns the % edge and a BUY / SELL / SKIP signal with a plain-English read. Use for "is this contract mispriced", "what is my edge", "should I take this position".
| Name | Required | Description | Default |
|---|---|---|---|
| marketPrice | Yes | Current contract price in cents (1–99), equal to the implied probability in %. | |
| yourProbability | Yes | Your own estimate of the true probability the contract resolves YES, in % (0–100). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true (non-destructive), and the description adds that the tool returns '% edge' and a 'BUY / SELL / SKIP signal with a plain-English read', disclosing output behavior beyond structured fields.
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 main action and platforms, then output description. No 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 simple calculation tool with two numeric parameters and no output schema, the description covers purpose, inputs, and outputs adequately. No gaps.
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 100% with clear parameter descriptions. The description does not add further semantic detail beyond what's in the schema, so baseline 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?
Description uses specific verbs ('calculate', 'returns') and resources ('Kalshi or Polymarket prediction-market contract'), clearly distinguishing from sibling tools like 'combo_edge' or 'kelly_size' which compute different metrics.
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?
Explicitly lists use cases: 'is this contract mispriced', 'what is my edge', 'should I take this position'. However, it does not mention when not to use it or suggest alternatives, which would make it a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Grade a same-game combo (parlay-style multi-leg position) on a prediction market against its fair value. Given each leg price in cents and your correlation-aware estimate of the true joint win probability, returns the fair-value ODDS BAND to grade a quote against. Pass offeredOdds — the price your platform actually quotes for the combo (Kalshi combo RFQ or an SGP product) — to get the expected-value %, a negative-correlation-trap flag, and a 7-tier verdict (SMASH / PLAY / LEAN / RISK / NO_VALUE / PASS / RUN). Without offeredOdds it returns fair value + band only (no verdict) — never grade EV off the product of the leg prices, which no venue pays. Use for "is this combo worth it", "grade my parlay quote", "same-game combo value".
| Name | Required | Description | Default |
|---|---|---|---|
| legPrices | Yes | Each leg's YES price in cents (1–99). Used only for the theoretical assemble ceiling. | |
| offeredOdds | No | The combo price your platform actually quotes — American odds (e.g. -150, 988) or a decimal payout multiplier (e.g. 10.7). Grades EV + verdict against fair value. Omit to get fair value + band only. | |
| trueWinProbability | Yes | Your correlation-aware estimate of the true joint probability all legs hit, in % (0–100). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and non-open-world; descriptions add rich behavioral context: returns fair-value ODDS BAND, EV% with/without offeredOdds, a negative-correlation-trap flag, and a 7-tier verdict. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with main purpose, but includes redundant warning about product of leg prices. Slightly verbose but efficient given complexity; every sentence adds info.
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?
Covers main outputs and parameter behavior well, but lacks numeric ranges for ODDS BAND or definitions of each verdict level. Adequate for an AI agent without output schema.
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 covers 100% of parameters, but description adds meaning: legPrices 'used only for theoretical assemble ceiling', offeredOdds format and effect, trueWinProbability as correlation-aware estimate. Adds value beyond 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 begins with a specific verb-resource pair ('Grade a same-game combo... against its fair value'), clearly defines inputs and outputs, and differentiates from siblings like calculate_ev by emphasizing same-game combo valuation and avoiding simple product 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?
Provides explicit use cases ('is this combo worth it', 'grade my parlay quote') and warns against misusing the product of leg prices. Lacks direct comparison to sibling tools but implies specificity to same-game combos.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert between implied probability, American odds, and decimal odds. Give one value and its format and get all three back (American odds carry no commas, e.g. +441 or -200). Use for "what is +150 as a probability", "convert 62% to American odds", "decimal to implied odds".
| Name | Required | Description | Default |
|---|---|---|---|
| value | Yes | The numeric value to convert. | |
| format | Yes | Format of `value`: probability (0–100 %), american (e.g. -200 / +150), or decimal (e.g. 2.5). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that given one value and its format, it returns all three formats. Annotations already state readOnlyHint=true, so no contradiction. Adds useful context about American odds format.
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 with examples and a formatting note. No wasted words; front-loaded with purpose.
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 conversion tool with two params and no output schema, the description fully covers input and output behavior. All necessary information is present.
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 100% with descriptions, but the description reinforces the meaning of each format (probability 0-100%, american like -200/+150, decimal like 2.5) and adds the no-comma rule for American odds, adding value beyond 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?
Clearly states it converts between implied probability, American odds, and decimal odds. Uses specific verbs and resource names, and the examples differentiate it from sibling tools like bayes_update or kelly_size.
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?
Provides explicit use cases ('what is +150 as a probability', 'convert 62% to American odds', 'decimal to implied odds') and a formatting note about commas. Does not explicitly exclude cases, but context implies it's for simple conversions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute the optimal Kelly position size for a prediction-market contract. Given your win probability, the market price (which sets the payout), your bankroll, and a Kelly fraction (full / half / quarter / eighth), returns the dollar stake and a risk rating. Use for "how much should I stake", "what is my position size", "Kelly sizing for this trade".
| Name | Required | Description | Default |
|---|---|---|---|
| bankroll | Yes | Total bankroll in dollars. | |
| fraction | No | Kelly fraction to apply. Half-Kelly is the common sharp-money default. | half |
| marketPrice | Yes | Contract price in cents (1–99). Sets the payout ratio. | |
| winProbability | Yes | Your probability the contract resolves YES, in % (0–100). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description doesn't need to disclose safety. The description adds that the tool 'returns the dollar stake and a risk rating', which is helpful output context, but no further behavioral traits (e.g., restrictions, assumptions) are given.
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 with no wasted words. First sentence states purpose and inputs; second sentence gives usage examples. Front-loaded and efficient.
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?
Despite no output schema, the description mentions returning 'dollar stake and a risk rating', covering return values. The tool's purpose is well-scoped, and sibling context is clear. Slightly missing is elaboration on risk rating, but overall adequate.
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 100%, so baseline is 3. The description adds meaning beyond schema by explaining that marketPrice 'sets the payout ratio' and linking it to winProbability. It also clarifies the fraction enum values. This enhances semantic 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 verb 'Compute' and the resource 'optimal Kelly position size for a prediction-market contract'. It distinguishes itself from sibling tools like base_rate_gap or bayes_update by focusing specifically on position sizing, and provides example use-case phrases.
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 explicitly lists natural-language triggers like 'how much should I stake', telling the agent when to use this tool. It does not provide when-not-to-use or mention alternatives, but the context is clear enough given the sibling set.
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.2.1base_rate_gapbayes_updatecalculate_evcombo_edgeconvert_probabilitykelly_sizeScored across 6 tools
Each tool serves a clearly distinct quantitative purpose: historical comparison, probability updating, edge calculation, combo evaluation, odds conversion, and sizing. No two tools overlap in function.
All names use snake_case and are descriptive, but they mix verb-led (calculate_ev, convert_probability) and noun-led (base_rate_gap, combo_edge, kelly_size) conventions. The pattern is not entirely uniform.
Six tools is well-scoped for a prediction market quant server, covering core analysis tasks without being excessive or insufficient.
The set covers the primary quantitative actions for prediction market analysis. Minor gaps such as lacking automated data fetching or correlation estimation are not critical given the tool descriptions.
Hosted MCP for Kalshi prediction markets: search, odds, order books, settlement rules, and trading.
Live Kalshi and Polymarket data: EV edges, cross-venue arbitrage, markets, and whale trades.
Read-only MCP server for live Polymarket, Kalshi, Limitless odds; Manifold sentiment.
Matched Kalshi and Polymarket markets across sports, crypto, weather, and economics over MCP.
