ScoreStarling

Review score

review_score

Read-only

Check a saved revision. acceptance is the verdict: each rule passes, fails with its bars and the operations that fix it, is unsure (ask the user) or unchecked; work from its failures until it passes. Its other evidence, like listening to bars or watching the video (check), is leads, not proof.

Input Schema

Name	Required	Description	Default
`crop`	No	watch: [left, top, right, bottom] as fractions of the frame from 0 to 1, such as [0, 0.5, 1, 1] for the lower half.
`part`	No	listen: one part's id or name: written-not-heard notes for it only; heard_near names the other parts that write what was heard.
`text`	No	The bars as text, each staff's attacks as beat and pitch, for reading phrases, figures and stray notes; without measures the whole score up to a size limit, naming the next bars to read.
`check`	No	acceptance (default): the verdict and its evidence, with a page picture or the bars as text; say which rule cannot pass and why. structure: the structural issues (bar lengths, voices and chords, playback bindings), a page at a time with their note IDs; not a measure of transcription accuracy. listen: a second engine re-hears up to 16 bars (measures) of a recording-based score against its own recording: notes heard but not written, written but not heard, and overtones of written ones; not for written music or drums; free, about a second. watch: numbered frames of a video-based score's own video, each with the notes struck just before it (frames land just after attacks): which hand plays a note, hand position, strumming, who plays a line; never download the video yourself.	acceptance
`image`	No	A page picture, for engraving: clefs, ledger lines, spacing.
`limit`	No	structure: issues per page, 1 to 100.
`trial`	No	Also write the score in 3/4 and 4/4 from the recording to judge the meter (seconds).
`frames`	No	watch: 1 to 16.
`offset`	No	structure: next_offset of the previous page.
`columns`	No	watch: 1 to 4; fewer columns show each frame larger.
`seconds`	No	watch: times in the recording instead of bars.
`measures`	No	Bars as numbered in the score: one bar or a range such as 9-12, at most 16.
`revision`	No	A saved revision; the current one by default.
`score_id`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed9 schema fields changedOct 25, 2026

addedInput schema / properties / check

Added value: +{
+  "default": "acceptance",
+  "description": "acceptance (default): the verdict and its evidence, with a page picture or the bars as text; say which rule cannot pass and why. structure: the structural issues (bar lengths, voices and chords, playback bindings), a page at a time with their note IDs; not a measure of transcription accuracy. listen: a second engine re-hears up to 16 bars (measures) of a recording-based score against its own recording: notes heard but not written, written but not heard, and overtones of written ones; not for written music or drums; free, about a second. watch: numbered frames of a video-based score's own video, each with the notes struck just before it (frames land just after attacks): which hand plays a note, hand position, strumming, who plays a line; never download the video yourself.",
+  "enum": [
+    "acceptance",
+    "structure",
+    "listen",
+    "watch"
+  ],
+  "type": "string"
+}

addedInput schema / properties / columns

Added value: +{
+  "description": "watch: 1 to 4; fewer columns show each frame larger.",
+  "type": "integer"
+}

addedInput schema / properties / crop

Added value: +{
+  "description": "watch: [left, top, right, bottom] as fractions of the frame from 0 to 1, such as [0, 0.5, 1, 1] for the lower half.",
+  "items": {
+    "type": "number"
+  },
+  "type": "array"
+}

addedInput schema / properties / frames

Added value: +{
+  "default": 8,
+  "description": "watch: 1 to 16.",
+  "type": "integer"
+}

addedInput schema / properties / limit

Added value: +{
+  "default": 20,
+  "description": "structure: issues per page, 1 to 100.",
+  "type": "integer"
+}

changedInput schema / properties / measures / description

Previous value: -"Up to 16 bars for the picture or text, such as 9-12."New value: +"Bars as numbered in the score: one bar or a range such as 9-12, at most 16."

addedInput schema / properties / offset

Added value: +{
+  "default": 0,
+  "description": "structure: next_offset of the previous page.",
+  "type": "integer"
+}

addedInput schema / properties / part

Added value: +{
+  "description": "listen: one part's id or name: written-not-heard notes for it only; heard_near names the other parts that write what was heard.",
+  "type": "string"
+}

addedInput schema / properties / seconds

Added value: +{
+  "description": "watch: times in the recording instead of bars.",
+  "items": {
+    "type": "number"
+  },
+  "type": "array"
+}

Changed11 schema fields changedOct 24, 2026

addedInput schema / properties / image / description

Added value: +"A page picture, for engraving: clefs, ledger lines, spacing."

removedInput schema / properties / measures / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

removedInput schema / properties / measures / default
```
Removed value: -null
```

addedInput schema / properties / measures / description

Added value: +"Up to 16 bars for the picture or text, such as 9-12."

addedInput schema / properties / measures / type
```
Added value: +"string"
```

removedInput schema / properties / revision / anyOf

Removed value: -[
-  {
-    "type": "integer"
-  },
-  {
-    "type": "null"
-  }
-]

removedInput schema / properties / revision / default
```
Removed value: -null
```

addedInput schema / properties / revision / description

Added value: +"A saved revision; the current one by default."

addedInput schema / properties / revision / type
```
Added value: +"integer"
```

addedInput schema / properties / text / description

Added value: +"The bars as text, each staff's attacks as beat and pitch, for reading phrases, figures and stray notes; without measures the whole score up to a size limit, naming the next bars to read."

addedInput schema / properties / trial / description

Added value: +"Also write the score in 3/4 and 4/4 from the recording to judge the meter (seconds)."

Changed1 schema field changedOct 17, 2026
- addedInput schema / properties / trial
```
Added value: +{
+  "default": false,
+  "type": "boolean"
+}
```
First observedOct 8, 2026

TDQS

B3.3/5.0

Behavior4/5

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

Annotations already establish readOnly/openWorld/non-destructive, and the description adds real behavioral context: listen is "free, about a second" and capped at 16 bars, text mode has a size limit, frames/columns bounds, and the caution about watch frames landing just after attacks. These details go meaningfully beyond the annotations.

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

Conciseness3/5

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

Front-loaded with "Check a saved revision," which is good, but the following sentences are dense and cryptic ("leads, not proof") rather than economical, and the meaning is hard to parse on a first read.

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 14-parameter tool with no output schema and near-complete schema coverage, the description supplies the conceptual frame (verdict-driven review) and mode trade-offs. A brief note on what a passing vs failing response looks like would close the remaining gap.

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

Parameters3/5

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

Schema coverage is 93%, so the description needn't re-document parameters and largely doesn't. It reinforces the central `check` semantics (default acceptance, what each mode returns) but adds little that the already-rich schema descriptions don't say, so baseline 3 applies.

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

Purpose3/5

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

"Check a saved revision" gives a specific verb and resource, and the acceptance explanation adds intent. But the heavy jargon ("bars," "leads, not proof," "written-not-heard notes") obscures what the tool actually does, and there is no differentiation from nearby siblings like validate_score, check_recording, or get_pro_instrument_review.

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

Usage Guidelines3/5

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

"Work from its failures until it passes" plus the check-enum breakdown (acceptance/structure/listen/watch) imply a usage flow. However, it never states when to choose this over validate_score or read_notation_view, nor any prerequisites, so guidance stays implied rather than explicit.

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

All ScoreStarling tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?