Skip to main content
Glama
Sign In
MuseScore MCP Server

MuseScore MCP Server

by ghchen99
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Find Repeated Measures

find_repeated_measures

Detects repeated measures and duplicated passages in a MuseScore score, returning per-staff measure-repeat candidates and whole-score repeat barline candidates, with the tool calls needed to apply them.

Instructions

Find repeated material in the score. Returns (1) per-staff bars that repeat the previous 1, 2 or 4 bars, candidates for measure-repeat signs (these declutter the page but keep the length), and (2) whole-score passages played again right away, candidates for repeat barlines and 1st/2nd endings (these shorten the score once the duplicate measures are deleted). Each passage lists the tool calls that apply it. Reads the score in small chunks, so it works on large scores. Measure numbers refer to the score as it is now: apply passages from the last one backwards.

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": "find_repeated_measures"
  }
}

Input Schema

NameRequiredDescriptionDefault
stavesNoStaff indices to analyse (0-based). Defaults to all staves.
highlightNoAlso color the results in the score: duplicate measures of each passage in a passage color, per-staff measure repeats in orange. Undo or clear_color removes it.
end_measureNoLast measure to analyse (1-based, inclusive). Defaults to the end of the score.
start_measureNoFirst measure to analyse (1-based)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.5/5.0
Behavior5/5

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

With no annotations supplied, the description carries the full burden and does it well: it discloses that the tool is chunked/streaming ("reads the score in small chunks, so it works on large scores"), that highlight=true is a visible mutation with defined colors, and that undo or clear_color reverts it. It also flags the ordering hazard that measure numbers shift as edits are applied, which is the main way an agent could misuse the results.

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

Conciseness4/5

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

Front-loaded with the core purpose, then the numbered result categories, then the operational caveat. Dense but every sentence contributes; the parenthetical asides about decluttering and shortening are slightly verbose but justify why each result type exists.

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 4-parameter, no-annotation, no-output-schema tool, the description covers purpose, return categories, side effects, reversibility, and ordering. The main gap is that it never sketches the shape of a returned passage (fields, how staff/measure ranges are expressed), which an agent must discover by calling it.

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 parameter baseline is 3; the description adds real meaning beyond it by explaining what highlight colors mean (passage color for duplicates, orange for per-staff repeats) and how to remove them. It also reinforces the measure-numbering semantics of start_measure/end_measure. No syntax details beyond that, but none are needed for integers.

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

Purpose5/5

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

States a specific verb and resource ("Find repeated material in the score") and splits the output into two clearly named categories — per-staff bar repeats (measure-repeat signs) versus whole-score immediate repeats (repeat barlines, 1st/2nd endings). That distinction alone lets an agent tell it apart from sibling appliers like apply_measure_repeats or collapse_to_repeat.

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?

Makes clear this is a detection step: results are "candidates" and "each passage lists the tool calls that apply it," which routes the agent to the follow-up tools. It also gives a concrete operational rule — "apply passages from the last one backwards" — because measure numbers refer to the current score. It stops short of an explicit when-not-to-use or a named alternative for detecting grooves or sections.

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

Deploy Server

Other Tools