Skip to main content
Glama

ScoreStarling

by com.scorestarling
OverviewDiscussionsAdmin

Save edited notation

revise_score

Save an edited MusicXML copy as the next revision of the same score; its recording, comments, panel and undo history stay. Never create a new score to change an existing one. For changes one operation cannot make: keep each exported note's id, so notes keep their timing.

Input Schema

NameRequiredDescriptionDefault
fileNoThe edited MusicXML or MXL, attached.
previewNotrue saves it as a suggestion the user can Apply or Discard.
musicxmlNoThe edited MusicXML as text, instead of file: the editing copy of this revision with every note's id kept. A note keeps its played timing whatever its written rhythm, staff or voice; a changed pitch plays the new pitch, a removed note stops sounding, a note without an id is added where it is written. Without the ids a recording's score takes only changes that keep every pitch.
revisionYesThe current saved revision, from the latest read or edit.
score_idYes
request_idNoA stable ID (16 to 80 letters, digits or hyphens); send the same one again after an unclear response.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed17 schema fields changed
    • addedInput schema / properties / file / additionalProperties
      Added value: +false
    • removedInput schema / properties / file / anyOf
      Removed value: -[
-  {
-    "additionalProperties": false,
-    "properties": {
-      "download_url": {
-        "type": "string"
-      },
-      "file_id": {
-        "type": "string"
-      },
-      "file_name": {
-        "default": "",
-        "type": "string"
-      },
-      "mime_type": {
-        "default": "",
-        "type": "string"
-      }
-    },
-    "required": [
-      "download_url",
-      "file_id"
-    ],
-    "type": "object"
-  },
-  {
-    "type": "null"
-  }
-]
    • removedInput schema / properties / file / default
      Removed value: -null
    • addedInput schema / properties / file / description
      Added value: +"The edited MusicXML or MXL, attached."
    • addedInput schema / properties / file / properties
      Added value: +{
+  "download_url": {
+    "type": "string"
+  },
+  "file_id": {
+    "type": "string"
+  },
+  "file_name": {
+    "default": "",
+    "type": "string"
+  },
+  "mime_type": {
+    "default": "",
+    "type": "string"
+  }
+}
    • addedInput schema / properties / file / required
      Added value: +[
+  "download_url",
+  "file_id"
+]
    • addedInput schema / properties / file / type
      Added value: +"object"
    • removedInput schema / properties / musicxml / anyOf
      Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
    • removedInput schema / properties / musicxml / default
      Removed value: -null
    • addedInput schema / properties / musicxml / description
      Added value: +"The edited MusicXML as text, instead of file: the editing copy of this revision with every note's id kept. A note keeps its played timing whatever its written rhythm, staff or voice; a changed pitch plays the new pitch, a removed note stops sounding, a note without an id is added where it is written. Without the ids a recording's score takes only changes that keep every pitch."
    • addedInput schema / properties / musicxml / type
      Added value: +"string"
    • addedInput schema / properties / preview / description
      Added value: +"true saves it as a suggestion the user can Apply or Discard."
    • removedInput schema / properties / request_id / anyOf
      Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
    • removedInput schema / properties / request_id / default
      Removed value: -null
    • addedInput schema / properties / request_id / description
      Added value: +"A stable ID (16 to 80 letters, digits or hyphens); send the same one again after an unclear response."
    • addedInput schema / properties / request_id / type
      Added value: +"string"
    • addedInput schema / properties / revision / description
      Added value: +"The current saved revision, from the latest read or edit."
  2. First observed

TDQS

A4.1/5.0
Behavior5/5

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

The description adds substantial behavioral context beyond annotations: the operation preserves the recording, comments, panel and undo history, and notes keep their timing when ids are retained. This is valuable for a mutation tool whose annotations only state that it is not read-only, not destructive and not idempotent.

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?

The description is front-loaded and compact at three sentences. The final sentence is useful but slightly indirect; overall it avoids waste and earns its space.

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 complex mutation with no output schema, the description covers the core behavior and important preservation semantics. It is still missing return-value information and explicit differentiation from save_score_edits, but it is sufficient for correct invocation in most cases.

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 description coverage is high at 83%, so the schema already carries most parameter meaning. The description reiterates the note-id timing behavior that is also explained in the musicxml parameter description, but it adds little new information about file, preview, revision, or request_id.

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 gives a specific verb and resource: save an edited MusicXML copy as the next revision of the same score. It clearly distinguishes this from create_score by saying never to create a new score to change an existing one, but it does not differentiate from the closest sibling save_score_edits.

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 provides a clear when-not rule: never create a new score to change an existing one. It also gives guidance for a specific edge case involving note ids and timing. However, it does not explicitly compare this tool with save_score_edits or preview_score_edit, leaving some sibling-selection ambiguity.

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

All ScoreStarling toolsInspect
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