Cross-venue spread between Kalshi and Polymarket for the same resolving question. The two venues sometimes price the same outcome 2-25pp apart because their participant pools differ — when the bet shapes are equivalent that delta is a real signal, when they aren't the tool says so. TWO MODES: (1)...
AI agents call polymarket_kalshi_spread to retrieve information from Mcp Currents without modifying anything — typically the context-gathering step in research, monitoring, and reporting workflows, before the agent takes action elsewhere.
| Parameter | Type | Required | Description |
|---|---|---|---|
topic | string | — | Pre-mapped: fed | btc | cpi | gdp | sp500 | recession | next_pope | next_uk_pm | next_israel_pm | 2028_president |
kalshi_event_ticker | string | — | Explicit Kalshi event ticker, e.g. "KXFED-26OCT". Overrides the topic-mapped Kalshi side. |
polymarket_event_slug | string | — | Explicit Polymarket event slug, e.g. "fed-decision-in-june-825". Overrides the topic-mapped Polymarket side. |
Parameters from the server's own tool schema.
The tool fetches and compares pricing data from two prediction markets (Kalshi and Polymarket) to display spread information. It retrieves market odds/prices without placing bets or committing any financial obligations. Despite being in the financial domain, it only reads and compares data, making it a Read category tool with low severity.
From the tool's definition Cross-venue spread between Kalshi and Polymarket for the same resolving question... auto-fetch the matching event on each venue... RESPONSE: each venue
Attacks that exploit this kind of access
Cross-venue spread between Kalshi and Polymarket for the same resolving question. The two venues sometimes price the same outcome 2-25pp apart because their participant pools differ — when the bet shapes are equivalent that delta is a real signal, when they aren't the tool says so. TWO MODES: (1) topic — 10 pre-mapped macro shortcuts ("fed", "btc", "cpi", "gdp", "sp500", "recession", "next_pope", "next_uk_pm", "next_israel_pm", "2028_president") auto-fetch the matching event on each venue. (2) explicit kalshi_event_ticker + polymarket_event_slug for custom pairings. RESPONSE: each venue's leg-by-leg prices (raw probability 0-1) plus matched spread[].top_spreads_pp (Kalshi − Polymarket) where the same outcome shows up on both sides. SAFETY FIELDS: compatibility_warning fires in two cases — (a) matched_pairs:0 with skipped_cross_type>0 means the venues frame the topic with non-equivalent bet shapes (e.g. Kalshi range_bucket point-in-time vs Polymarket cumulative_threshold touch-anywhere — no arb exists), (b) matched_pairs:0 with skipped_cross_type:0 and both venues >5 legs means the token-overlap matcher found nothing in common — events likely semantically unrelated despite the topic keyword. temporal_alignment{polymarket_month,kalshi_month,aligned} tells you whether the two events resolve in the same calendar period; aligned:false means spreads are mathematically meaningless across the temporal gap. skipped_cross_type / skipped_cross_subtype counters expose how many leg-pair comparisons were dropped (cross-type = metric_type mismatch like MoM vs YoY; cross-subtype = inequality mismatch like cum_ge vs cum_le). Real cross-venue spreads are rarer than the macro-shortcut list suggests — most pre-mapped topics return compatibility_warning today; pre-mapped ≠ tradeable. It is categorised as a Read tool in the Mcp Currents MCP Server, which means it retrieves data without modifying state.
polymarket_kalshi_spread accepts 3 parameters: topic, kalshi_event_ticker, polymarket_event_slug. The full parameter table on this page comes from the server's own tool schema.
Register the Mcp Currents MCP server in PolicyLayer and add a rule for polymarket_kalshi_spread: allow, deny, rate-limit, or require approval. Point your MCP client at the PolicyLayer proxy URL and the rule is enforced on every call, before it reaches Mcp Currents. Nothing to install.
polymarket_kalshi_spread is a Read tool with low risk. Read-only tools are generally safe to allow by default.
Yes. Add a rate_limit block to the polymarket_kalshi_spread rule in your PolicyLayer policy. For example, setting max: 10 and window: 60 limits the tool to 10 calls per minute. Rate limits are tracked per agent session and reset automatically.
Set action: deny in the PolicyLayer policy for polymarket_kalshi_spread. The AI agent will receive a policy violation error and cannot call the tool. You can also include a reason field to explain why the tool is blocked.
polymarket_kalshi_spread is provided by the Mcp Currents MCP server (https://gateway.pipeworx.io/currents/mcp). PolicyLayer sits as a proxy in front of this server to enforce policies before tool calls reach the server.
Every MCP server has a record like this.
Type a name, get the same breakdown: verified identity, auth posture, risk grade, capabilities, recommended policy.
Teams ship this data inside their own products. See what a licence covers →