Retrieve complete player statistics for a given sport by nickname or unique ID, combining period stats, foundation data, and recent map results in one aggregate.
Full Redis aggregate: period stats + foundation + recent maps. player = nickname or kr_pl_* id.
| Name | Required | Description | Default |
|---|---|---|---|
| sport | Yes | ||
| player | Yes | ||
| recent_limit | No |
Changes observed during successful MCP inspections.
v0.6.5Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It does disclose that the tool is a Redis-backed aggregate covering the player's full stats, which implies a cached, read-only operation. However, it does not address error behavior, missing data handling, or what 'foundation' means, leaving some ambiguity.
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 is extremely compact: two sentences, no fluff, and the core meaning is front-loaded. The parameter clarification is immediately useful and does not waste space.
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?
With no output schema and no annotations, the description is not complete enough. It states the general components ('period stats + foundation + recent maps') but leaves out response format, valid sport values, and guidance for choosing between this and get_player_stats. An agent would still have unanswered questions before invoking it correctly.
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?
Schema description coverage is 0%, so the description must compensate for all three parameters. It helps only with 'player' by explaining the accepted identifier forms ('nickname or kr_pl_* id'). The required 'sport' parameter and the optional 'recent_limit' parameter receive no explanatory coverage.
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 clearly identifies the resource ('Redis aggregate') and the content ('period stats + foundation + recent maps'), and it clarifies the identifier format. However, it does not explicitly distinguish this tool from the similarly named get_player_stats sibling, so it loses the top score.
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?
No guidance is given on when to prefer get_player_stats_full over similar sibling tools like get_player_stats or get_player_snapshot. The description only states what the tool returns, not when it should be used or when an alternative would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.