player_burn_event_full_leaderboard

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

With no annotations, the description carries the full disclosure burden and meets it in detail: bounded response, ignored limit/offset, no pagination, string wire types, one logical GET, no auto-fetching, 100-row/256 KiB caps, truncation reporting, and refusal of oversized records without partial fields. This is exceptionally transparent.

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

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

The description front-loads the purpose and then lists one significant warning per sentence, so it is structured and easy to scan. It is verbose for a zero-parameter tool and includes the historical '3344 compact rank/player/points rows' detail that is not needed for invocation, but nearly every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite no output schema, the description covers the most important invocation facts: what the request reads, how many rows are returned, how truncation is signaled, and how oversized records fail. It does not specify exact output field names or explicitly route the agent to the sibling that serves the true full ranking, but it is otherwise sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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

The input schema is empty, so the 0-param baseline applies, but the description still adds useful input-related context: it states that limit/offset do not advance or shorten the response, that no paging controls are exposed, and that declared filters are forwarded as supplied though not guaranteed effective. It does not enumerate actual filter names, which is the main gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific action and resource: 'Read the upstream full burn-event ranking route.' It also clarifies the server 'returns only a bounded leading portion, not the full ranking,' which tells an agent what the tool really does. The label 'full' makes this slightly confusing, 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives behavioral caveats—'no paging controls are exposed' and 'forwards filters as supplied'—but never states when to prefer this endpoint over player_burn_event_leaderboard or any other leaderboard sibling. There is no explicit when-to-use, exclusion, or alternative, so an agent must infer selection from the route name alone.

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