Vike Data API

Polymarket Leaderboard

polymarket_leaderboard

Read-onlyIdempotent

Leaderboard of Polymarket wallets ranked by realized P&L, hit rate, volume or trade count, for all time or over a window, optionally within one market category. The same board vike.io/polymarket shows. Returns rows {rank, proxy_wallet, pseudonym, display_name, realized_pnl_usd (lifetime, USD, resolved markets only), realized_pnl_window_usd (USD over window, by resolution time), resolved_markets, hit_rate, hit_rate_ci, volume_all_usd, volume_window_usd (USD), trades_all, trades_window, avg_trade_usd, markets, first_seen, last_seen (UTC), tags}. hit_rate is a FRACTION from 0 to 1 (0.62 = 62%), volume-weighted (the share of the wallet's resolved dollar volume that sat in markets it won), not a count of wins; it is null, never 0, when the wallet has no resolved volume. hit_rate_ci is the +/- half-width of the 95% Wilson interval, also a fraction: read hit_rate +/- hit_rate_ci and distrust a hit_rate with a wide one; a near-100% rate on a sliver of P&L is an arbitrage pattern, not skill. min_resolved defaults to 20 so a hit rate rests on a real sample; 0 lists thinner wallets. tags are whale (lifetime volume $100k or more), bot (average trade under $20 over 100+ trades), hot / cold (lifetime P&L of +/-$1,000 on 5+ resolved markets). The top of a category is often bots with tens of thousands of resolved markets: check tags and avg_trade_usd, or pass min_avg_usd=20 to drop every bot-tagged wallet. first_seen is the wallet's first trade in the recorded tape, which starts on 2026-01-01, so it does not show that a wallet is new. The 24h / 7d / 30d windows are rebuilt hourly (hour-granular) and a market's resolution time can be corrected later, so a windowed figure can be revised; window=all is not affected. Page with limit and offset; ties break on the wallet address. Addresses are public on-chain data; this tool names no one.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "polymarket_leaderboard"
  }
}

Input Schema

Name	Required	Description	Default
`sort`	No	Default: realized_pnl_window when `window` is 24h, 7d or 30d, realized_pnl when it is all. realized_pnl: lifetime USD, largest first, whatever the window. realized_pnl_asc: biggest losers first. realized_pnl_window / realized_pnl_window_asc: P&L inside `window`. hit_rate: highest first, nulls last; the top is often wallets that buy near-certain outcomes just under $1 (a 100% rate on a sliver of P&L), so set realized_pnl_usd against volume_all_usd before reading it as skill. resolved: most resolved markets. volume_24h / trades_24h: USD volume / trade count inside `window` (the names are historical; they follow `window`). volume_all, trades_all, markets: lifetime. last_seen: most recently active first.
`limit`	No	Rows per page (default 20, max 50).
`offset`	No	Rows to skip, 0 to 1000 (default 0). `rank` continues across pages; the board is rebuilt hourly, so a page fetched after a rebuild can repeat or skip a wallet.
`window`	No	The period behind trades_window, volume_window_usd and realized_pnl_window_usd (P&L of markets RESOLVED inside it), and what the *_window and volume_24h / trades_24h sorts rank on. Default all (lifetime). For 'top traders this week / month' pass 7d / 30d and leave sort out: the board then ranks on realized_pnl_window_usd.	all
`category`	No	Market category (default all). Every figure is recomputed on that category's markets only.	all
`min_avg_usd`	No	Minimum average trade size in USD (default 0). 20 drops every wallet tagged bot.
`min_resolved`	No	Minimum resolved markets (a count). Default 20; 0 includes wallets too thin for a hit rate to mean anything.
`min_volume_usd`	No	Minimum lifetime volume in USD, buys plus sells (default 0).

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedNov 1, 2026

removedInput schema / properties / sort / default
```
Removed value: -"realized_pnl"
```

changedInput schema / properties / sort / description

Previous value: -"realized_pnl (default): lifetime USD, largest first. realized_pnl_asc: biggest losers first. realized_pnl_window / realized_pnl_window_asc: P&L inside `window`. hit_rate: highest first, nulls last; the top is often wallets that buy near-certain outcomes just under $1 (a 100% rate on a sliver of P&L), so set realized_pnl_usd against volume_all_usd before reading it as skill. resolved: most resolved markets. volume_24h / trades_24h: USD volume / trade count inside `window` (the names are historical; they follow `window`). volume_all, trades_all, markets: lifetime. last_seen: most recently active first."New value: +"Default: realized_pnl_window when `window` is 24h, 7d or 30d, realized_pnl when it is all. realized_pnl: lifetime USD, largest first, whatever the window. realized_pnl_asc: biggest losers first. realized_pnl_window / realized_pnl_window_asc: P&L inside `window`. hit_rate: highest first, nulls last; the top is often wallets that buy near-certain outcomes just under $1 (a 100% rate on a sliver of P&L), so set realized_pnl_usd against volume_all_usd before reading it as skill. resolved: most resolved markets. volume_24h / trades_24h: USD volume / trade count inside `window` (the names are historical; they follow `window`). volume_all, trades_all, markets: lifetime. last_seen: most recently active first."

changedInput schema / properties / window / description

Previous value: -"The period behind trades_window, volume_window_usd and realized_pnl_window_usd (P&L of markets RESOLVED inside it), and what the *_window and volume_24h / trades_24h sorts rank on. Default all (lifetime)."New value: +"The period behind trades_window, volume_window_usd and realized_pnl_window_usd (P&L of markets RESOLVED inside it), and what the *_window and volume_24h / trades_24h sorts rank on. Default all (lifetime). For 'top traders this week / month' pass 7d / 30d and leave sort out: the board then ranks on realized_pnl_window_usd."

First observedOct 25, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations already declare read-only, non-destructive, idempotent behavior, but the description adds substantial behavioral context: hourly window rebuilds, resolution-time corrections that can revise windowed figures, pagination inconsistency on rebuild (repeat or skip wallets), and the tape start date of 2026-01-01 affecting first_seen. It also clarifies that addresses are public on-chain data and the tool names no one.

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 front-loaded with purpose and logically ordered (purpose, return fields, interpretation, caveats, pagination, data ethics). It is dense and long, but every sentence adds value for a complex 8-parameter tool; minor room for better visual structure (e.g. bullets) keeps it from a 5.

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?

With no output schema, the description fully compensates by enumerating the return fields and their meanings (rank, realized_pnl_usd, hit_rate, hit_rate_ci, tags, first_seen/last_seen, etc.). It also covers data freshness, revision risks, and pagination caveats, leaving no critical gap for correct invocation and interpretation.

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?

Schema coverage is 100%, so a baseline of 3 would suffice, but the description adds deep semantic meaning beyond the schema: hit_rate is a volume-weighted fraction (not a win count), null never 0, hit_rate_ci is a 95% Wilson half-width, min_resolved defaults to 20 for statistical validity, and tags (whale/bot/hot/cold) are defined with thresholds. It also explains how sort defaults interact with window and why certain sorts are misleading without checking volume or tags.

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 states a specific verb+resource: a leaderboard of Polymarket wallets ranked by realized P&L, hit rate, volume or trade count, with window and category scoping. It does not explicitly differentiate itself from siblings like polymarket_smart_money or hl_leaderboard, so it stops short of a 5.

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?

It gives clear contextual guidance for parameters (e.g. 'For top traders this week / month pass 7d / 30d and leave sort out', 'pass min_avg_usd=20 to drop every bot-tagged wallet'). However, it never names an alternative tool or explains when NOT to use this leaderboard, so it lacks explicit routing to siblings.

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.