Polyrank

Polyrank Ranking Builder (custom composite ranking)

polyrank_rank_wallets

Read-onlyIdempotent

Rank every Polymarket wallet with your own composite — exactly what the Ranking Builder runs (POST /v1/rankings/custom). weights: metric id → weight (or {weight, window}); any of the 84 catalog metrics at any window it exists at (polyrank_get_metric_windows), plus copy-engine (sk_score_14d) and entry-timing ids at lifetime. filters: min_trades, min_resolved, min_inband_n_30d (the in-band positions behind inband_return_30d: a sort by engine:inband_return_30d applies 10 unless you set it, 1 = every measured wallet; the floor that ran is in applied_filters), min_volume_usdc, min_realized_pnl(_net_fees), min_win_rate_pct, max_roi_pct, active_within_days/hours, categories, exclude_bonders, skill_gates [{metric,min_pctile,window}], metric_filters [{metric,min,max,window}], copy_engine {sleeve}, timing {sub,bucket,window,min_n}, cluster_policy, copy_placeable, smart_money_tags_any_of, follower_count_max … (the server rejects anything it cannot apply, with the reason). A HISTORY BOARD (a Strategy Lab history ranking's latest seat) is filters {history_board: {board}} with board one of underdog-specialists | copier-consensus | predictors-early-underdog | sports-closing-line and NO weights: it is ranked by the seat's own order and served as that preset board; only active_within_days, active_within_hours and best_category may narrow it (window_days, score, min_positions, one_per_operator and other keys are not accepted there), plus limit, offset, sort_by, sort_dir, include_breakdown, include_verdict, extra_metrics, extra_engine_metrics, dedupe_clusters. as_of=YYYY-MM-DD ranks the board as it stood that day (lifetime snapshot metrics only — refused with the reason otherwise, never answered live). To reproduce a Builder goal, pass its request from polyrank_list_ranking_templates as request. Needs POLYRANK_API_KEY (a plan with the Builder).

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": "polyrank_rank_wallets"
  }
}

Input Schema

Name	Required	Description
`as_of`	No	Rank the board as it stood on this day (ISO date). Lifetime snapshot metrics only.
`limit`	No	Rows (default 100, max 500).
`offset`	No
`window`	No	Default window for every weight given as a bare number (default lifetime).
`explain`	No	How many wallets each filter dropped.
`filters`	No	Ranking filters (see description).
`request`	No	A complete POST /v1/rankings/custom body (e.g. a goal's `request`). When given, the other arguments override its fields.
`sort_by`	No	composite (default), metric:<id>, pctile:<id>, engine:<id>, timing:<id>, or a board column. engine:inband_return_30d is a mean over few positions for most wallets: it carries a min_inband_n_30d floor (default 10) and projects inband_n_30d beside it.
`weights`	No	metric id → weight, or → {weight, window}. Weights are auto-normalized.
`sort_dir`	No
`na_policy`	No
`include_raw`	No	Raw values beside the percentiles (dollars, hours).
`extra_metrics`	No	More metric columns to project.
`dedupe_clusters`	No	Keep one wallet per wallet-farm cluster.
`include_verdict`	No	The copy verdict the trader page shows.
`include_breakdown`	No	Per-metric percentile cells per row.
`extra_engine_metrics`	No	Copy-engine columns to project.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 7, 2026

changedInput schema / properties / sort_by / description

Previous value: -"composite (default), metric:<id>, pctile:<id>, engine:<id>, timing:<id>, or a board column."New value: +"composite (default), metric:<id>, pctile:<id>, engine:<id>, timing:<id>, or a board column. engine:inband_return_30d is a mean over few positions for most wallets: it carries a min_inband_n_30d floor (default 10) and projects inband_n_30d beside it."

First observedNov 7, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the readOnly/idempotent annotations it discloses the auth requirement ('Needs POLYRANK_API_KEY (a plan with the Builder)'), the failure policy ('the server rejects anything it cannot apply, with the reason'), and a hidden default that changes results: an engine:inband_return_30d sort silently applies min_inband_n_30d=10 and exposes the effective floor in applied_filters. It also warns that as_of is refused rather than answered live — all behavior the annotations cannot express.

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

Conciseness3/5

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

Most sentences carry load-bearing information, but the description is a single dense run-on crammed with nested parentheticals and trailing ellipses, so the history-board rules and the filter defaults are hard to extract on a first read. Front-loading is good (purpose first, then weights, then filters, then the history-board variant), but readability suffers for a tool an agent must call precisely.

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 17-parameter tool with nested objects and no output schema, the description covers the opaque parts (filters, weights, history_board, as_of, request-override precedence) and even describes returned fields (applied_filters, the projected inband_n_30d column, the preset board serving). The remaining parameters are documented in the schema at 82% coverage, so 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.

Parameters5/5

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

Schema coverage is 82%, so the baseline is 3, but the description must carry the opaque `filters` object (additionalProperties: {} in the schema) and does so exhaustively: min_trades, min_resolved, min_win_rate_pct, skill_gates [{metric,min_pctile,window}], metric_filters, copy_engine.sleeve, timing, cluster_policy and more, plus the history_board sub-object and exactly which of its keys are rejected. It also explains `weights` semantics beyond the schema (any of 84 catalog metrics at any window it exists at, windows allowed per entry) and that weights auto-normalize.

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 opening sentence gives a specific verb and resource with explicit scope: 'Rank every Polymarket wallet with your own composite — exactly what the Ranking Builder runs (POST /v1/rankings/custom).' It also flags a second, materially different mode (HISTORY BOARD) ranked by a preset seat order, which is enough to distinguish it from polyrank_get_leaderboard and polyrank_get_custom_ranking 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?

It routes the agent in two concrete cases: 'To reproduce a Builder goal, pass its request from polyrank_list_ranking_templates as request', and it points to polyrank_get_metric_windows for discovering valid metric/window pairs. What it lacks is an explicit negative rule — when to use polyrank_get_custom_ranking or polyrank_get_leaderboard instead — so the alternative-tool decision is left to inference.

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

All Polyrank 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.