Skip to main content
Glama
MuseScore MCP Server

MuseScore MCP Server

by ghchen99

Number Bars As Played

number_bars_as_played

Numbers bars to count repeated passages as actually played, so measure numbers jump after repeats. Run it again after changing repeats, exclude pickup bars, or reset to plain 1..N numbering.

Instructions

Make the displayed bar numbers count repeated bars, as played: after a passage between repeat barlines played N times, the next bar's number jumps by (N - 1) x the passage length. Recomputes all bars (MuseScore's 'Add to measure number'), so it can be run again after changing repeats. exclude_from_count leaves bars out of the count, e.g. [1] for a silent pickup or intro bar. reset=True removes all offsets and exclusions instead (plain 1..N numbering). Voltas are not taken into account. Needs MuseScore 4.6+. Tools keep addressing bars by position.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "number_bars_as_played"
  }
}

Input Schema

NameRequiredDescriptionDefault
resetNoUndo the numbering: plain 1..N, no offsets or excluded bars
exclude_from_countNoBar positions (1-based) to exclude from the count, e.g. [1]

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations supplied, the description carries the behavioral burden well: it discloses that all bars are recomputed, that the operation can be rerun, that reset removes offsets and exclusions, that voltas are ignored, and that MuseScore 4.6+ is required. It does not describe return values or error behavior, but it covers the important side effects and limitations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but front-loaded: it first states the core behavior, then the recomputation model, then parameter-specific caveats, limitations, and version requirements. Every sentence adds relevant information for correct invocation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter tool with no annotations or output schema, the description provides sufficient context about behavior, side effects, reversibility via reset, limitations, and version compatibility. It could say more about return values or errors, but the key operational details are present.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

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 meaning beyond the schema by explaining the purpose of excluding bars, such as a silent pickup or intro bar, and by clarifying the plain 1..N result when reset=True is used.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: making displayed bar numbers count repeated bars as played. It clearly explains the resulting numbering behavior and distinguishes the operation from ordinary measure numbering by describing the repeat-aware offset calculation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives clear context for when the tool is useful, including rerunning after changing repeats and using reset=True to remove offsets and exclusions. It does not explicitly compare against alternatives such as set_measure_number, but the intended use case is clear.

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