mcp-score

Overview Schema Source Related Servers Discussions Admin

read_passage

Read notes, rests, and other elements within a specified measure range in the live score. Provide start and end measures, and optionally a staff, to retrieve the content at the cursor for analysis or editing.

Instructions

Read the content of a range of measures in the live score.

Returns what is at the cursor in each measure: notes, rests and other elements. MuseScore gives full note content; Dorico only reports its application status (see the warning in the result).

Args: start_measure: First measure to read (1-indexed). end_measure: Last measure to read (inclusive, 1-indexed). staff: Staff to read (0-indexed). Omit to read the current staff.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`staff`	No
`end_measure`	Yes
`start_measure`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedSep 26, 2026
- addedOutput schema / $defs
```
Added value: +{
+  "CommandResult": {
+    "additionalProperties": true,
+    "type": "object"
+  }
+}
```
- addedOutput schema / properties / result / $ref
```
Added value: +"#/$defs/CommandResult"
```
- removedOutput schema / properties / result / title
```
Removed value: -"Result"
```
- removedOutput schema / properties / result / type
```
Removed value: -"string"
```
First observedv0.1.0May 29, 2026

TDQS

A3.7/5.0

Behavior3/5

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

There are no annotations, so the description carries the behavioral burden. It does add valuable behavior: return content is cursor-based, MuseScore returns full note content while Dorico only reports application status, and a warning is referenced. However, it doesn't disclose potential side effects, limits, or why the cursor matters.

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 compact and front-loaded, with the core purpose in the first sentence, followed by return semantics and the platform caveat. The Args section is formatted for quick parsing and every sentence adds information.

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 read-only range tool with an output schema, the description covers the input semantics and return behavior sufficiently. It is slightly incomplete in not addressing when to choose it over get_measure_content and in not detailing the referenced warning, but these are secondary for correct invocation.

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

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description fully compensates: start_measure is 1-indexed, end_measure is inclusive and 1-indexed, and staff is 0-indexed with an explanation that omitting it reads the current staff. This is exactly the semantic information the schema lacks.

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 opens with a specific verb and resource ('Read the content of a range of measures in the live score') and clarifies what is returned (notes, rests, other elements). It doesn't explicitly distinguish this from sibling get_measure_content, but the range-scoped scope makes the core purpose unambiguous.

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

Usage Guidelines2/5

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

No guidance is given about when to use this tool instead of get_measure_content or the other reading/inspection siblings, and there are no exclusions or prerequisites. The 'Read' verb only weakly implies its usage context.

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