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

Annotations only declare readOnlyHint and openWorldHint=false; the description adds real semantic context beyond them — that the data is a bounded sample of a 12-month ranking, that release dates are not listening dates, and that no play counts or ranks exist. It doesn't state freshness/update cadence or what the response envelope looks like, which keeps it from a 5.

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?

Four short sentences, front-loaded with the core definition and followed by the exclusions an agent most needs. The staccato negation/qualifier clauses ('Release dates are release dates, not listening dates') are dense but each carries distinct information, so there's 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?

With an output schema present, return values needn't be described, and the description covers source, scope, exclusions, and data-quality caveats well. The only real gap is how 'limit' shaping behaves, which is the sole parameter an agent must actually decide on.

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 single 'limit' parameter has 0% schema description coverage, so the schema gives only a default of 12 and a 1–35 range with no meaning attached. The description says 'bounded selection' but never explains that limit controls how many albums are returned or what happens at the cap, so it only partially compensates for the coverage 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?

States a specific verb ('Get'), resource ('past-year music rotation'), and provenance ('Last.fm's past-12-month album ranking'), and immediately delimits it as a 'bounded selection' rather than a live feed. An agent can distinguish this from list_posts or discover_music without opening any schema.

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 enumerates when-not: not currently playing, not favorites, not personal recommendations, not a complete listening history. That negation list effectively routes the agent toward discover_music for recommendations, but the description never names a sibling tool as the alternative, so it stops just short of a 5.

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