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

The description goes beyond the read-only annotations by explaining that it accepts BPM or a note duration and returns whole-to-sixty-fourth values, dotted and triplet variants, pre-delay suggestions, and approximate Italian marking ranges. It also clarifies domain constraints such as BPM 20 to 400, up to 100000 bars, and that hertz here means rhythmic repetition rather than pitch.

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 appropriately front-loaded with 'Use this when' and remains compact enough for the number of use cases covered. The keyword-list opening is somewhat dense, but every sentence contributes scope, constraints, or a clarifying boundary.

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?

Given the seven optional parameters, full schema description coverage, read-only annotations, and an output schema, the description supplies enough context to select and invoke the tool correctly. It covers supported inputs, major constraints, output categories, and non-audio boundaries without needing to restate the full schema.

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 the baseline is 3, but the description adds useful semantics by clarifying the BPM-or-note-duration input mode and the meaning of hertz in this context. Most BPM and bar-limit details are repeated from the schema, which keeps it from a 5.

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 states what the tool calculates: BPM-to-ms conversions, note-cycle hertz, milliseconds-to-BPM, bar length, and song length. It is specific about the resource and outputs, but it does not explicitly distinguish this tool from sibling tools like show_metronome or plan_tempo_practice.

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 gives clear triggering scenarios such as 'bpm to ms', 'delay time calculator', and 'bar length or song length', plus a useful exclusion that it does not record audio or detect pitch. It stops short of naming alternatives or explicitly saying when a sibling tool should be used instead.

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