Adjust the tempo at a selected measure in a live score, specifying BPM and an optional label for style or expression.
Set the tempo at a measure in the live score.
Args: measure: Measure number (1-indexed). bpm: Beats per minute. text: Optional display text (e.g. "Swing", "Allegro").
| Name | Required | Description | Default |
|---|---|---|---|
| bpm | Yes | ||
| text | No | ||
| measure | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections.
Output schema / $defsAdded value: +{
+ "CommandResult": {
+ "additionalProperties": true,
+ "type": "object"
+ }
+}Output schema / properties / result / $refAdded value: +"#/$defs/CommandResult"Output schema / properties / result / titleRemoved value: -"Result"Output schema / properties / result / typeRemoved value: -"string"v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, but it only states the action and parameters. It does not disclose that setting a tempo likely overwrites an existing one, whether a connection to a scoring app is required, or what happens for invalid measure numbers. This is a meaningful transparency gap for a mutation tool.
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 compact and front-loaded: one clear purpose sentence followed by three terse, useful parameter lines. There is no redundant or filler content.
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?
The purpose and all parameter semantics are covered, and an output schema exists so return-value documentation is unnecessary. However, given the absence of annotations, the missing usage prerequisites and behavioral caveats leave the definition slightly incomplete for an agent deciding whether and how to call it.
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 input schema has 0% description coverage, but the description's Args section fully compensates: it defines measure as 1-indexed, explains bpm as beats per minute, and documents text as optional with examples. All three parameters receive meaningful semantic clarification beyond the raw schema.
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 ('Set') and a precise resource ('tempo at a measure in the live score'). This clearly distinguishes it from sibling tools like set_live_time_signature and set_live_key_signature, and the purpose is immediately understandable without further context.
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 provides no guidance on when to use this tool versus alternatives, nor any prerequisites such as needing an active connection through connect_to_musescore or connect_to_dorico. The tool name implies the usage context, but the description itself does not help an agent select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.