How Parlay Works
How Parlay maps Polymarket, Kalshi, and Manifold into a single MCP tool schema.
Doc index
Looking for a machine-readable map of every Parlay doc? See the
Introduction for the human version, or fetch
/docs/llms.txt for the agent-friendly index.
Parlay sits between an AI assistant and three prediction-market venues — Polymarket, Kalshi, and Manifold — and turns their three different APIs into one typed MCP tool schema. The model speaks one protocol; Parlay handles the venue-specific glue. Below is the full pipeline, layer by layer.
The full pipeline
A user asks a question
Plain English in the AI client: "What's the best price on a Fed cut in June?" or "Which market has the most liquidity for the 2026 election?"
The AI client picks a tool
The model reads Parlay's MCP descriptor, picks search_markets or get_quote, fills in typed arguments, and sends the call over HTTP or stdio.
Parlay validates and routes
The Parlay MCP server checks your API key, validates the arguments against the tool schema, and routes the call to the right venue adapter.
The venue adapter calls the upstream API
Polymarket, Kalshi, or Manifold returns its native payload. Parlay normalizes the shape — same field names, same units, same timestamps — across all three.
The client gets typed JSON back
The model reads structured fields it can reason about directly. No scraping, no per-venue parsing logic, no SDK on the client side.
Layer 1: Your AI client
You bring the AI client. Parlay works with any MCP-aware client today: Claude (desktop and web), ChatGPT (via the MCP connector), Gemini CLI, OpenClaw, Cursor, and Windsurf. The client provides:
| Capability | What it brings |
|---|---|
| Natural-language understanding | The model translates "best Fed-cut odds" into a real search_markets call. |
| Multi-step reasoning | Chain search_markets → get_quote → get_orderbook without prompting at each step. |
| File and context grounding | Pull tickers, dates, or themes from documents you've shared with the assistant. |
| User confirmation | Trading tools (landing next) prompt the user before any state-changing call. |
| Result formatting | The model converts typed JSON into prose, tables, or charts the user can read. |
Layer 2: MCP (Model Context Protocol)
MCP is the open spec from Anthropic that lets any client talk to any tool server without a custom SDK. Parlay exposes a single endpoint that every client connects to:
https://parlay.run/mcpThe same URL serves Claude, ChatGPT, Gemini, OpenClaw, and any future MCP client. The descriptor handshake tells the client which tools exist and what shape each call takes.
Read tools — live today
search_markets, get_quote, get_orderbook, get_trades. All four work across Polymarket, Kalshi, and Manifold with one schema.
Write tools — landing next
place_order and cancel_order are in development. They will be opt-in, separately scoped, and require explicit user confirmation per call.
For the wire-level handshake and a sample descriptor, see How MCP Works.
Layer 3: Authentication (API key + Bearer)
Parlay uses a single API key per account, not per-venue OAuth. Venue credentials live server-side and never reach the client.
Issue a key in the dashboard
Sign in at parlay.run and create an API key under Dashboard → API Keys. Each key is scoped to your account and can be rotated or revoked at any time.
Set it in your client
For HTTP clients (Claude, ChatGPT, Gemini, Cursor) paste the key as a Bearer token in the MCP connector settings:
Authorization: Bearer <your-api-key>For stdio clients (OpenClaw, Gemini CLI) export it in your shell:
export PARLAY_API_KEY=<your-api-key>Parlay validates and scopes the session
The server checks the key against your account, scopes the session to read-only tools today, and rate-limits per account. Invalid or revoked keys fail at the descriptor handshake — before any venue is touched.
Server-side adapters call the venues
Parlay's adapters use Parlay-managed venue credentials to fetch live data. Your API key never sees a Polymarket wallet, a Kalshi trading secret, or a Manifold session token.
What Parlay never sees from you:
- Your wallet seed phrase or private keys
- Your venue-side API secrets
- Your custodial balances on any platform
- Your IP-bound login sessions
Layer 4: Prediction-market APIs
The point of Parlay is that one tool name returns the same shape no matter which venue answers. Here is how each tool maps across the three venues today:
| Parlay tool | Underlying call | What it returns |
|---|---|---|
search_markets | Polymarket Gamma API /markets | Active markets matching keyword/category, with close date and venue tag. |
search_markets | Kalshi /trade-api/v2/markets | Active Kalshi markets, normalized to the same shape. |
search_markets | Manifold /v0/search-markets | Active Manifold markets, normalized to the same shape. |
get_quote | Polymarket CLOB /midpoint + book | Current yes/no implied probability and last-trade timestamp. |
get_quote | Kalshi /markets/{id} | Current yes/no probability from Kalshi's bid/ask. |
get_quote | Manifold /market/{id} | Current probability from Manifold's market state. |
get_orderbook | Polymarket CLOB /book | Top-N bid/ask levels with size, in cents. |
get_orderbook | Kalshi /markets/{id}/orderbook | Top-N bid/ask levels with size, normalized. |
get_trades | Polymarket CLOB /trades | Recent fills with price, size, side, timestamp. |
get_trades | Kalshi /markets/{id}/trades | Recent fills, normalized to the same fields. |
Manifold doesn't expose a public order book or trade tape today, so get_orderbook and get_trades skip Manifold gracefully — the response includes a not_supported flag rather than failing the whole call.
Safety model
Parlay is read-only today, but the safety model is layered for when trading tools land.
| Layer | Protection | Who enforces it |
|---|---|---|
| API-key scope | Each key is bound to one account; revocation is immediate. | Parlay control plane |
| Tool surface | Only read tools are exposed today; write tools require a separate scope. | Parlay MCP server |
| Rate limiting | Per-account quotas prevent runaway agents from hammering venues. | Parlay edge |
| Venue ToS | Adapters respect each venue's robots, rate limits, and acceptable-use rules. | Parlay adapters |
| Data minimization | Only the fields the tool schema declares leave the server. | Parlay MCP server |
| Audit logging | Every tool call is logged with timestamp, tool, and account for review. | Parlay control plane |
Data flow summary
| What | Where it lives | Who can access it |
|---|---|---|
| Your Parlay API key | Hashed in the Parlay control plane; raw value shown once at issuance. | You, on the client side. Parlay sees only the hash after creation. |
| Venue credentials | Parlay-managed secrets, encrypted at rest, never sent to clients. | Parlay adapters only. |
| Market data (quotes, books, trades) | Cached briefly at the edge for hot markets; otherwise fetched live. | The requesting client, on demand. |
| Request logs | Audit log scoped to your account. | You (via dashboard) and Parlay support. |
| User prompt text | Stays in the AI client; only the typed tool arguments reach Parlay. | Your AI client. Parlay never sees raw prompts. |
| Response payloads | Returned to the client and not retained beyond the audit log entry. | Your AI client. |
FAQ
Related documentation
How MCP Works
The wire-level descriptor and JSON-RPC message shape that every MCP client uses.
Quickstart
Sign up, connect a client, and run your first tool call in 5 minutes.
Polymarket
Venue-specific notes for Polymarket markets, IDs, and pricing conventions.
OpenClaw
The CLI agent that speaks Parlay over stdio for local, low-latency workflows.