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

Annotations already establish readOnlyHint=true, destructiveHint=false and a closed world, so the safety profile needs no restating and the description correctly does not restate it. It adds one real behavioral caveat: beat data is only present on songs 'where a steady beat is clear enough to trust,' warning the agent about missing fields. Beyond that it discloses nothing about response size, cost, or failure modes for an unknown piece path.

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 payload is front-loaded in the first clause ('Everything about one piece's rhythm in one call'), and the long enumeration of returned signals is dense but each item informs the agent. The second sentence awkwardly merges a provenance hint (attend) with an input-format example, and the parenthetical about beats interrupts the list. Minor restructuring would earn a 5, but there is little outright waste.

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, the description is not obligated to explain return values, and it has full schema coverage on inputs and a clear read-only annotation set, so the essentials are covered. The remaining gap is sibling positioning against read_song, which matters for an agent choosing among nine tools but is a usage issue rather than a completeness failure.

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 coverage is 100%, so all five parameters, including the four optional utm_* fields, are already documented in the schema. The description's note that `piece` may be a song slug or a spoken path like 'chants/chant-for-arrival' largely repeats the `piece` schema text about rhythm.url. Baseline 3 is appropriate: the schema does the work and the description adds no new syntax or format detail.

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 opening clause names a specific verb (read) and resource (one piece's rhythm) and enumerates what comes back: rests, tempo, beats, per-second loudness and spectral bands. It also scopes to 'song or voiced piece,' so the agent knows both input kinds are accepted. It stops short of distinguishing the tool from read_song, which is the nearest sibling and the main ambiguity.

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 implies a workflow — attend produces a summary and a rhythm.url, and you pass that value here — which is genuinely useful routing context. However, it never says when to prefer read_rhythm over read_song, or whether rhythm data is a subset or a superset of song data. The agent must infer the choice from the sibling names alone.

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