What can you do with this server?

This server provides tools to discover, analyze, and trade on Polymarket CLOB V2 prediction markets, with live and paper trading modes, account management, and fee estimation. All operations are subject to operator-set hard limits (per-order caps, daily budgets) that agents cannot override. * find_markets — Search for tradeable markets by keyword or top 24h volume; returns event titles, slugs, and outcome names. * event — List all binary markets within a multi-outcome event (e.g., election, tournament), with per-market slugs, token IDs, close times, and settled winners. * market — Resolve a market by its gamma slug to get its condition ID, outcome-to-token-ID mappings, close time, and settled winner (works for expired markets too). * book — Fetch a real-time order book summary for a specific outcome token: best bid/ask with sizes and USD notional depth within a price range. * taker_fee — Calculate the official Polymarket taker fee in USD for a given price, share count, and market category. * account_collateral — Check the CLOB-visible pUSD balance for the configured account (or simulated paper balance), with diagnostics for signature_type issues. * account_trades — Get BUY-side totals (shares, USD spent, fees) for a market; serves as the reconciliation source after uncertain orders. * fak_buy / fak_sell — Execute fill-and-kill orders to open or close positions with no resting orders left on the book. Requires PMQ_MCP_LIVE=1 and API keys for live trading; paper mode simulates against real order books with no keys needed. * cancel_and_reconcile — Cancel all resting orders on a market and return the account's true exchange state. Also requires explicit operator enablement for live trading. Read-only market data tools require no API keys. Trading tools are operator-gated and can be simulated in paper mode (PMQ_MCP_PAPER=1) using the same response format as live trading.

pmq

by crp4222

Overview Schema Source Related Servers Discussions Admin

Python

Remote

pmq

PyPI tests canary coverage gate typed OpenSSF Scorecard license

Fail-closed execution and market data for Polymarket CLOB V2, in Python, built agent-first. Local signing (your keys never leave your process), exchange-confirmed fills only, fee-correct math, deposit-wallet (POLY_1271) support that actually works in production, order-attribution registries (several bots can share one wallet, each with its own exchange-truth accounting), and a bundled MCP server: plug any LLM or agent framework that speaks MCP (Claude, ChatGPT, LangChain, your own loop) on top and it can read every market and, if and only if the operator enables it, trade under hard rails: tools that do not exist until you create them, a cap per order, a daily buy budget. The model cannot widen any of this from inside a session.

pip install pmquant        # Python >= 3.10; distribution pmquant, import pmq

(PyPI's similarity check reserves the bare name; the module you import is pmq, same pattern as beautifulsoup4/bs4.)

Try it in 30 seconds, no keys

Point any MCP client at uvx; it installs the MCP extra in an isolated environment and starts pmq-mcp with one environment variable:

{
  "mcpServers": {
    "pmq": {
      "command": "uvx",
      "args": ["--from", "pmquant[mcp]", "pmq-mcp"],
      "env": { "PMQ_MCP_PAPER": "1" }
    }
  }
}

PMQ_MCP_PAPER=1 registers the same trading tools as live, but fills are simulated against the real live order books using the displayed best quote, venue minimums, and a documented crypto-rate fee estimate. The first paper ledger starts at 1000 USD, configurable with PMQ_MCP_PAPER_USD; it then persists locally across server restarts. No keys are needed and no order can reach the exchange. A real session, captured 2026-07-04, quoted verbatim:

> find_markets(query="fed decision july")
    12 markets, among them "How many dissent at the July Fed meeting?"
> market(slug="will-no-one-dissent-the-july-fed-decision-20260616001928666")
    condition_id 0x50ba...7967, token ids for Yes and No, closes 2026-07-29
> book(token_id=<Yes>)
    bid 0.54 x 592.75 | ask 0.56 x 21 | min order 5 shares | tick 0.01
> fak_buy(token_id=<Yes>, price_cap=0.58, usd=10)
    paper fill: 17.8571 shares at 0.56 (the real ask, not the cap),
    fee 0.308, cash left 989.69
> account_collateral()
    989.69 paper USD

Five calls: discover, resolve, read the live book, buy with simulated money at the real ask, check the balance. The same session rendered as a step-by-step page: docs/demo.html (one self-contained HTML file, no JavaScript, no external requests; download and open it). Trading real money additionally requires keys and an explicit PMQ_MCP_LIVE=1, under the rails in the agents section.

As of 2026-07-03 this is, to our knowledge, the only maintained Python layer combining local CLOB V2 signing, an exchange-confirmed fill contract, and working deposit-wallet (POLY_1271) auth. That claim is dated and falsifiable: docs/comparison.md names the alternatives and what each does instead; open an issue if it goes stale.

Related MCP server: polymarket-mcp

Quickstart

Market data needs no keys:

import pmq

m = pmq.parse_market(pmq.get_market("btc-updown-15m-1783062000"))
book = pmq.get_book(m["token_a"])
bid, bid_sz, ask, ask_sz = pmq.best_bid_ask(book)
print(ask, pmq.band_ask_depth_usd(book, 0.90, 0.97))
print(pmq.fee(price=0.95, shares=100))          # taker fee in $, crypto rate

Execution (reads POLY_PRIVATE_KEY, POLY_FUNDER, POLY_SIG_TYPE from the environment):

from pmq import PolymarketExecutor, OrderUncertain

ex = PolymarketExecutor()                        # signature_type=3 for the app's deposit wallet
ex.require_collateral(5.0)                       # fail fast, with a diagnostic that names sig_type

try:
    fill = ex.buy_fak(token_id=m["token_a"], price_cap=0.95, usd=5.00)
except OrderUncertain:
    ex.reconcile(m["condition_id"], m["token_a"])   # exchange truth before anything else
else:
    if fill:                                     # book ONLY what matched
        print(fill.matched_shares, "shares at", fill.price, "order", fill.order_id)

sell_fak and limit_gtc follow the same contract, and all three paths have carried production volume: a FAK round trip (buy 5.149 @ 0.94, sell back 5.14 @ 0.94, cross-checked via get_trades, 2026-07-03) and a GTC maker fill (posted above the bid, matched as MAKER at zero fee, 2026-07-04, settlement tx in the production section below).

Scope, latency, requirements

Python 3.10 to 3.14 (the CI matrix runs all five). Plain REST round trips, measured 2026-07-04 (medians of 5, residential fiber, Western Europe): resolve a market 76 ms, fetch a book 85 ms, sign + POST an order and get the exchange's answer 73 ms. Sub-second everywhere, built for second-scale strategies (the maintainer's bot polls 15-minute windows every 2.5 s); it is not a microsecond market-making stack: no websockets, no co-location, one HTTP call per action.

Why this exists

Polymarket cut over to CLOB V2 on 2026-04-28. V1-signed orders are rejected in production, the fee schedule is decided at match time, and the official client examples leave several traps undocumented. Every line of pmq was paid for with a real error in live trading:

invalid amounts, the market buy orders maker amount supports a max accuracy of 2 decimals, taker amount a max of 4 decimals: the CLOB treats FAK/FOK buys as market orders and caps their signed amounts at 2 decimals (maker) / 4 decimals (taker) whatever the tick size. The official client's rounding table allows 5-6 taker decimals on markets whose tick is finer than 0.01 (any book trading past 0.96 or under 0.04), so market orders there are rejected wholesale (reported upstream: py-clob-client-v2#99). pmq clamps the signed pair to the exchange caps before signing and refuses at startup any client build that would still sign a rejectable pair, so the trap cannot reach your orders. Measurements in docs/rounding-study.md.
no orders found to match with FAK order (HTTP 400, yet with an orderID): a clean no-fill, not an error. pmq returns an empty Fill instead of crashing or, worse, retrying blindly.
CLOB shows balance: 0 while your pUSD sits on-chain: the balance endpoint ignores your funder parameter and derives the wallet from your EOA and signature_type. Funds in the Polymarket app's default wallet (an ERC-1271 deposit wallet) are only visible with signature_type=3.

The full write-up with reproduction details: docs/war-story.md.

Runs in production: my own money, daily

I built pmq for my own trading. It executes real volume with my funds every day, and it has never booked a fill the exchange did not confirm. If you want to see it on-chain, here is a settlement from one of my wallets (2026-07-03): 0x387f5f09...100d88a8 on the CTF Exchange V2: a FAK market buy built by this library, matched and settled, with the builder code visible in the calldata. The maker path has its own receipt (2026-07-04): a limit_gtc posted one tick above the bid, matched as MAKER at zero fee and settled in 0x1b60f19a...c35d09, where the maker_orders slice accounting that release 0.4.6 encodes is visible in the raw trade record. A weekly canary workflow exercises the real endpoints and the installed client surface, and opens an issue by itself if Polymarket drifts.

pmq-doctor: diagnose your setup in one command

pip install pmquant && pmq-doctor --market <slug>

It checks, in order: the installed client surface (introspection), your derived EOA, the funder wallet on-chain (owner() and bytecode: is it a deposit wallet?), whether POLY_SIG_TYPE matches the wallet type, whether the CLOB actually sees your collateral (and if not, WHICH sig_type does), and the target market's minimum size and tick. Real output on a real deposit-wallet account:

pmq-doctor output

If you landed here from "the order signer address has to be the address of the API KEY" or a CLOB balance of 0 with funds on-chain: this is the tool.

The contract: nothing is booked without exchange confirmation

Situation	What pmq does
Response is a dict with `orderID`, not flagged failed	`Fill` with the matched size read from the response
Error dict on HTTP 200, string body, `success: false`	`Fill(rejected=True)`, zero booked
HTTP 4xx (incl. FAK no-match)	`Fill(rejected=True)`, zero booked
Timeout, 5xx, exception after send	raises `OrderUncertain`: the order MAY exist. Call `reconcile()` before trading that market again
Unparseable matched amounts	zero booked (fail closed)

reconcile(condition_id) cancels anything resting, verifies nothing stayed open, and returns (shares, usd, fees) from get_trades: the exchange truth.

At startup pmq introspects the installed py-clob-client-v2 against the API surface it was verified on, and refuses to trade on drift instead of sending orders through changed semantics. The whole table is pinned by an executable test per row plus a hypothesis fuzz suite (hundreds of generated adversarial responses per run, including NaN/Infinity and negative amounts, which book zero).

Several bots, one wallet

get_trades is account-level: run two bots on the same wallet and each one's exchange-truth totals silently include the other's fills. Since 0.5.0 every order-sender can keep an attribution registry: an append-only file of its own order ids, written on every confirmed post.

ex = PolymarketExecutor(order_log="botA.orders",
                        foreign_order_logs=["botB.orders"])
# or per process: POLY_ORDER_LOG=botA.orders POLY_FOREIGN_ORDER_LOGS=botB.orders

With a registry configured, trades_totals() counts only trades whose taker_order_id (taker role) or maker_orders[].order_id slice (maker role) belongs to OUR registry (both fields verified present and populated on real V2 trade records), and reconcile() additionally claims trades unknown to EVERY registry, so a fill posted during an uncertainty window is recovered by the bot that was uncertain and by nobody else. Sound only if every sender on the wallet keeps a registry (POLY_FOREIGN_ORDER_LOGS is colon-separated). The MCP server inherits the registries through the same environment variables. Fully opt-in: without POLY_ORDER_LOG the behavior is unchanged.

Streaming the resolution prices

The updown markets resolve on the Chainlink stream, and wss://ws-live-data.polymarket.com republishes that exact stream (plus a Binance spot mirror). pmq.stream.PriceStream consumes it with the standard library only:

from pmq.stream import PriceStream

ps = PriceStream(assets=("btc", "eth")).start()
ps.last("btc")               # (unix_seconds, value) from the Chainlink feed
ps.age("btc")                # seconds since the freshest tick
ps.last("btc", "binance")    # the spot mirror, for comparison

Design note, measured 2026-07 from two unrelated egresses: the edge serves the sustained push only to browser connections; a plain client gets the initial tick batch after subscribing, then silence. PriceStream therefore re-polls short connections (about one per second); the freshest tick is typically 1.2 to 2.8 seconds old. Treat the feed as advisory and fail closed on age(): the exchange resolves with its own copy.

The signature_type decoder table

`signature_type`	Wallet	When it is yours
0	the EOA itself	you trade from a bare private key
1	`POLY_PROXY`	email/Magic accounts (legacy)
2	`POLY_GNOSIS_SAFE`	browser-wallet proxy
3	`POLY_1271` deposit wallet	the Polymarket app's default wallet

If collateral() returns 0 while the funds are visible on-chain on your funder address, your signature_type is wrong. Debug trick: eth_call owner() (0x8da5cb5b) on the funder; if it returns your EOA and the wallet bytecode is an ERC-1167 proxy, you want signature_type=3.

Alternatives

NautilusTrader if you want a full backtesting and trading framework; pmxt if you accept routing writes through a hosted backend; raw py-clob-client-v2 if you want no opinion layered on the official client. The dated feature-by-feature table (written by an interested party, every row checkable) lives in docs/comparison.md.

Builder code disclosure

pmq ships with the maintainer's public Polymarket builder code as default attribution inside signed orders (pmq.executor.DEFAULT_BUILDER_CODE). Its commission is set to 0/0: it never adds any fee to your orders. Attribution feeds Polymarket's builder program and funds this project at zero cost to you.

Agents: the MCP server

For an installed server, run pip install "pmquant[mcp]" then pmq-mcp (stdio). For a clean MCP-client configuration, use uvx --from "pmquant[mcp]" pmq-mcp as in the paper example above. Listed in the official MCP registry as io.github.crp4222/pmq, it works with Claude Desktop or Code, ChatGPT, LangChain, and a bare SDK loop.

What an agent can do, exactly:

Tool	Needs	What it does
`pmq_status`	nothing	mode, registered trading surface, caps, daily headroom, and durable-state health without constructing a signer
`find_markets`	nothing	discover active markets, any category, full-text search
`event`	nothing	all binary markets of a multi-outcome event (elections, tournaments)
`market`	nothing	slug to condition id, outcome names, token ids, close time, winner
`market_snapshot`	nothing	resolve a market and read a top-of-book summary for every outcome in one call
`book`	nothing	real-time bid/ask with sizes, depth in a price range, exchange minimums
`order_preview`	nothing	non-mutating top-of-book FAK estimate with rails and a crypto-rate fee estimate; it never creates a signer, submits an order, or reserves budget
`taker_fee`	nothing	official fee formula per category, cost per share including fee
`account_collateral`	paper mode, or keys	paper cash or the CLOB-visible live balance with a sig_type diagnostic
`account_trades`	paper mode, or keys	paper totals or exchange-truth BUY totals on one market
`account_portfolio`	paper mode, or public wallet	durable paper positions, or public Data API positions for `wallet` or `POLY_FUNDER`
`fak_buy`	`PMQ_MCP_PAPER=1`, or keys plus `PMQ_MCP_LIVE=1`	open a position with a fill-and-kill buy; nothing rests
`fak_sell`	`PMQ_MCP_PAPER=1`, or keys plus `PMQ_MCP_LIVE=1`	close a position with a fill-and-kill sell under the same contract
`cancel_and_reconcile`	`PMQ_MCP_PAPER=1`, or keys plus `PMQ_MCP_LIVE=1`	cancel resting orders and return reconciliation truth; paper has nothing resting

With PMQ_MCP_PAPER=1 (the 30-second demo above) the same trading and account tools are registered keyless: fills are simulated at the displayed best quote, capped by the displayed size, refused under the exchange minimum, and the account tools report the durable paper ledger. order_preview remains read-only in every mode. Paper responses are flagged paper: true, and no order reaches the exchange.

The rails, all operator-set (server environment, invisible to and untouchable by the model):

Variable	Effect	Default
`PMQ_MCP_LIVE`	unset: the three trading tools are never REGISTERED; an agent cannot call a tool that does not exist	read-only
`PMQ_MCP_PAPER`	trading tools simulate fills against the real live books, keyless, nothing sent to the exchange; wins over `PMQ_MCP_LIVE` when both are set	off
`PMQ_MCP_PAPER_USD`	initial paper balance when a new state file is created	1000
`PMQ_MCP_MAX_USD`	hard cap per single order, live and paper alike	10
`PMQ_MCP_DAILY_USD`	durable cumulative BUY budget per UTC day; unknown live results retain their requested reservation through that UTC day	off
`PMQ_MCP_STATE_FILE`	local file for the durable paper ledger and daily budget	`$XDG_STATE_HOME/pmq/mcp-state.json`, otherwise `~/.local/state/pmq/mcp-state.json`
`POLY_*` keys	omit them entirely for a data-only server	absent

Structural rails on top: only FAK orders exist (nothing rests unattended on the book), every uncertain outcome is surfaced for reconciliation, and fills are booked only from exchange confirmations, never from optimism.

The state file contains paper cash, positions, fills, and the daily budget, never key material. It is atomically replaced on update. Use a distinct state file for each concurrently running server. A live buy reserves its requested amount before the client call, then settles that reservation to an exchange-confirmed amount. A clean rejection releases it; an unknown outcome keeps the full reservation through the UTC day. pmq_status exposes state health without exposing secrets. If a required durable write fails, the affected buy is refused rather than proceeding without its rail.

{
  "mcpServers": {
    "pmq": {
      "command": "uvx",
      "args": ["--from", "pmquant[mcp]", "pmq-mcp"],
      "env": {
        "PMQ_MCP_LIVE": "1",
        "PMQ_MCP_MAX_USD": "10",
        "PMQ_MCP_DAILY_USD": "25",
        "POLY_PRIVATE_KEY": "...",
        "POLY_FUNDER": "0x...",
        "POLY_SIG_TYPE": "3"
      }
    }
  }
}

Remove PMQ_MCP_LIVE and the POLY_* variables entirely for a read-only market-data server.

Bot template

bot-template/ is a complete bot minus the strategy, for ANY market (politics, sports, crypto, culture): paper mode against real books with real fees, per-market budgets with fee headroom, poisoned-market reconciliation, consecutive-failure halt, disk-persisted daily loss halt, a systemd unit with RestartPreventExitStatus=42 so halts stay halted, and a lightweight phone dashboard. You implement watchlist() and decide(); the shipped demo strategy is an API illustration meant to be replaced.

Security posture

Keys are read from the environment, used to instantiate the signer, and never logged. No custody, no backend, no telemetry, zero network calls besides Polymarket endpoints.
A documented wave of fake "polymarket bot" repositories steals private keys; pmq is deliberately small so the entire execution path stays readable in minutes by anyone who wants to look.
Fund the trading wallet with what you can afford to lose. Nothing here is financial advice; prediction-market access is restricted in some jurisdictions and compliance is on you.

If you feel like checking any of it

None of the claims above require taking my word; each one comes with a handle you can pull, whenever you care to:

Egress. PMQ_CANARY=1 pytest tests/test_canary_live.py -k egress -s records every DNS resolution during a full session (market data, auth derivation, one signed order) and fails on any host outside polymarket.com. Last observed list: clob.polymarket.com, gamma-api.polymarket.com, nothing else. The weekly canary prints that list in public CI logs. One designed exception: pmq-doctor's optional on-chain checks use the public Polygon RPCs named in its source.
Provenance. Releases carry a signed PEP 740 attestation (Sigstore, via PyPI trusted publishing): click "provenance" next to any file on the PyPI files page, or fetch it raw from PyPI's integrity API. The signing identity is this repository's publish.yml workflow.
Dependencies. Dependabot files weekly bump PRs (Python and SHA-pinned GitHub Actions), and the weekly canary runs pip-audit; a hit opens an issue by itself.
The source. Five small modules; the whole execution path reads in minutes. The grep targets that answer the important questions fastest are listed in SECURITY.md.

Stability and maintenance

Pre-1.0 SemVer with a written deprecation window and a stated bar for 1.0; one maintainer, trading his own money through this exact code daily. The operational rule worth knowing: if the canary badge goes red and stays red, treat the project as unmaintained and pin your last known-good version. Full policy and the precisely scoped help-wanted: docs/stability.md.

License

MIT

Available Tools

11 tools

account_collateralA

Collateral (pUSD, $) the CLOB sees for the configured account. If this is 0 while funds are on-chain, the operator's POLY_SIG_TYPE is wrong (the Polymarket app's deposit wallet needs 3). In paper mode: the simulated cash balance.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Without annotations, the description should explicitly indicate the tool is read-only. While 'collateral the CLOB sees' implies a query, it does not confirm non-destructive behavior or disclose any other behavioral traits like authentication or rate limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences efficiently convey purpose and additional context (troubleshooting, paper mode) without fluff. Slightly more verbose than necessary but well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Provides enough context for a parameterless tool with an output schema. Diagnostic info adds value, but could mention that output format is numeric (collateral value). Still, overall complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist, so baseline of 4 applies. Description adds context about output meaning but no parameter info needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves collateral (pUSD/$) as seen by the CLOB for the configured account, distinguishing it from sibling tools like account_trades (trades) or market data tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides diagnostic context (what to check if collateral is 0) and mentions paper mode behavior, but does not explicitly state when to use this tool over alternatives or when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

account_portfolioA

Current portfolio without placing an order. Paper mode returns the local durable ledger. Otherwise pass a public wallet address, or configure POLY_FUNDER, to read its public Data API positions. Data API values lag the matching engine and are not exchange reconciliation truth.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`wallet`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.8/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses important behavioral traits: Data API values lag the matching engine and are not exchange reconciliation truth. This adds transparency beyond the input schema. No annotations provided, so description carries full burden.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two dense sentences, no wasted words. Front-loaded with core purpose, efficient in structure.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers modes, wallet configuration, and data lag caveat. Output schema exists, so return values are documented elsewhere. Limit parameter omission is a gap, but overall sufficient for an agent given the output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Only the wallet parameter is partially explained (public wallet address for live mode). The limit parameter is not mentioned in the description; schema has 0% coverage, so the description fails to explain its purpose.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns the current portfolio without placing an order, distinguishing it from order placement tools. However, it does not explicitly differentiate from sibling tools like account_collateral, though 'portfolio' implies a broader view.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides clear guidance on when to use paper mode vs. live mode, and how to configure wallet address via parameter or environment variable. Lacks explicit when-not-to-use or comparison to siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

account_tradesA

BUY-side totals of OUR account on one market: (shares, usd, fee_estimate), usd and fees counting BUY fills only. This is the reconciliation source, use it after any uncertainty instead of trusting local bookkeeping. Paper mode: same semantics over the simulated fills, except shares are net of paper sells (position, not gross buys).

ParametersJSON Schema

Name	Required	Description	Default
`token_id`	No
`condition_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description effectively discloses behavior: it only counts BUY fills for USD and fees, and explains paper mode semantics (shares are net of sells). It does not mention whether the operation is read-only or has side effects, but the verb 'totals' implies a read operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with three sentences covering purpose, usage guidance, and paper mode. It is front-loaded with the core function. However, it could be slightly more structured with bullet points or clearer separation between normal and paper mode semantics.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 2 parameters (1 required) and an output schema (not shown but exists), the description sufficiently explains the return values and core behavior for both production and paper mode. It lacks details on the optional token_id parameter and potential side effects, but overall meets the needs for a reconciliation tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage for its two parameters (condition_id, token_id). The description mentions 'on one market' which likely maps to condition_id but does not explicitly define either parameter or their usage. Token_id is not addressed, leaving ambiguity.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns 'BUY-side totals of OUR account on one market' with specific fields (shares, usd, fee_estimate). It distinguishes the tool from siblings by emphasizing it is the 'reconciliation source' for post-uncertainty verification, setting it apart from local bookkeeping and other market tools like 'book' or 'market'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly guides when to use: 'use it after any uncertainty instead of trusting local bookkeeping'. This provides clear context for appropriate usage, though it does not directly compare against sibling tools like 'account_collateral' or 'taker_fee'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

bookA

REAL-TIME order book summary for one outcome token: best bid/ask with sizes, plus the $ notional of asks resting inside [depth_lo, depth_hi]. This endpoint is served by the matching engine; trust it over the trade tape for any live decision.

ParametersJSON Schema

Name	Required	Description	Default
`depth_hi`	No
`depth_lo`	No
`token_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so the description carries the full burden. It states the tool is REAL-TIME and served by the matching engine, adding behavioral context beyond the schema. However, it does not disclose auth needs, rate limits, or any destructive behavior, which is acceptable for a read-only query tool but still leaves gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences long, efficiently front-loading the key outputs and adding a trustworthiness note. Every sentence adds value with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 3 parameters, no annotations, and an output schema exists, the description covers the main outputs (best bid/ask, sizes, notional) and the depth range. It does not mention pagination or error handling, but for a simple order book snapshot, it is fairly complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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 explains the depth_lo and depth_hi parameters as defining the range for asks notional, and implies token_id as the outcome token identifier. However, it does not explain default values or units, leaving some meaning only partially clarified.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it provides a real-time order book summary for one outcome token, including best bid/ask, sizes, and notional inside a depth range. It distinguishes itself from siblings by focusing on order book depth and live matching engine data.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context that this endpoint is served by the matching engine and should be trusted over the trade tape for live decisions. It implicitly suggests when to use (for live decisions) and provides a comparison (trade tape), but lacks explicit when-not-to-use or alternatives among siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

eventA

All binary markets of one multi-outcome EVENT (an election, a tournament: one market per candidate). Use the event slug from find_markets. Returns per market: slug, outcome names with token ids, close time, settled winner if any.

ParametersJSON Schema

Name	Required	Description	Default
`slug`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description discloses the return structure (slug, outcome names, token ids, close time, settled winner) and that it returns multiple markets. It does not mention auth or rate limits, but for a read operation this is adequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences front-load purpose, provide a usage hint, and detail return format. Every sentence earns its place without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one parameter and existing output schema, the description covers core behavior and return format. It lacks mention of error handling or limits but is largely complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 0% coverage, but the description explains the 'slug' parameter's origin and purpose ('Use the event slug from find_markets'), adding significant meaning beyond the empty schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves all binary markets of a multi-outcome event, specifying 'All binary markets of one multi-outcome EVENT' and distinguishing from siblings like 'market' (single market) and 'find_markets' (search).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly instructs to use the event slug from find_markets, providing a clear prerequisite. While it doesn't list when not to use, the sibling context implies alternatives for single markets or search.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

find_marketsA

Discover tradeable Polymarket markets of ANY kind (politics, sports, crypto, culture). With a query, full-text search; without, the most active events by 24h volume. Returns event title plus, per market, the slug to pass to the market tool and the outcome names.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`query`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.1/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided. The description implies read-only behavior ('Discover') and explains the two operational modes. However, it does not explicitly declare non-destructiveness, auth requirements, or rate limits. For a search tool, the transparency is adequate but not fully explicit.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the main purpose, and contains no superfluous words. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has an output schema (so return values are documented externally), the description covers the essential usage context: search modes, result contents, and linkage to the sibling 'market' tool. It is complete for an agent to decide when and how to invoke it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate. It explains the 'query' parameter through the two modes, but does not mention the 'limit' parameter (its meaning or default). This partial explanation is helpful but incomplete.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Discover') and resource ('Polymarket markets of ANY kind'), and distinguishes two modes (with/without query). It clearly differentiates from sibling tools like 'market' by mentioning the slug to pass to it.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description tells when to use with query (full-text search) vs without (most active by volume). It references the sibling 'market' tool for subsequent steps but does not explicitly state when not to use or provide alternatives beyond that.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

marketA

Resolve one Polymarket market by its gamma slug (any category, works for expired short-lived markets too). Returns condition_id, the outcome names mapped to their token ids (use those token ids with book and the trading tools), the close time and the settled winner if resolution already happened.

ParametersJSON Schema

Name	Required	Description	Default
`slug`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.3/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must carry the full burden of behavioral disclosure. The description indicates it 'resolves' a market, which might imply a read operation, but does not explicitly state it is read-only or non-destructive. It adds context about expired markets but lacks information on auth needs or rate limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, each serving a distinct purpose: the first explains the action and scope, the second details the output and usage. There is zero wasted text, and the most critical information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has only one parameter and an output schema exists (though not shown), the description comprehensively covers the output fields (condition_id, token ids, close time, winner) and provides integration guidance with sibling tools. It is fully sufficient for the agent to understand and invoke the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single parameter 'slug' has 0% schema description coverage, but the description explains it is a 'gamma slug' that works for any category, including expired short-lived markets. This adds meaning beyond the schema's title 'Slug', helping the agent understand the parameter's nature and scope.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool resolves a Polymarket market by gamma slug, works for any category including expired short-lived markets. It specifies the returned data: condition_id, outcome names mapped to token ids, close time, and settled winner. This distinguishes it from siblings like 'find_markets' (search) and 'event' (event-level data).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description tells the agent to use the returned token ids with 'book' and trading tools, providing clear post-invocation guidance. It does not explicitly state when to choose this tool over alternatives like 'find_markets' or 'event', but the context of resolving by slug is implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

market_snapshotA

One read-only decision snapshot: resolve a market and return the live top-of-book summary for each outcome. This does not place or prepare an order, and a missing book is reported only for that outcome.

ParametersJSON Schema

Name	Required	Description	Default
`slug`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.7/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the burden. It discloses read-only nature, no order actions, and error handling for missing books. But it omits authentication requirements, rate limits, or behavior on invalid inputs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely concise: two sentences with no wasted words. The first sentence immediately conveys the core purpose and read-only nature. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one parameter and an output schema, the description provides appropriate context: it's a snapshot, returns top-of-book per outcome, does not place orders. Minor gap: does not mention output schema exists or what fields are returned.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Only one parameter 'slug' with 0% schema description coverage. The description mentions 'resolve a market' implying slug is a market identifier, but does not explain what format or values it expects, leaving ambiguity.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool is a read-only snapshot that resolves a market and returns the live top-of-book summary for each outcome. It explicitly distinguishes itself from order placement/preparation, and the verb 'resolve' combined with resource 'market' is specific.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description indicates when to use (need a snapshot, not placing/preparing an order) and mentions that a missing book is reported per outcome. However, it does not explicitly compare to sibling tools like 'book' or provide alternative conditions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

order_previewA

Read-only top-of-book FAK preview. For BUY, amount is USD and price_limit is the highest acceptable price. For SELL, amount is shares and price_limit is the lowest acceptable price. It never creates an executor, sends an order, or reserves budget. Fees are an estimate using the documented crypto-table rate until the exchange confirms a fill.

ParametersJSON Schema

Name	Required	Description	Default
`side`	Yes
`amount`	Yes
`token_id`	Yes
`price_limit`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses all key behavioral traits: read-only, top-of-book FAK, no executor/order creation, no budget reservation, and fee estimation behavior. Since no annotations are provided, the description fully fulfills the transparency burden.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with four sentences, no redundant information, and front-loads the core purpose ('Read-only top-of-book FAK preview'). Every sentence contributes essential detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 4 parameters, no schema descriptions, no annotations, and an output schema, the description covers the core semantics and behavior. It omits details about the output structure, but the presence of an output schema mitigates this need. A perfect score would require more explicit guidance on output fields.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds crucial meaning to the parameters by explaining how 'amount' and 'price_limit' differ based on the 'side' (BUY vs SELL). This is not available in the schema, which has 0% description coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool is a 'read-only top-of-book FAK preview' and explicitly distinguishes it from order-execution tools by stating it never creates an executor, sends an order, or reserves budget. This provides a clear verb+resource definition and differentiates it from siblings like order–related tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description indicates when to use the tool (to preview an order) and what it does not do (no order creation). However, it lacks explicit comparisons to sibling tools or conditions for not using it, which would raise the score to 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

pmq_statusA

Operator-visible mode and safety-rail status. This is keyless: it never constructs a signer, checks a live balance, or changes state.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description fully discloses behavioral traits: never constructs a signer, checks a live balance, or changes state. This provides clear transparency for a read-only status tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences front-loading the core purpose and constraints with no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter tool with an output schema, the description sufficiently covers what the tool does, its keyless nature, and what it avoids, making it complete for the agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are zero parameters, so the baseline is 4. The description adds no parameter-specific info but reinforces the tool's keyless nature, which is relevant for usage context.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it retrieves 'Operator-visible mode and safety-rail status' and explicitly distinguishes itself by being keyless and not performing state changes, which differentiates it from sibling tools that likely involve authentication or operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies safe usage without authentication ('keyless') and no state modification, but does not explicitly compare with alternatives or state when to use this tool over others. However, the context signals and sibling names allow inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

taker_feeA

Official Polymarket taker fee in $ (fee = rate * p * (1-p) * shares). Categories and rates: crypto 0.07, sports 0.03, finance/politics/mentions/ tech 0.04, economics/culture/weather 0.05, geopolitics 0. Makers pay 0.

ParametersJSON Schema

Name	Required	Default
`price`	Yes
`shares`	Yes
`category`	No	crypto

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.6/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Describes the calculation formula and lists rates, which is transparent about its behavior. No annotations exist, so description carries full burden; it adequately discloses the fee computation but does not mention if it is read-only or has side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Concise single sentence plus a list of categories. The line break in the list is minor, but overall efficient with no unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple calculation and existence of output schema, the description covers the essential formula and category rates. But lacks explanation of what the output represents and any prerequisites or edge cases.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema coverage, description partially compensates: the formula explains price and shares as inputs (p and shares), and category is linked to rates. However, it does not specify units, ranges, or meaning for price and shares beyond the formula.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it computes the official Polymarket taker fee, provides the formula and lists categories with rates. Distinguishes from sibling tools which are about accounts, books, and markets.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool or when to avoid it. Only lists categories and rates without indicating alternatives or conditions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

4 tool updatesv0.7.0Jul 13, 2026
- Addedaccount_portfolio
- Addedmarket_snapshot
- Addedorder_preview
- Addedpmq_status
7 tool updatesv0.5.0Jul 5, 2026
- First observedaccount_collateral
- First observedaccount_trades
- First observedbook
- First observedevent
- First observedfind_markets
- First observedmarket
- First observedtaker_fee

Deploy Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0

Scored 2026-07-13 17:46 across 11 tools

Disambiguation5/5

All 11 tools target distinct aspects of Polymarket: account balances, portfolio, trades; market discovery, details, order books, and order preview; plus status and fee info. No two tools have overlapping purposes.

Naming Consistency4/5

Most tool names use lowercase underscore with a noun-verb or verb-noun pattern (e.g., account_collateral, find_markets, order_preview). A couple are single-word nouns (book, event) but the pattern is largely consistent and readable.

Tool Count5/5

With 11 tools, the surface covers market data, account info, and order preview without being overwhelming. Each tool serves a clear, non-redundant purpose for a prediction market query interface.

Completeness2/5

For a trading-related server, the lack of order placement, cancellation, or any execution tools is a significant gap. While the read-side is well-covered, agents cannot complete a trading workflow without these operations.

Maintenance

ActivitySlowing

ResponsivenessWithin a week

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Polymarket
io.github.pipeworx-io
Polymarket MCP — prediction-market data via Gamma + CLOB public APIs.
Finance Blockchain
2
Kalshi MCPOAuth
com.kalshi-mcp
Hosted MCP for Kalshi prediction markets: search, odds, order books, settlement rules, and trading.
Finance
1
Parlay AOAuth
run.parlay
Read-only MCP server for live Polymarket, Kalshi, Limitless odds; Manifold sentiment.
Finance Research & Data
626
HYPERneobroker.com A
com.hyperneobroker.mcp
Live prices, perps, prediction markets and a paper trading desk over one MCP.
Finance Cryptocurrency
371

Related MCP Servers

polymarket-mcp
Blockchain Cryptocurrency Finance
BrainDAO
A
license
A
quality
B
maintenance
Enables AI agents to discover and analyze prediction markets, execute trades, and manage positions on Polymarket via the Model Context Protocol.
Updated a month ago (2026-08-10 16:08 UTC)
7
32
20
MIT
polymarket-mcp
Blockchain Cryptocurrency
pr1m8
F
license
A
quality
B
maintenance
AI-agent ready FastMCP server for Polymarket market discovery, wallet analytics, and public CLOB data, providing a read-only interface for querying markets, wallets, and order books.
Updated 5 months ago (2026-04-21 19:29 UTC)
22
-
polymarket-mcp
Finance Blockchain
fzlzjerry
A
license
A
quality
C
maintenance
A read-only MCP server exposing Polymarket's public prediction-market data. Search markets, read live odds and order books, pull historical probability time-series, and inspect public wallet positions.
Updated 3 months ago (2026-06-17 13:46 UTC)
14
MIT
polyrouter-mcp
Finance Web3 & Decentralized Tech
fieldviolence
A
license
Not graded
quality
C
maintenance
MCP server for querying and optionally trading across prediction markets (Polymarket, Kalshi, Limitless, Manifold) through a unified API.
Updated 8 months ago (2026-01-11 22:06 UTC)
31
MIT