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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds the set of values returned, which is useful since there is no output schema, but it says nothing about response size, pagination of the ten-game log, or behavior for an unknown player_id. With annotations carrying safety, a 3 fits.

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?

Three sentences, front-loaded with the trigger condition and examples, then the payload, then the exclusions. Every clause carries information an agent needs for selection and there is no filler.

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 read-only, three-parameter lookup with a full schema and no output schema, the description covers purpose, return contents, and routing exclusions. It stops short of describing caveats such as a missing/limited player or malformed player_id, which leaves a small gap.

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%, and all three parameters already have descriptions including the season default and the enum for league. The description adds no parameter-level meaning beyond the schema, so the baseline of 3 applies.

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 verb+resource ('one player's season or recent form') and enumerates the returned content: season averages, efficiency metrics per league (TS%, eFG%, USG%, BPM; yards, touchdowns, EPA), Keel Impact with rank, injury status, and last ten games. It also names the sibling tools it is not, so an agent can route without opening the schemas.

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?

It states explicitly when to invoke ('when the user asks about one player's season or recent form') with two realistic example queries, and gives exclusions naming the exact alternatives: player_splits_and_on_off for on/off or teammate splits and props_research for prop lines. Nothing is left to inference.

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