Vike Data API

Polymarket Market Trades

polymarket_market_trades

Read-onlyIdempotent

ONE Polymarket market's trades WITH the wallet behind each, newest first, paged: who traded, which side, how many shares and at what price, from 2026-01-01 to a few minutes ago, read from the on-chain trade tape. Takes the market's condition_id (0x plus 64 hex digits, from polymarket_markets or polymarket_market_detail), NOT an outcome token id. Returns {trades, has_more, next_cursor}; while has_more is true pass next_cursor back as cursor for the next, older page. from_ms is inclusive and to_ms exclusive (epoch ms). A page is 100 rows by default and at most 10,000; a row is ~430 characters (a 66-character transaction hash and a 42-character wallet), so ask for what the context window holds. ONE ROW IS ONE ORDER'S FILL, NOT ONE MATCH: a match is several rows (the resting maker orders that were hit, plus one taker row for the aggressor, whose size is the sum of theirs), so never add size * price over both roles. A few percent of fills are merged away, so a count can sit slightly under the on-chain total. proxy_wallet is Polymarket's proxy wallet, not necessarily the person's own address. For the recorded order book (no wallets) use polymarket_tape; for one wallet's whole record use polymarket_wallet.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "condition_id": "<condition_id>"
    },
    "name": "polymarket_market_trades"
  }
}

Input Schema

Name	Required	Description
`limit`	No	Rows per page (default 100, max 10000, as the REST route).
`to_ms`	No	Trade time, epoch milliseconds, EXCLUSIVE; must be greater than from_ms. Omit for no upper bound.
`cursor`	No	The previous page's next_cursor, passed back unchanged.
`from_ms`	No	Trade time, epoch MILLISECONDS, inclusive. Omit for the first trade.
`condition_id`	Yes	The market's condition id: 0x followed by 64 hex digits.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 2, 2026

changedInput schema / properties / limit / description

Previous value: -"Rows per page (default 100, max 200)."New value: +"Rows per page (default 100, max 10000, as the REST route)."

AddedOct 31, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, yet the description still adds real behavioral payload: data extent (2026-01-01 to a few minutes ago), on-chain provenance, row width (~430 chars) for context budgeting, and the critical warning that one row is one order's fill rather than one match, so size*price must not be summed across both roles. It also flags that a few percent of fills are merged away and that proxy_wallet is Polymarket's proxy, not the person's own address — genuine caveats absent from the structured fields.

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?

Front-loaded with the identity of the tool and the primary routing distinction, then the format and pagination contract, then the gotchas. It is dense and one long block, but nearly every clause carries information; the row-as-fill warning is worth the space it takes.

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?

No output schema exists, so the description supplies the return shape ({trades, has_more, next_cursor}), explains how to consume it, and covers row semantics and caveats. For a read-only paged tool, nothing an agent needs to call it correctly is missing.

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 coverage is 100%, so the baseline is 3, but the description still adds meaning the schema does not: the exact condition_id format and its prohibition on outcome token ids, the inclusive/exclusive boundary pair reinforced in prose, the cursor round-trip rule tied to has_more, and context-window sizing advice for limit. Only minor syntax details are left to the 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?

States a specific verb and resource — one market's trades, joined to the wallets behind each, newest first, paged — and immediately distinguishes itself from the recorded tape and the per-wallet view. An agent can tell it apart from polymarket_tape and polymarket_wallet without opening either schema.

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

Usage Guidelines5/5

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

Names both alternatives with the exact condition that selects each: polymarket_tape for the recorded order book without wallets, polymarket_wallet for one wallet's whole record. It also tells the agent where condition_id comes from (polymarket_markets or polymarket_market_detail) and explicitly forbids passing an outcome token id.

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

All Vike Data API tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.