Deep post-match breakdown and objective analytics

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

Annotations already establish the safe read-only, idempotent profile, so the description's marginal contribution is the auto-default to the most recent match when gameId is omitted and the shape of the return ('structured objective and player breakdowns'). That is genuinely useful context beyond the annotations, though it stops short of noting cost/latency or data-availability edge cases (e.g., what happens with an invalid gameId).

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?

Front-loaded with the payload of computed metrics, then routing, then behavior – a sensible order. The closing 'Returns structured objective and player breakdowns' slightly restates the opening enumeration, which keeps it from a perfect score, but the text is otherwise dense and waste-free.

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?

For a single-optional-param analytics tool with no output schema, the description covers what is computed, when to reach for it, the sibling alternatives, the default behavior, and the general return shape. 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.

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

Schema description coverage is 100% for the single gameId parameter, and the schema itself already documents the most-recent-match fallback, so the description's restatement adds nothing new. Baseline 3 is appropriate when the schema carries the parameter burden.

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?

States a specific verb ('Calculates advanced post-game metrics') with a concrete enumerated resource (damage share %, gold efficiency, KP %, vision score, objective counts). An agent can distinguish it from lol_analytics_match_history and lol_analytics_live_combat purely from the opening sentence.

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?

Explicitly gives the when-to-use case ('analyzing the decisive factors, individual carrying performance, or throws of a specific completed match') and names both alternatives with the condition that selects them (match_history for brief multi-match views, live_combat for in-progress matches). This is textbook routing guidance.

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