rust.wiki

Rust player leaderboard: most kills, best K/D, hours and more

get_player_leaderboard

Read-onlyIdempotent

Rust player leaderboard: most kills, best K/D, hours and more. The leaderboard on https://rust.wiki/players: Rust players ranked by their official Steam stats. Boards: kills, kd (min 1,000 kills), headshots (headshots on anything), hours (public playtime only), accuracy (bullets that hit a player / fired, min 20,000 fired), scientists, animals, gathered (wood + stone + metal ore + sulfur ore), building (blocks placed), rockets, fish, deaths. Each result has rank, steamid, name, avatar, country, value / value_text, kills, deaths, kd, hours and updated (the date its stats were last read from Steam). Players are added when looked up on Player Stats or when their inventory is checked on rust.wiki, refreshed about weekly; only public game details are ranked and accounts with VAC or game bans never are. total is how many players qualify for the board.

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

Input Schema

Name	Required	Description	Default
`page`	No
`board`	No	Which leaderboard.	kills
`country`	No	Two-letter country code (Steam profile country).
`per_page`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 8, 2026
- changedInput schema / properties / page / maximum
```
Previous value: -40New value: +100
```
- changedInput schema / properties / per_page / default
```
Previous value: -50New value: +20
```
AddedNov 7, 2026

TDQS

A4/5.0

Behavior5/5

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

Goes well past the readOnly/idempotent annotations by disclosing data provenance and freshness (players added on lookup, refreshed roughly weekly), coverage limits (public game details only, no VAC/game-banned accounts), and the meaning of the `total` count. These are exactly the caveats that change how an agent should present results.

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-loads the purpose, then enumerates boards, then describes result fields — a sensible order for scanning. Dense but mostly earns its length; the opening sentence largely restates the title.

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?

No output schema exists, and the description compensates by listing the returned fields (`rank`, `steamid`, `name`, `avatar`, `country`, `value`/`value_text`, `kills`, `deaths`, `kd`, `hours`, `updated`) and the `total` count. Only pagination behavior and any result-size limits are unaddressed.

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?

With only 50% schema coverage, the description does real work: it defines each of the 12 board values, including how composite boards are computed ('gathered' = wood + stone + metal ore + sulfur ore, 'building' = blocks placed). `page`/`per_page` and `country` semantics are left to the schema, which documents country but not the pagination bounds behavior.

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?

States a specific verb and resource: a player leaderboard ranked by official Steam stats, with the concrete board names. It never explicitly contrasts with sibling tools such as get_player_stats or get_inventory_leaderboard, so an agent must infer the boundary from the word 'leaderboard' alone.

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 board list plus qualification thresholds ('kd' min 1,000 kills, 'accuracy' min 20,000 fired) implicitly tell the agent which board to pick for a given question. There is no explicit when-to-use / when-not guidance and no pointer to alternatives like get_player_stats for a single player.

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

All rust.wiki 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.

Resources

Need Help?