Polymarket MCP Server: Connect Claude to Live Markets (2026)

What is a Polymarket MCP server?

Model Context Protocol is a standard for giving a language model callable tools. An MCP server is the program that exposes those tools; the client, such as Claude Desktop or Claude Code, discovers them and decides when to call one.

Applied to Polymarket, that means the difference between pasting a market's price into a chat and asking "what are the biggest movers on Polymarket in the last 24 hours, and how does the top one compare to the same event on Kalshi" and having the model go and find out.

The server runs locally over stdio. It is not a hosted endpoint you point at, it is a process your client starts, which is why the install is a command rather than a URL. Your API key stays in your own environment.

How do you connect Claude to Polymarket data?

Create a free key at portal.predictefy.com/keys, then pick your client. Every one of these uses the same package.

Claude Code is a single command:

claude mcp add predictefy -e PREDICTEFY_API_KEY=pk_live_your_key_here -- npx -y @predictefy/mcp

Claude Desktop takes a block in claude_desktop_config.json:

{
  "mcpServers": {
    "predictefy": {
      "command": "npx",
      "args": ["-y", "@predictefy/mcp@1.0.0-beta.6"],
      "env": {
        "PREDICTEFY_API_KEY": "pk_live_your_key_here"
      }
    }
  }
}

Cursor uses the identical shape in .cursor/mcp.json in your project.

VS Code differs in two ways that cause most of the failed setups. The key is servers, not mcpServers, and each entry needs an explicit type. In .vscode/mcp.json:

{
  "servers": {
    "predictefy": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@predictefy/mcp"],
      "env": {
        "PREDICTEFY_API_KEY": "pk_live_your_key_here"
      }
    }
  }
}

How do you verify the connection actually works?

Reload the client, then ask it to list its tools. If list_venues and search_markets appear, the server registered.

Registration is not the same as authentication, though, and this is where people declare victory early. The connection is only proven once an authenticated call returns. The cheapest one is a catalog read:

get_catalog_metadata with {"kind":"markets","venue":"router","limit":3}

Use router rather than polymarket for that first call. router answers across every served venue at once, so a narrow filter cannot hide a working connection behind an empty result. If it comes back with three markets, you are connected.

An empty list is still a successful call and should be read as zero markets, not as a broken setup. A 401 means the key is missing or wrong, and a 402 means credits are exhausted, which retrying will not fix.

What tools does the server expose?

Forty-three by default. They are grouped and parameterized rather than one per endpoint, so a kind or scope enum selects the verb inside a family. That keeps the tool list readable for the model instead of presenting ninety near-identical entries.

One thing the MCP surface deliberately does not do is stream. MCP is request and response, so there is no live subscription tool and none is faked. get_arbitrage gives a point-in-time snapshot; a live feed is a job for the WebSocket surface instead.

Caps differ from the REST contract in a few places worth knowing before you write a prompt around them. get_orderbook and get_trades clamp their limit at 100 where REST allows 1,000, and get_ohlcv exposes three resolutions where REST exposes twelve.

How do you turn the trading tools off?

This is the part most write-ups get backwards, so it is worth stating plainly: the ten execution and collateral tools register by default. You do not arm them. You disarm them.

{
  "mcpServers": {
    "predictefy": {
      "command": "npx",
      "args": ["-y", "@predictefy/mcp@1.0.0-beta.6"],
      "env": {
        "PREDICTEFY_API_KEY": "pk_live_your_key_here",
        "MCP_ENABLE_TRADE": "false"
      }
    }
  }
}

It has to be the literal string false. Anything else, including an empty value, leaves the execution set registered. With it set, you get a 33 tool surface that reads and analyzes and genuinely cannot place an order or return a collateral-moving transaction to sign.

For a research setup, or any connection you are handing to an agent running unattended, that is the configuration to use.

If you do leave execution on, two things protect you. exec_submit previews unless it is passed confirm: true, so a model cannot fire an order by inferring intent from a conversation. And server-side spend caps apply regardless: 100 USD per order and 1,000 USD per API key over a rolling 24 hours. No tool both builds and signs an order either. Build operations return unsigned artifacts and signing stays in your own process, so key custody never moves.

What are the guardrails on an MCP connection?

All four are enforced server side rather than trusted to the client, which matters because the caller is a language model that will happily ask for a million rows.

There is a design decision underneath those that is easy to miss. Because a grouped tool shares one schema across its kinds, a parameter the chosen kind cannot honor is refused with an error that names it, rather than being dropped quietly. An agent must never read an unfiltered result as though its filter applied, and silent parameter dropping is exactly how that happens.

The same principle governs unsupported venues. If you ask for a trade tape on a venue that does not publish one, the answer is an honest NOT_SUPPORTED, not an empty array. Those two responses look identical downstream and mean completely different things.

What does it cost to run?

The free plan carries 25,000 credits a month, refilled, with no invite needed. Requests are endpoint weighted, so casual exploration through chat is inexpensive.

A conversation that searches markets, pulls two order books and compares a pair across venues costs well under 30 credits. The queries that add up are the cross-venue and arbitrage ones, which is the right shape, since those are the ones doing real work.

What other Polymarket MCP servers are there?

Several, and the category has grown quickly. A search of npm returns a dozen or so community servers wrapping Polymarket's public Gamma and CLOB APIs, ranging from read-only data wrappers to ones that place orders.

If you are evaluating them, the questions that matter are the same ones you would ask of any dependency. When was the last commit. Is there a license. What happens when you ask for something the underlying API does not support, an honest error or an empty array. Whether trading tools are present, and whether they can be switched off. And whether the tool surface is capped, because an uncapped list tool will consume your context window on a single call.

That last group of questions is the real reason to think past a single venue. A Polymarket-only server answers Polymarket questions. The moment you want to know how a price compares to the same event elsewhere, you are back to running several servers and reconciling their output by hand, which is a normalization problem wearing a different hat. Predictefy's server covers Polymarket as one of 16 venues on a single schema, so a cross-venue question is one tool call rather than a manual join.

Frequently Asked Questions