rust.wiki

Site-wide totals and data freshness

get_server_stats

Read-onlyIdempotent

Site-wide totals and data freshness. The headline numbers from the servers.rustprofit.com homepage: online_servers, total_players and queued_players summed across every online server, tracked_servers (every row ever discovered, offline included), steam_global_players (Rust's concurrent player count from Steam, null if Steam did not answer), next_force_wipe_at (the first Thursday of the month at 2 PM US Eastern: 18:00 UTC during US daylight saving time, 19:00 UTC otherwise), the poller's configuration (poll_interval_seconds between cycles, offline_after_seconds before an unanswering server is marked offline, snapshot_retention_days of per-server history kept) and workers - the live heartbeat status of the discovery, polling and map-generation jobs, so you can tell how fresh the data is. Includes next_force_wipe_at (Rust's monthly forced wipe).

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_server_stats"
  }
}

Input Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 25, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already cover read-only, idempotent, non-destructive, so the description isn't needed for the safety profile. It does add real behavioral value the annotations cannot: null semantics for steam_global_players when Steam doesn't answer, the exact wipe schedule with DST handling, poller interval/offline threshold/retention semantics, and worker heartbeat status for judging data staleness.

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?

Front-loaded with the headline purpose, which is good, but the run-on field inventory is dense and the closing sentence 'Includes next_force_wipe_at (Rust's monthly forced wipe)' simply repeats a field already fully explained earlier. Trimming that repetition and splitting the field list would improve scannability.

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?

With no output schema, the description carries the full burden of describing return values and does so field by field, including nullability and time-zone edge cases. The one real gap is that it never positions the tool against the overlapping sibling get_data_freshness.

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?

The tool takes zero parameters, so there is nothing to disambiguate; the description's field-level explanation is a bonus rather than a compensation for schema gaps. Baseline 4 applies for a parameterless tool.

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/resource pairing ('site-wide totals and data freshness' from the homepage) and enumerates the exact fields returned, so the agent knows what it gets. It does not, however, distinguish itself from the very close sibling get_data_freshness or say how it differs from get_top_servers/get_server.

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?

Usage is only implied — 'the headline numbers from the homepage' and 'so you can tell how fresh the data is' suggest an overview/freshness use case. There is no explicit statement of when to call this instead of get_data_freshness, get_top_servers, or get_server, despite those being adjacent siblings.

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?