Polymarket MCP Server: Giving Claude 45 Tools to Trade Prediction Markets

The gap between reading Polymarket and trading it

Polymarket exposes a REST API and a CLOB for order placement. An LLM cannot call either one directly. The usual workaround is a chat session where you copy prices in and paste order parameters out, which breaks down the moment you want to react to a spread that moved two minutes ago. This project closes that gap by wrapping Polymarket's surface area in the Model Context Protocol, so Claude Desktop or Claude Code can call tools rather than describe intentions. The README frames the goal as enabling Claude to "autonomously trade, analyze, and manage positions," and the tool count of 45 across five categories tells you the author intended breadth rather than a single narrow helper. The audience is narrow: someone with a Polygon wallet, some familiarity with how CLOB limit orders behave, and a willingness to let a language model select and invoke trading functions. It is not aimed at people who want a read-only dashboard, though DEMO mode covers that case.

What the 45 tools actually cover

The README splits the tool surface into five groups. Market Discovery has 8 tools for keyword and category search, trending markets by 24h, 7d and 30d volume, closing-soon alerts, featured markets, sports markets and crypto markets. Market Analysis has 10: live prices and spreads, orderbook depth, liquidity and volume metrics, historical prices, an AI-powered opportunity analysis that returns BUY, SELL or HOLD, multi-market comparison, top holder lookup, risk scoring and spread monitoring. Trading has 12, including limit orders with GTC, GTD, FOK and FAK time-in-force options, market orders, batch submission, AI-suggested pricing in aggressive, passive or mid modes, order status and history, open order management, single and bulk cancellation, a natural-language "smart trade execution" path, and position rebalancing with slippage protection. Portfolio adds 8 tools for positions, realized and unrealized P&L, aggregate value, risk analysis covering concentration and liquidity, filtered trade history, on-chain activity, performance metrics and optimization presets. Real-time Monitoring adds 7 tools over WebSocket for price updates, orderbook streaming, order status notifications, execution alerts, resolution notifications, subscription management and health checks.

Architecture: MCP tools over a rate-limited Polymarket client

The data flow implied by the README is straightforward. Claude issues a tool call, the MCP server validates it against the configured safety rules, then translates it into a Polymarket API request signed with EIP-712 and authenticated at two levels: L1 wallet authentication using the private key, and L2 API key authentication. Read paths go to Polymarket's REST endpoints. Streaming paths go over WebSocket with auto-reconnect and exponential backoff, which the README lists as a feature rather than an afterthought, and that matters because a dropped socket during an open position is the failure mode you would notice first. Outbound requests pass through a token bucket rate limiter described as respecting all Polymarket API limits. The README states there are no mocks and that tests run against real APIs, which is a meaningful design decision: it makes the test suite dependent on network access and on Polymarket's sandbox behaviour, and it means CI cannot be hermetic. The README's own test badge is a claim, not evidence, and I have not run the suite.

Safety limits are configurable, not automatic

The safety section lists seven mechanisms: per-order size limits, total portfolio exposure caps, per-market position limits, minimum liquidity validation, maximum spread tolerance, a confirmation flow for large orders, and pre-trade validation. Every one of these is a threshold you set. The server does not infer that a 40 percent position in a single market is unwise; it checks your number against your number. That is the honest design for a tool whose users have opinions about risk, but it also means the safety layer is only as good as the .env you wrote at 1am. The confirmation flow for large orders is the one mechanism that inserts a human into the loop, and it is worth knowing exactly what triggers it before you leave the server running. The README does not state default values for any of these limits in the material available, so treat the defaults as unknown until you read .env.example.

Installation and configuration paths

There are four routes. The one-command path pipes a remote script into bash: curl -sSL https://raw.githubusercontent.com/caiovicentino/polymarket-mcp-server/main/quickstart.sh | bash. The README also supports cloning and running ./quickstart.sh locally, which is the version I would use, since it lets you read the script before it touches your environment. Full installation runs ./install.sh on macOS and Linux, or install.bat on Windows. DEMO mode is ./install.sh --demo and needs no wallet, giving read-only access to discovery, analysis and price monitoring with trading disabled. Manual setup is the conventional sequence: git clone, python -m venv venv, activate, then pip install -e . The installer claims to check for Python 3.10 or newer, create the virtual environment, install dependencies, configure the environment, wire up Claude Desktop integration and run a test. Configuration starts from cp .env.example .env. A separate web dashboard starts with polymarket-web or ./start_web_dashboard.sh and serves on http://localhost:8080, with sliders for safety limits and trading controls. The README's configuration section is truncated in the material I have, so I cannot list the individual environment variable names beyond the .env.example reference.

Where this is the wrong tool

The DEMO mode boundary is the clearest limitation: without a wallet, everything in the Trading and Portfolio categories is unreachable, so anyone evaluating the project on DEMO mode alone is evaluating roughly half of it. Beyond that, the architecture puts a language model between you and order placement. The README's own feature list includes natural-language trade execution and AI-suggested pricing, which means the model proposes parameters that the server then signs. A hallucinated price or a misparsed ticker becomes a signed order. The pre-trade validation and spread tolerance checks are the backstop, and they are numeric, so they will catch an order outside your bands but not an order that is inside your bands and wrong about the market. The project is also tightly coupled to Polymarket: the rate limiter, the EIP-712 signing, the WebSocket subscriptions and the two-level auth are all Polymarket-specific, so none of it transfers to Kalshi or Manifold. Finally, the material gives no indication of how the server behaves when Polymarket changes an endpoint. The last push is dated 2026-07-30, the same day as v0.2.0, so the project is active, but API drift is the maintenance risk you are accepting.

How it differs from a general agent framework

The obvious alternative is wiring Polymarket's REST and CLOB APIs into a general agent framework yourself, or using a generic MCP filesystem or HTTP tool that lets the model issue arbitrary requests. The difference is in what gets encoded. A generic HTTP tool hands the model a URL and a body; the model must know the endpoint shape, the signing scheme and the time-in-force semantics. This project encodes all of that in Python, so the model chooses among 45 named operations with typed parameters instead of composing raw requests. The trade-off runs the other way too. A generic HTTP tool works against any API you point it at, while this server only speaks Polymarket, and adding a new Polymarket endpoint means editing Python rather than writing a prompt. If your goal is one market, one strategy and a handful of orders, the generic route is less machinery. If you want discovery, orderbook depth, portfolio P&L and streaming in the same conversation, the 45-tool surface is the reason to take the dependency.

Licence, maintenance and upgrade cost

The project is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is a permissive licence and it does not carry the network-copyleft obligations of AGPL, so running a modified version as a service does not trigger a source disclosure requirement. This is a description of the licence text, not legal advice; if you are deploying it inside a firm, run the terms past counsel. On maintenance, the release history shows v0.1.0 in November 2025 and v0.2.0 in July 2026, an eight-month gap that included the addition of the web dashboard. That cadence suggests a single maintainer working in bursts, which is worth weighing if you plan to depend on the server for live order flow. The upgrade cost is concentrated in two places: the safety defaults in .env, which you will need to re-check after any version bump, and the Polymarket API surface, which is outside the maintainer's control. Pinning to v0.2.0 and reading the diff before moving is the cheap insurance here.

Editorial conclusion

Adopt it if you already trade on Polymarket, hold a funded Polygon wallet you are willing to expose to an LLM-driven tool call, and want Claude to handle discovery, orderbook analysis and order placement in one loop. Avoid it if you cannot articulate your own position sizing rules, because the server enforces limits you configure, not limits it derives. Before running install.sh, read safety.py and the .env.example keys for order size, exposure and spread tolerance, and confirm on the Polymarket docs that the CLOB endpoints this project targets are still current.

Official sources

1. caiovicentino/polymarket-mcp-server on GitHub
2. Issues
3. License: MIT
4. README
5. Releases