# Kalshi (npm · @pipeworx/mcp-kalshi)

Kalshi MCP — US-regulated prediction-market data (no auth on public reads).

- Trust score: 82/100 (high trust)
- Change this week: +3
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-11-05

## Components

- remote · `gateway.pipeworx.io`: 78/100, [markdown](https://verifymcp.io/servers/pipeworx-io-kalshi/kalshi-mcp.md), [page](https://verifymcp.io/servers/pipeworx-io-kalshi/kalshi-mcp)
- npm · `@pipeworx/mcp-kalshi`: 82/100 (this document), [markdown](https://verifymcp.io/servers/pipeworx-io-kalshi/pipeworx-mcp-kalshi.md), [page](https://verifymcp.io/servers/pipeworx-io-kalshi/pipeworx-mcp-kalshi)

## Channel facts

- Registry: `npm`
- Package: `@pipeworx/mcp-kalshi`
- Version: `0.3.1`
- Transport: `stdio`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-11-05.

- **Supply Chain Security**: 100/100
  - No malware found by supply-chain analysis.
  - No known CVEs affecting this package version or its production dependencies.
  - No install/post-install scripts declared.
  - No production dependencies, so there is no dependency health to assess.
- **Provenance & Transparency**: 97/100
  - Source repository is publicly reachable at the declared URL.
  - Cryptographically verified build provenance (signed, bound to pipeworx-io/mcp-kalshi).
  - Clear OSI-approved license (MIT).
  - Actively maintained (last published 2 days ago).
  - Disclosure check failed: no security disclosure policy was found in the source repository.
- **Schema Quality & AI Usability**: 62/100
  - AI-judged instruction clarity (excellent).
  - Context-footprint check failed: tool/resource definitions use about 6033 tokens (~317/item across 19 items; 19 tools + 0 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 23/100
  - Stability observed for 7 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 100/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 100% of tool parameters carry a description.
- **Tool Safety**: 100/100
  - No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.
  - We read all 19 captured tool definition(s), and no name or description among them implies an irreversible operation.
  - An AI judge read all 20 captured unit(s) of tool text and found none that tries to manipulate the model reading it.
- **Capabilities**: 100/100
  - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.

## Install

### How do I install the Kalshi MCP server?

Kalshi runs locally as an npm package, launched with npx -y @pipeworx/mcp-kalshi. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

### Claude

```bash
claude mcp add pipeworx-io-kalshi -- npx -y @pipeworx/mcp-kalshi
```

### Cursor

```json
{
  "mcpServers": {
    "pipeworx-io-kalshi": {
      "command": "npx",
      "args": [
        "-y",
        "@pipeworx/mcp-kalshi"
      ]
    }
  }
}
```

### VS Code

```json
{
  "servers": {
    "pipeworx-io-kalshi": {
      "command": "npx",
      "args": [
        "-y",
        "@pipeworx/mcp-kalshi"
      ]
    }
  }
}
```

### Codex

```bash
codex mcp add pipeworx-io-kalshi -- npx -y @pipeworx/mcp-kalshi
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "pipeworx-io-kalshi": {
      "type": "local",
      "command": [
        "npx",
        "-y",
        "@pipeworx/mcp-kalshi"
      ],
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add pipeworx-io-kalshi --command npx --arg -y --arg @pipeworx/mcp-kalshi
```

### Hermes

```yaml
mcp_servers:
  pipeworx-io-kalshi:
    command: "npx"
    args: ["-y", "@pipeworx/mcp-kalshi"]
```

### Netclaw

```json
{
  "McpServers": {
    "pipeworx-io-kalshi": {
      "Transport": "stdio",
      "Command": "npx",
      "Arguments": [
        "-y",
        "@pipeworx/mcp-kalshi"
      ]
    }
  }
}
```

### Vellum

```bash
assistant mcp add pipeworx-io-kalshi -t stdio -c npx -a -y @pipeworx/mcp-kalshi
```

### Other

```json
{
  "mcpServers": {
    "pipeworx-io-kalshi": {
      "command": "npx",
      "args": [
        "-y",
        "@pipeworx/mcp-kalshi"
      ]
    }
  }
}
```

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-11-05 (score 82, +1)

No change was recorded against any check on this day. Stability & Change Management went from 20 to 23. That category is still filling its 30-day observation window: 6 days of observed history at the previous scan, 7 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-11-03 (score 81, +16)

- [security improvement] Malware scan: unverified → pass

### 2026-11-02 (score 65, −15)

- [security regression] Malware scan: pass → unverified
- [functional] Package version: 0.3.0 → 0.3.1

### 2026-10-31 (score 80, +1)

No change was recorded against any check on this day. Stability & Change Management went from 3 to 7. That category is still filling its 30-day observation window: 1 days of observed history at the previous scan, 2 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-10-29 (score 79)

First indexed and scored.

## MCP tools (19)

### `kalshi_markets` (~567 tokens)

List or search Kalshi prediction markets, open or already settled. Pass `keyword` to find markets by subject — "inflation", "Iran", "Vance" — served by Kalshi's own full-corpus search, with each result tagged match: market|event|related so you can tell a literal keyword hit from a relevance-ranked neighbor. A keyword search honours `status`, so status "settled" is how you find a RESOLVED market by subject (its `result` is the outcome) — Kalshi indexes settled markets separately and the open index does not contain them. Other filters: status (open|closed|settled|unopened), event_ticker (group by event), series_ticker (group by series like KXFED for Fed rate). EVERY path returns the same fields — ticker, event_ticker, series_ticker, title, subtitle, status, yes_ask/yes_bid/no_ask/last_price (cents 1–99), implied_yes_prob, volume, volume_24h, open_interest, liquidity, close_time, category, result — so you can screen by category AND liquidity in one call. Two fields are conditional and say so here rather than surprising you: `result` is the settled outcome ("yes"/"no") and is null while a market is still trading, and `category` comes from the market's Kalshi series (Kalshi's market records carry none), so it is null for the rare market whose series lookup fails — listed in fields_omitted when that happens. A keyword search adds two fields a listing has no notion of: event_title and match. Anything we cannot populate is named in `fields_omitted` rather than returned as a bare null. Use this to discover markets; use kalshi_market for the rules text.

Input parameters:

- `cursor` (string): Pagination cursor from previous response
- `event_ticker` (string): Filter to one event (e.g. "KXFED-26OCT")
- `keyword` (string): Subject to search for, e.g. "inflation", "Iran", "Vance". Runs Kalshi's own search over the full market corpus, in the slice named by `status` — pass status "settled" to find markets that have alread…
- `limit` (number): 1-1000 (default 100)
- `series_ticker` (string): Filter to one series (e.g. "KXFED" for Fed funds rate)
- `status` (string): open | closed | settled (default open)

### `kalshi_market` (~185 tokens)

AUTHORITATIVE detail for one Kalshi market by ticker (e.g. "KXFED-26OCT-T3.50"), live OR long-settled — Kalshi drops older markets from its live endpoints (they 404 there), and this falls through to Kalshi's historical archive and says which answered in `source`. Returns the rules text (so you know exactly what the market settles on — critical before quoting odds), yes_ask + no_ask prices in cents, last_price, volume, open_interest, expiration date, settlement criteria. Use after kalshi_events / kalshi_event to drill into a specific market, or when you already have a Kalshi ticker. For depth-of-book use kalshi_orderbook.

Input parameters:

- `ticker` (string, required): Kalshi market ticker, e.g. "KXFED-26OCT-T3.50"

### `kalshi_events` (~329 tokens)

List/browse Kalshi events (event = a question with one-or-more child markets, e.g. "Fed funds rate after Oct 2026 meeting?" with 11 markets, one per rate bucket). Filter by status (open / settled), series_ticker (KXFED, KXBTC, KXCPI, etc.), or category (Politics, Economics, Financials, Crypto, Climate and Weather, Sports, ...). Kalshi's own endpoint ignores a category filter, so we apply it over a bounded page scan and report events_scanned / scan_complete with the result — a category browse is filtered, not exhaustive. Use this as a discovery tool — to find what events Kalshi has open for a given topic family. For a specific event's child markets see kalshi_event; for one specific market see kalshi_market.

Input parameters:

- `category` (string): Kalshi category, exact words: Politics | Elections | Economics | Financials | Crypto | Companies | Commodities | Climate and Weather | Science and Technology | Sports | Entertainment | World | Health…
- `cursor` (string): Pagination cursor
- `limit` (number): 1-200 (default 100)
- `series_ticker` (string): e.g. "KXFED"
- `status` (string): open | closed | settled (default open)

### `kalshi_event` (~437 tokens)

AUTHORITATIVE odds from Kalshi — the only CFTC-regulated US prediction-market exchange (US persons CAN legally trade here, unlike Polymarket). Returns one event with ALL its child markets nested: event title + each market's ticker, subtitle, price, volume. Use when you need the full partition for an outright bet ("Fed funds in June 2026: each rate level is one market"). Pass include_orderbook=true to fetch live top-of-book for each market (slower but populates yes_ask_cents/yes_bid_cents/no_ask_cents + implied_yes_prob — required for most macro events since the nested response leaves prices null on the public unauth API). Every price ships TWO ways: `*_cents` rounded to the nearest cent (Kalshi's display convention) and `*_dollars` at full fixed-point precision — a genuine sub-cent quote like 0.335 shows as 34 in `yes_ask_cents` and exactly 0.335 in `yes_ask_dollars`; use the dollars field for anything sizing a trade on a thin spread. `implied_yes_prob` is computed from the dollars value, not the rounded cents, so it carries the same precision. `yes_bid_size`/`no_bid_size` report top-of-book contract size for the two real resting sides when include_orderbook populated them from the orderbook ladder — there is no separate size for yes_ask/no_ask because those are derived prices (1 − the opposite side's best bid), not an independent order. For cross-venue spreads vs Polymarket, see polymarket_kalshi_spread.

Input parameters:

- `event_ticker` (string, required): Kalshi event ticker, e.g. "KXFED-26OCT"
- `include_orderbook` (boolean): Default false. When true, fetches per-market orderbook in parallel and patches in best bid/ask + recomputed implied_yes_prob. Adds ~1s for events with ~10 markets. Required when the nested response r…

### `kalshi_series` (~84 tokens)

List Kalshi series (a series groups related events over time — e.g. "KXFED" series has one event per FOMC meeting). Useful to find the canonical handle for recurring questions.

Input parameters:

- `category` (string): Politics | Economics | Climate | Sports | Science | World
- `limit` (number): 1-1000 (default 200)

### `kalshi_orderbook` (~85 tokens)

Current YES/NO orderbook (bids + asks with size, in cents) for a market ticker. Use to see live liquidity depth before judging whether an edge is tradable. Returns sorted price/quantity levels.

Input parameters:

- `depth` (number): Levels to return per side (default 5, max 100)
- `ticker` (string, required): Kalshi market ticker

### `kalshi_trades` (~154 tokens)

Executed trades for a market ticker, live OR long-settled. Returns most-recent N trades with yes/no price in BOTH units (yes_price_cents and yes_price_dollars at full precision), contract size, taker side and timestamp. Useful for sanity-checking what the market actually paid vs the resting orderbook, and for reconstructing how a resolved market traded. Kalshi answers 200-with-an-empty-list on its live trades endpoint for markets it has archived, so this falls through to Kalshi's historical trade archive and reports which one answered in `source`.

Input parameters:

- `limit` (number): 1-1000 (default 50)
- `ticker` (string, required): Kalshi market ticker

### `kalshi_price_history` (~539 tokens)

Historical price/probability time-series (candlesticks) for a Kalshi market — how the YES odds moved over time, for ANY window, including one that ended long ago. Pass a market ticker (e.g. "KXFEDDECISION-28JAN-H26") plus either an explicit start_ts/end_ts window ("what did this market think in March?") or lookback_days as sugar for a window ending now. Returns OHLC candles: YES price (open/high/low/close/mean as probability 0-1), best bid/ask, volume, and open interest per interval. Kalshi serves at most 5,000 candles per request; a window larger than that comes back as page 1 with `next_cursor` and `complete: false` — pass the cursor straight back for the next slice, oldest-first — so a long window is never silently shortened. Kalshi also MOVES older markets out of its live endpoints, where they 404; this routes to Kalshi's historical archive automatically and reports which one answered in `source`, so backtesting a resolved 2024 market works the same way as charting a live one. The Kalshi analogue of polymarket_price_history.

Input parameters:

- `cursor` (string): Pass back `next_cursor` from a previous response to fetch the next slice of a window too large for one request (>5,000 candles). The cursor carries the ticker, interval and remaining window, so no ot…
- `end_ts` (string): Window END — same formats as start_ts. Defaults to now when omitted.
- `interval` (string): "1h" (hourly) | "1d" (daily, default) | "1m" (per-minute). Coarser intervals cover longer history per request.
- `lookback_days` (number): Sugar for a window length in days (1-365, default 30). Anchors to start_ts if you gave one, to end_ts if you gave that, and to now if you gave neither. Ignored when both start_ts and end_ts are set.
- `start_ts` (string): Window START — ISO date ("2026-03-01"), ISO datetime ("2026-03-01T00:00:00Z"), or unix seconds. Use with end_ts to ask about a window that does NOT end today.
- `ticker` (string): Kalshi market ticker (e.g. "KXFEDDECISION-28JAN-H26"). The series is derived from the ticker automatically. Required unless you are passing `cursor`.

### `kalshi_exchange_status` (~38 tokens)

Exchange-level status: is the trading floor open, are deposits/withdrawals enabled, any scheduled maintenance. Cheap check before a batch script.

### `kalshi_top_markets` (~289 tokens)

Ranking / leaderboard of Kalshi's most-traded markets right now — use this for "what is the highest volume prediction market on Kalshi", "most traded Kalshi market", or any top-N-by-activity question. Kalshi's /markets endpoint has NO server-side sort and its raw listing is 99%+ algorithmically-generated multivariate combo markets with zero volume, so paging through it would surface junk. This instead discovers real, currently-active markets via Kalshi's own search/relevance index, then re-ranks the leaders using each market's authoritative live volume/price detail. Returns title, ticker, event_ticker, volume, volume_24h, open_interest, liquidity, yes/no price (cents), close_time, as_of, and source, sorted highest-first. Not an exhaustive scan of every one of Kalshi's ~14,000 series — see `method` and `candidates_considered` in the response for the disclosed scan size.

Input parameters:

- `by` (string): volume (default, all-time contracts traded) | volume_24h | open_interest | liquidity
- `limit` (number): 1-50 (default 10)
- `status` (string): "open" (default — only markets not yet past close_time) | "any" (include markets whose close_time has passed, still excludes settled/resulted ones)

### `kalshi_macro` (~141 tokens)

Friendly-name shortcut for the most-asked Kalshi macro series: "Fed" (FOMC rate buckets), "BTC" (Bitcoin price ranges), "ETH" (Ethereum), "CPI" (monthly inflation), "GDP" (quarterly growth), "SP500" (S&P 500 EOY close), "Recession" (NBER recession calls). Returns the soonest-expiring open event for that series with all child markets + implied probabilities, so agents can ask about macro odds without knowing Kalshi's ticker scheme.

Input parameters:

- `topic` (string, required): Fed | BTC | ETH | CPI | GDP | SP500 | Recession

### `kalshi_orderbooks` (~389 tokens)

Depth-of-book for UP TO 100 Kalshi markets in ONE call — Kalshi's own batch orderbook endpoint (`GET /markets/orderbooks`), not a fan-out we do for you. Use this instead of calling kalshi_orderbook once per ticker when you are pricing a whole event partition (an 11-bucket Fed event, a 20-strike temperature ladder) or screening several markets for liquidity: one request, one rate-limit slot. Returns per ticker: the full yes_bids / no_bids ladders (price in BOTH units — price_dollars at Kalshi's fixed-point precision and price_cents rounded — with quantity), plus best_yes_bid / best_no_bid and the derived yes_ask / no_ask (1 − the opposite side's best bid, which is what an ask IS in a binary market; Kalshi returns bids only). Kalshi returns an orderbook entry only for tickers it recognises AND that have a book, so any ticker you asked for that came back with nothing is named in `tickers_without_book` rather than silently dropped — an empty ladder is a real answer (nobody is quoting), not an error.

Input parameters:

- `depth` (number): Levels to keep per side, best-first (default 5, max 100). Kalshi returns the whole ladder; this trims the response. `levels_available` reports the untrimmed depth per side so you can tell a thin book…
- `tickers` (array, required): Market tickers, 1-100 (Kalshi's own per-request cap, e.g. ["KXHIGHNY-26SEP16-B75.5","KXHIGHNY-26SEP16-B77.5"]). A comma-separated string is accepted too. More than 100 is an explicit error, not a sil…

### `kalshi_candlesticks` (~421 tokens)

Price history (OHLC candles) for UP TO 100 Kalshi markets over ONE shared window, in ONE call — Kalshi's batch candlestick endpoint (`GET /markets/candlesticks`). This is the comparison tool: every bucket of a Fed or CPI event on one timeline, or the same question across several strikes, without the N separate calls kalshi_price_history would cost. Per candle: YES open/high/low/close/mean as a probability 0-1, best bid/ask close, volume and open interest. Kalshi caps the response at 10,000 candles ACROSS all markets combined — when the cap binds the response says `truncated_by_upstream: true` and tells you which tickers came back short, because a silently halved series is indistinguishable from a quiet market. For ONE ticker with paging, a longer window, or a market old enough that Kalshi has archived it, use kalshi_price_history: this batch endpoint has no archive fallback and no cursor.

Input parameters:

- `end_ts` (string): Window END — same formats. Defaults to now.
- `interval` (string): "1h" (hourly, default) | "1d" (daily) | "1m" (per-minute). Kalshi accepts only these three; the 10,000-candle cap is shared across every ticker you ask for, so a per-minute window over 100 markets wi…
- `lookback_days` (number): Sugar for a window ending now (1-365, default 1). Ignored when both start_ts and end_ts are given.
- `start_ts` (string): Window START — ISO date ("2026-09-01"), ISO datetime, or unix seconds.
- `tickers` (array, required): Market tickers, 1-100 (e.g. ["KXHIGHNY-26SEP16-B75.5","KXHIGHNY-26SEP16-B77.5"]). A comma-separated string is accepted too.

### `kalshi_event_live_data` (~448 tokens)

The REAL-WORLD measurement an event settles against, next to the odds — Kalshi's event live-data feed (`GET /live_data/events/{event_ticker}`). This is the thing you cannot get by calling any other Kalshi endpoint: for a crypto event it is the underlying BTC/ETH price track from the settlement index (candlesticks + tick timeseries); for an economic event it is the actual published series the market resolves on (e.g. CPI CUUR0000SA0 from BLS, monthly, with its latest value and the target period); for other events it is whatever observation Kalshi charts behind the contract. The response's `type` names the schema of `details` (seen live: "crypto", "timeseries"), and the fields that matter are lifted to the top level where they exist: latest_value, unit, measure, frequency, provider, series_id, target_period, last_refreshed. COVERAGE IS PARTIAL AND WE SAY SO: most events have no live data and answer 404 — this returns found:false with the ticker rather than an error. Weather is NOT here: temperature observations are city-keyed, not event-keyed (KXHIGHNY-26SEP16 404s) — use kalshi_weather_index. The raw payload can exceed 400 KB for an active crypto event, so series are trimmed to `max_points` newest-first and `points_total` reports what existed.

Input parameters:

- `event_ticker` (string, required): Kalshi event ticker, e.g. "KXBTCD-26SEP1617" (crypto) or "KXUSCPIYEAR-37FEB01" (economic series).
- `max_points` (number): Newest points to keep per series (default 200, max 2000). `points_total` always reports the untrimmed length.
- `range` (string): Chart-range hint passed straight to Kalshi, e.g. "15min", "1h", "1d". Honoured only by types that support it; the response reports Kalshi's own `default_range` and any `selectable_periods` it adverti…

### `kalshi_game_stats` (~317 tokens)

Live scoreboard and play-by-play for a sports game Kalshi has markets on, keyed by MILESTONE id (not event ticker) — Kalshi's `GET /live_data/milestone/{id}` plus `/game_stats`. Returns the current state (score, period/inning, status, last play, winner once final) and the play list, newest-first, each with its description, clock and score at the time. Get the milestone id from kalshi_milestones (its `related_event_tickers` is the bridge back to tradeable markets). COVERAGE, stated plainly: Kalshi documents play-by-play for Pro/College Football, Pro/College Basketball, WNBA, Soccer, Pro Hockey and Pro Baseball, and it comes from Sportradar — a milestone outside that set, or one Sportradar does not cover, returns HTTP 200 with an EMPTY play list, which this reports as plays_available:false rather than passing off an empty array as a game with no plays (verified live 2026-09-16: a college football game returned `{"pbp":{}}`).

Input parameters:

- `limit` (number): Plays to return, newest first (default 25, max 500). `plays_total` reports how many existed.
- `milestone_id` (string, required): Kalshi milestone UUID, e.g. "ce57e3ef-6b6a-4680-a849-5965021aaac2". Find one with kalshi_milestones(category:"Sports").

### `kalshi_milestones` (~394 tokens)

Kalshi's own index of the real-world OCCURRENCES its markets hang off — games, elections, hearings, launches — from `GET /milestones`. Each milestone carries a title, type (e.g. baseball_game, football_game, tennis_tournament_singles, election), category, start and end dates, source ids, and — the reason to use this — `primary_event_tickers` and `related_event_tickers`, which are Kalshi's OWN statement of which markets belong to the occurrence. That is the alternative to matching event titles by string, which is how you accidentally group two different games. Filter by category ("Sports", "Elections", ...), type, competition, related_event_ticker (reverse lookup: which milestone is this event part of?) or minimum_start_date; page with cursor. A milestone id is also the key for kalshi_game_stats.

Input parameters:

- `category` (string): Kalshi category, exact words, e.g. "Sports" | "Elections" | "Economics" | "Politics".
- `competition` (string): Competition filter, e.g. "NFL", "NBA" (Kalshi's own spelling; many milestones carry none).
- `cursor` (string): Pagination cursor from a previous response.
- `limit` (number): 1-200 (default 50). Kalshi requires this parameter; we always send it.
- `minimum_start_date` (string): RFC3339 timestamp; only milestones starting at or after it. Kalshi's default page is dominated by historical milestones, so pass this to see current ones.
- `related_event_ticker` (string): Reverse lookup — return milestones linked to this event ticker.
- `type` (string): Milestone type, e.g. "baseball_game", "football_game", "basketball_game", "tennis_tournament_singles", "soccer_tournament_multi_leg".

### `kalshi_structured_targets` (~462 tokens)

The ENTITIES Kalshi's markets are about, as Kalshi models them — players, teams, actors, films and similar — from `GET /structured_targets`. Each row has a stable id, a type — granular by sport, e.g. "actor", "football_player", "soccer_team", "film", "company", "politician", with NO bare "player" or "team" and no error for an unknown one (it returns an empty list, and the response names the known types when that happens), a name, source ids, and a type-specific `details` block (a player carries league, position, jersey, team_id; an actor carries films and social handles). Use it to resolve a name to the id Kalshi itself uses, so a market about a person can be tied to that person rather than to a string that happens to match. Filter by type, competition, or explicit ids; page with cursor (up to 2,000 per page). This is a reference index, not market data — nothing here carries a price.

Input parameters:

- `competition` (string): Competition filter, e.g. "NFL", "NCAAMB". Same silent-empty behaviour as `type` for an unrecognised value.
- `cursor` (string): Pagination cursor from a previous response.
- `ids` (array): Explicit structured-target ids to fetch. A comma-separated string is accepted too.
- `page_size` (number): 1-2000 (default 100).
- `type` (string): Entity type. Kalshi's types are GRANULAR BY SPORT and there is no bare "player", "team" or "athlete" — an unknown value returns 200 with an EMPTY list rather than an error. Seen live 2026-09-16: acto…

### `kalshi_weather_index` (~493 tokens)

Kalshi's OWN city temperature index — the minute-resolution series that its hourly temperature markets settle against, from `GET /live_data/weather/{city}`. This is not a weather forecast and not a single station: it is the number Kalshi computes from a weighted multi-station panel, in Fahrenheit to 0.01, which is the only series a temperature contract actually resolves on. Each point carries `contributors` (how many stations reported) and `status`; a minute where the quorum failed is reported rather than interpolated. CITY IS AN INDEX ID, NOT A PLACE NAME, and Kalshi supports exactly thirteen (verified live 2026-09-16 from Kalshi's own rejection message): miami, dfw, houston, phl-delaware-valley, puget-sound, sf-bay, greater-boston, southeast-michigan, kansas-city, minneapolis-st-paul, nyc, chicago, la-coastal. An unknown city is a clean error listing those. The series is city-keyed and independent of any event, so it exists even when no market is open. For the station weights and offsets behind the number, and every recalibration, use kalshi_weather_index_calibrations.

Input parameters:

- `city` (string, required): Index city id — one of: miami, dfw, houston, phl-delaware-valley, puget-sound, sf-bay, greater-boston, southeast-michigan, kansas-city, minneapolis-st-paul, nyc, chicago, la-coastal.
- `detailed` (boolean): Include Kalshi's per-station audit readings on every point (much larger response).
- `from` (number): Window start, unix MILLISECONDS (Kalshi's unit here, not seconds). Overrides last_sec when given with `to`.
- `last_sec` (number): Window length ending now, in seconds (default 3600). The series is per-minute, so a window under ~120s can legitimately return zero points — that is a real empty window, not a failure, and `points` s…
- `max_points` (number): Newest points to keep (default 500, max 5000). `points_total` reports the untrimmed count.
- `to` (number): Window end, unix MILLISECONDS, inclusive. Defaults to now.

### `kalshi_weather_index_calibrations` (~208 tokens)

How a Kalshi city temperature index is COMPUTED, and every time that changed — `GET /live_data/weather/{city}/calibrations`. Returns the launch configuration plus each weekly offset calibration and methodology update in ascending effective order: per-station weights, per-station offsets in Celsius, the city reference, the config version string, the calibration window and Kalshi's stated reason for the change. This is the audit trail behind kalshi_weather_index: it is what lets you reproduce an index value from raw station data, and what tells you whether a settlement dispute falls before or after a methodology change. Same thirteen city ids as kalshi_weather_index.

Input parameters:

- `city` (string, required): Index city id — miami, dfw, houston, phl-delaware-valley, puget-sound, sf-bay, greater-boston, southeast-michigan, kansas-city, minneapolis-st-paul, nyc, chicago, la-coastal.

## Diagnostics

Captured diagnostic sections: Provenance, Dependencies. The full working is on the page: https://verifymcp.io/servers/pipeworx-io-kalshi/pipeworx-mcp-kalshi#diagnostics

## Score history

- 2026-11-05: 82
- 2026-11-04: 81
- 2026-11-03: 81
- 2026-11-02: 65
- 2026-11-01: 80
- 2026-10-31: 80
- 2026-10-30: 79
- 2026-10-29: 79

## Common questions

### What is the Kalshi MCP server?

Kalshi is an MCP server listed in the public MCP registry as io.github.pipeworx-io/kalshi. Kalshi MCP, US-regulated prediction-market data (no auth on public reads). This page covers its npm package (@pipeworx/mcp-kalshi).

### Is the Kalshi MCP server safe to use?

Kalshi scores 82 out of 100 on VerifyMCP. We found no known CVEs affecting it as of 5 November 2026. It declares no install or post-install scripts. Its build provenance is signed and verified. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

### What tools does the Kalshi MCP server expose?

Kalshi exposes 19 tools: kalshi_markets, kalshi_market, kalshi_events, kalshi_event, kalshi_series, and 14 more. Their descriptions and schemas cost roughly 5,980 tokens of context every time the server is loaded.

### Is the Kalshi MCP server still maintained?

Kalshi is still listed as active in the MCP registry. We last reached this channel on 5 November 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.

### What licence is the Kalshi MCP server under?

Kalshi declares the MIT licence, which is OSI-approved. That covers the source only, and says nothing about the cost of any service it calls.

### What did VerifyMCP test on the Kalshi MCP server?

VerifyMCP ran 16 checks on Kalshi, covering Malware scan, Known CVEs, Install scripts, Dependency health and 12 more. Endpoint Security and Transport & Reachability do not apply to an npm package, so they were not tested. The score does not measure everything, and the scoring documentation lists what it leaves out.

## Links

- npm package: https://www.npmjs.com/package/@pipeworx/mcp-kalshi
- Socket report: https://socket.dev/npm/package/@pipeworx/mcp-kalshi
- Repository: https://github.com/pipeworx-io/mcp-kalshi
- Website: https://pipeworx.io/packs/kalshi
- Changelog RSS feed: https://verifymcp.io/servers/pipeworx-io-kalshi/pipeworx-mcp-kalshi.xml
- Changelog JSON feed: https://verifymcp.io/servers/pipeworx-io-kalshi/pipeworx-mcp-kalshi/changelog.json
- Trust report (JSON): https://verifymcp.io/servers/pipeworx-io-kalshi/pipeworx-mcp-kalshi.json
- HTML version of this page: https://verifymcp.io/servers/pipeworx-io-kalshi/pipeworx-mcp-kalshi