Vike Data API

Polymarket Orderbook

polymarket_orderbook

Read-onlyIdempotent

Order-book snapshot for ONE Polymarket outcome token: the nearest full-book snapshot at or before ts (the latest when omitted), flattened to price levels. token_id is the ERC-1155 OUTCOME token id (decimal string from clob_token_ids in polymarket_market_detail or outcomes[].token_id in polymarket_markets); a condition_id (0x...) will NOT work. Returns rows {as_of_ts (epoch ms, the snapshot actually used), side ('ask' | 'bid'), level (1 = best), price (probability in [0, 1]), size (shares)}, all asks before all bids. A book can be one-sided, so fewer than 2 x depth rows is normal. A level can repeat in one answer (the recorder writes several identical snapshot rows for one venue timestamp): keep one row per (side, level) and read a side's depth as its highest level, never as a row count. as_of_ts can be old for a quiet or finished market, so check it before quoting a spread. [] means no snapshot at or before ts, or a token that was never recorded.

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": {
      "token_id": "<token_id>"
    },
    "name": "polymarket_orderbook"
  }
}

Input Schema

Name	Required	Description
`ts`	No	As-of epoch MILLISECONDS; the nearest snapshot at or before it is used. Omit for the latest.
`depth`	No	Levels per side, 1 to 25 (default 25).
`token_id`	Yes	Required. The outcome token id (decimal string).

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 25, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only cover the read-only/idempotent profile; the description adds substantial behavioral detail beyond that: row ordering (all asks before bids), the possibility of a one-sided book, duplicate snapshot rows requiring dedupe by (side, level), and stale as_of_ts for quiet markets. Empty-result semantics ('[] means no snapshot') are also disclosed.

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 core operation and return shape, then caveats in descending priority. Every sentence carries information, though the single dense paragraph is hard to scan for the token-id sourcing and dedupe rules.

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, yet the description fully specifies the returned row shape and field meanings (as_of_ts epoch ms, side, level, price as probability, size in shares), plus edge-case interpretation. Nothing an agent needs in order to call or interpret this 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 baseline is 3; the description earns above that by clarifying that token_id is the ERC-1155 OUTCOME token id as a decimal string, naming the source fields in two sibling tools, and warning that a 0x... condition_id will fail. It does not restate depth or ts semantics beyond 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 ('Order-book snapshot for ONE Polymarket outcome token') with explicit scope (single token, single snapshot at/ before ts). An agent can distinguish it from polymarket_ohlcv (time series) and polymarket_tape (trades) without opening a schema.

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?

Gives strong operational context: token_id must come from clob_token_ids/outcomes[].token_id, a condition_id will NOT work, and as_of_ts should be checked before quoting a spread. It stops short of naming an alternative sibling to use for time-series or trade-level data, so selection between neighbors is only implied.

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.