Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@polymarket-news-mcp Match news: Federal Reserve signals rate hike"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Give an AI agent a headline — get the Polymarket markets it moves.
An MCP (Model Context Protocol) server that connects real-world news to prediction markets. Plenty of MCP servers can look up Polymarket prices; this one answers a different question: "this just happened — where can the world's belief about it be read?" Matching is deterministic and explainable — every match reports the exact terms that fired and a confidence score, so your agent can judge the match itself.
Read-only by design: no API keys, no wallet, no trading. Live odds and links only.
Tool | What it does |
| The headline tool. News headline/snippet → the markets it could move, with live odds, 24h volume, match score, matched terms, deep links |
| Live feed: recent headlines from major outlets (crypto, politics, world, sports), each matched to its markets |
| Lenient free-text search over ~2,000 active markets |
| Most active markets right now by 24h volume |
| One market's live odds by URL or slug |
match_news("Federal Reserve signals rate hike as inflation stays hot")
[
{"question": "Fed rate hike in 2026?", "match_score": 17.2,
"outcomes": {"Yes": 0.47, "No": 0.53}, "volume_24h_usd": 812440,
"matched_terms": ["fed", "hike", "rate", "rate hike"],
"url": "https://polymarket.com/event/fed-rate-hike-in-2026"},
{"question": "Fed Rate Hike by July 2026 Meeting?", "match_score": 17.0,
"outcomes": {"Yes": 0.08, "No": 0.92}, ...}
]Related MCP server: Polymarket MCP Server
Requires Python ≥3.10. With uv (no install needed):
uvx polymarket-news-mcpClaude Code
claude mcp add polymarket-news -- uvx polymarket-news-mcpClaude Desktop / any MCP client (claude_desktop_config.json):
{
"mcpServers": {
"polymarket-news": {
"command": "uvx",
"args": ["polymarket-news-mcp"]
}
}
}Or classic pip: pip install polymarket-news-mcp
then command polymarket-news-mcp.
By default this server is read-only. Trading tools appear only when you provide your own signing key and install the extra:
pip install "polymarket-news-mcp[trading]"
export POLYMARKET_PRIVATE_KEY=0x... # YOUR key. Stays local, signs locally.
export POLYMARKET_FUNDER=0x... # your Polymarket proxy/funds address (browser-wallet accounts)
# optional: POLYMARKET_SIGNATURE_TYPE (0 EOA / 1 proxy / 2 Safe / 3 deposit wallet)
# optional: POLYMARKET_MAX_ORDER_USD (spend cap per order, default 100)Tools: trading_status, place_limit_order, place_market_buy, my_open_orders,
cancel_order, my_positions. Every order is bounded by the spend cap.
Transparency — builder attribution. Orders placed through this server carry the
newsbet builder code (0 bps maker/taker — you pay no extra fees); Polymarket's
Builders program attributes routed volume to the project. Forks can override via
POLYMARKET_BUILDER_CODE.
Security. Your key never leaves your machine and is never logged. Use a dedicated trading wallet with limited funds. Market SELL is deliberately not offered (ambiguous upstream semantics) — sell via limit orders.
Known upstream caveat (July 2026). Polymarket's py-clob-client-v2 currently cannot
sign for NEW "deposit wallet" accounts (#52,
#70,
#76). Accounts created via
the Polymarket website with a browser wallet (signature types 0/1/2) work — set
POLYMARKET_FUNDER to your Polymarket profile address.
Jurisdiction. Polymarket's CLOB rejects orders from restricted regions (incl. the US) server-side; using these tools where prohibited is on you. Nothing here is financial advice.
IDF-weighted term overlap between your text and market questions/event titles, plus:
phrase (bigram) agreement, numeric normalization ($120,000 ≡ 120k), accent folding,
a salience gate (every match needs a rare informative anchor — "openai", never "the"),
one-best-market-per-event dedupe, and a relative cutoff. Market data comes from
Polymarket's public Gamma API (top ~2,000 markets by liquidity, cached 15 minutes at
~/.cache/polymarket-news-mcp/). First call after a cold start takes ~10–15s to build
the index; subsequent calls are instant.
Informational only — not financial advice. Polymarket availability depends on your jurisdiction; this server never places orders.
News feed sources: CoinDesk, Cointelegraph, Decrypt, The Block, SEC, BBC World & Politics, ESPN (RSS). PRs welcome for more.
Match scores ≥15 are high-confidence; 10–15 are related-entity matches.
MIT
Look up one market by its polymarket.com URL, event slug, or market slug.
| Name | Required | Description | Default |
|---|---|---|---|
| slug_or_url | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it only says 'look up' and does not disclose the return shape, behavior when no market matches, or any error cases. It conveys a read operation but little beyond what the name already suggests.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no filler. Every word adds information about what the tool does and how to call it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter lookup tool, this is adequate for invocation, but the absence of an output schema and any note on not-found or resolution behavior leaves some context missing. The agent knows what to pass but not what to expect back beyond the implied market object.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no description for slug_or_url (0% coverage), so the description compensates by explaining the parameter accepts a URL, event slug, or market slug. It adds real meaning without providing examples or validation details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action ('look up') on a specific resource ('one market') and enumerates three accepted identifier forms (URL, event slug, market slug). This distinguishes it from the sibling search_markets and trending_markets tools, which operate over collections rather than a single market.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The implied usage is clear: use this tool when you already have a Polymarket URL or slug and need that single market. However, it never explicitly says when to prefer the sibling tools or what conditions make search_markets or trending_markets the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Live feed: recent headlines from major news sources, each matched to the Polymarket markets it could move. The 'what does the news mean for the odds' view. Only headlines with at least one confident market match are returned.
| Name | Required | Description | Default |
|---|---|---|---|
| top_k | No | ||
| max_age_hours | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It does add one key behavior: only headlines with a confident market match are returned. However, it does not explain what 'confident' means, how results are ordered, how recent 'recent' is, or any pagination/rate-limit behavior. The core filtering trait is disclosed, but deeper behavioral details are absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the first sentence states the core function, the second frames the user-facing value, and the third clarifies the filtering criterion. Every sentence earns its place with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description gives a functional overview and the output schema exists, but it omits essential operational details for a parameterized feed: how top_k and max_age_hours behave, what ordering is used, and how 'confident market match' is determined. The presence of an output schema reduces the need to explain return values, but the parameter semantics gap leaves the definition incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the two parameters, top_k and max_age_hours. It does not mention either parameter or how they influence results. The phrase 'recent headlines' vaguely relates to max_age_hours, but no explicit mapping or semantic guidance is provided beyond the parameter names themselves.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a live feed of recent headlines matched to Polymarket markets, with a specific perspective ('what does the news mean for the odds'). It distinguishes itself from siblings like match_news by being a continuous feed rather than a one-off matching operation, and the filtering rule ('only headlines with at least one confident market match') sharpens the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use this tool: when you want a live, pre-matched view of news relative to market odds. It does not explicitly name alternatives or exclusions, but the 'live feed' framing plus sibling names like search_markets and match_news make the intended use reasonably evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find the Polymarket markets a news headline or snippet could move.
Pass a headline (optionally with a sentence or two of body text). Returns matched markets with live odds, 24h volume, deep links, a match_score (higher = stronger term overlap; >=15 is a confident match), and the exact matched_terms that fired, so you can judge the match yourself.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| top_k | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral disclosure burden. It does well by explaining the scoring semantics ('higher = stronger term overlap; >=15 is a confident match'), the output fields, and that matched_terms is provided so the agent can judge the match itself. It does not cover edge cases like no matches, but the disclosed behavior is substantive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose, then covers input format, output fields, and score interpretation. Every sentence adds useful information without restating schema boilerplate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter read-oriented matching tool, the definition covers invocation, result contents, and score interpretation, and an output schema exists to handle remaining return-structure details. The main gaps are the unexplained top_k parameter and the lack of explicit routing against siblings like latest_matched_news, neither of which blocks correct use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does explain the text parameter as a headline with optional body text, but it never mentions or explains top_k, leaving its meaning to be inferred from the parameter name and default. This is only partial compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence identifies a specific verb-resource pair: 'Find the Polymarket markets a news headline or snippet could move.' It clearly distinguishes match_news from generic search_markets or trending_markets by focusing on news-to-market matching and term-overlap scoring.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit input guidance: pass a headline and optionally body text, and explains how to interpret results via match_score and matched_terms. It does not explicitly name alternative tools or state when not to use it, but the use case is clearly implied and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free-text search over active Polymarket markets (lenient matching).
Use for questions like 'what markets exist about the Fed' — returns the most relevant active markets with live odds and links.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| top_k | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It discloses that matching is lenient, only active markets are returned, and results include live odds and links. This gives the agent a useful behavioral model beyond the bare operation name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two focused sentences: behavior first, then a concrete usage example. Every clause contributes useful information, and there is no repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The behavior and use case are well described, and an output schema exists, so return-value details are not necessary. However, the top_k parameter is left undocumented in both the schema and the description, creating a minor but real gap for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% property description coverage, so the description must compensate. It indirectly explains query through 'questions like...' but never explains top_k, its meaning, or how it controls the number of results. An agent must infer this from the parameter name and default value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Free-text search over active Polymarket markets', giving a specific verb and resource. It also adds 'lenient matching' and clarifies output as 'most relevant active markets with live odds and links', which distinguishes it from sibling tools like trending_markets, get_market, and match_news.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says 'Use for questions like...' and provides a concrete example ('what markets exist about the Fed'), making the intended use case clear. It does not name alternatives or exclusions, but the context is strong enough for an agent to know when to apply it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The most active Polymarket markets right now, by 24h volume.
| Name | Required | Description | Default |
|---|---|---|---|
| top_k | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It specifies the time-window and volume ranking, but it does not state ordering direction, result count limits, or whether the operation is read-only. It is adequate but not rich in behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short front-loaded sentence with no filler. It immediately communicates the core behavior and market scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but the description does not explain the optional top_k parameter or any limits on results. The output schema exists but is not shown, so the description is the only guidance for the agent; it leaves a notable gap around controlling result size.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema gives top_k only a type and default value with no description, and the tool description does not mention the parameter at all. Although 'top_k' is somewhat self-explanatory, the description misses the opportunity to clarify its role or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool returns the most active Polymarket markets by 24h volume. This is a specific resource and criterion, and it distinguishes the tool from siblings like get_market (single market) and search_markets (search).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for discovering currently active or trending markets, but it does not explicitly state when to prefer it over search_markets or get_market. There is no when-not-to-use guidance or mention of alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_marketlatest_matched_newsmatch_newssearch_marketstrending_marketsScored across 5 tools
Each tool addresses a distinct scenario: exact lookup, free-text search, trending discovery, matching user-provided news, and browsing a live matched feed. There is no meaningful overlap or ambiguity between tools.
Three names follow a verb_noun pattern (get_market, search_markets, match_news), but latest_matched_news and trending_markets are adjective_noun phrases. The snake_case is consistent, but the verb-first convention is not uniformly applied, making the set readable but mildly inconsistent.
With five tools, the count is well-scoped for the server's purpose of connecting news to Polymarket markets. Each tool serves a clear function with no redundancy or bloat.
The set covers the full workflow: discovering markets via search or trends, retrieving specific market details, matching incoming news to markets, and consuming a live feed of already-matched news. There are no dead ends, and any referenced market can be looked up directly.
Live odds and markets from the major prediction markets.
Live prediction markets: Polymarket + Kalshi prices, odds, order books. Pay-per-call USDC, no key.
Live prediction-market odds, volume and movers across 8 platforms. Read-only, no auth.
Live Kalshi + Polymarket prediction-market data and cross-venue arbitrage spreads, one schema.
