set_tempo

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

With no annotations provided, the description carries the full behavioral burden. It says only that it sets the project tempo and accepts a BPM value, without disclosing side effects, valid ranges, whether the change is undoable, or how it interacts with playback or existing audio. For a mutation tool, this is a significant gap.

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 very short and front-loaded: purpose first, then the parameter explanation. Every sentence earns its place. The 'Args:' block is slightly schema-redundant but provides unit clarification.

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 simple one-parameter setter with no annotations and no output schema, the description gives just enough to invoke the tool correctly. It does not explain return values or side effects, but those are minimal for a straightforward tempo setter. Adequate but not rich.

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 0%, so the schema gives only the parameter name 'bpm' and type number. The description adds meaning by clarifying that bpm is 'Tempo in beats per minute,' which is useful beyond the schema. However, it does not specify acceptable ranges, precision, or constraints, leaving some semantic 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?

The description states a specific verb and resource: 'Set the project tempo.' This clearly distinguishes it from the sibling get_tempo, which retrieves rather than sets the tempo. No ambiguity about what the tool does.

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?

There is no explicit guidance on when to use this tool versus alternatives, nor any prerequisites or conditions. The usage is implied by the verb 'set', but the description does not state when to prefer this over get_tempo or other tempo-related operations.

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