Skip to main content
Glama

ScoreStarling

by com.scorestarling
OverviewDiscussionsAdmin

Reserve audio upload

begin_audio_upload

Reserve an app-only, ten-minute, single-use upload from filename, exact byte size and processing options; this call receives no audio bytes. The panel posts raw bytes to the returned capability URL. ScoreStarling validates the size, may compress lossless audio to MP3, and retains the input under the signed-in account's task. Uploaded tasks queue for processing or wait for required instrumentation and price consent. local and piano process on ScoreStarling; mirelo uses the band transcription provider. provider, supplied quarter-note bpm and notation view configure that task. replay_only restricts configured accounts to exact saved Pro results; a cache miss cannot submit a supplier job. Ambiguous uploads retain their job identifier.

Input Schema

NameRequiredDescriptionDefault
bpmNo
sizeYes
viewNo
previewNo
filenameYes
providerNolocal
pro_optionsNoBand (Pro) rhythm and paper choices, each optional: only user-supplied or source-established ones. Pass a source-established time_signature: omission uses N/4 and never detects 6/8, 9/8 or 12/8. Otherwise timing performance (quantized snaps to a reliable beat), subdivision found by Pro, tempo follow (fixed: one tempo, at bpm), page_size a4.
replay_onlyNo
audio_secondsNo
review_instrumentsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed16 schema fields changed
    • removedInput schema / $defs
      Removed value: -{
-  "ProOptions": {
-    "additionalProperties": false,
-    "description": "Pro (Mirelo) rhythm and paper choices; each one left out keeps its default.",
-    "properties": {
-      "bpm": {
-        "anyOf": [
-          {
-            "maximum": 300,
-            "minimum": 30,
-            "type": "number"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null,
-        "description": "The constant tempo for tempo fixed, sent to Pro as given; the result states the tempo written (time_grid.tempo_bpm)."
-      },
-      "page_size": {
-        "anyOf": [
-          {
-            "enum": [
-              "a4",
-              "letter"
-            ],
-            "type": "string"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null,
-        "description": "Paper of the supplier PDFs and MusicXML; a4 (default) or letter."
-      },
-      "subdivision": {
-        "anyOf": [
-          {
-            "enum": [
-              "automatic",
-              "straight_sixteenths",
-              "eighth_triplets",
-              "sixteenth_triplets",
-              "swing_eighths"
-            ],
-            "type": "string"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null,
-        "description": "Rhythmic grid. Omit it to let Pro choose; it keeps straight sixteenths unless triplets are clear."
-      },
-      "tempo": {
-        "anyOf": [
-          {
-            "enum": [
-              "follow",
-              "fixed"
-            ],
-            "type": "string"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null,
-        "description": "follow (default) keeps the tempo changes of the playing; fixed writes one constant tempo, at bpm or else at the tempo Pro detects. A bpm given with the upload means fixed."
-      },
-      "time_signature": {
-        "anyOf": [
-          {
-            "enum": [
-              "2/4",
-              "3/4",
-              "4/4",
-              "5/4",
-              "6/4",
-              "7/4",
-              "9/4",
-              "12/4",
-              "6/8",
-              "9/8",
-              "12/8"
-            ],
-            "type": "string"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null,
-        "description": "Omit it to let Pro find the meter (written as N/4); choose 6/8, 9/8 or 12/8 explicitly for a compound meter."
-      },
-      "timing": {
-        "anyOf": [
-          {
-            "enum": [
-              "performance",
-              "quantized"
-            ],
-            "type": "string"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null,
-        "description": "performance (default) keeps the played timing; quantized aligns notes to the beat when Pro finds a reliable beat grid, otherwise the result reports a fallback."
-      }
-    },
-    "type": "object"
-  }
-}
    • removedInput schema / properties / audio_seconds / anyOf
      Removed value: -[
-  {
-    "type": "number"
-  },
-  {
-    "type": "null"
-  }
-]
    • removedInput schema / properties / audio_seconds / default
      Removed value: -null
    • addedInput schema / properties / audio_seconds / type
      Added value: +"number"
    • removedInput schema / properties / bpm / anyOf
      Removed value: -[
-  {
-    "type": "number"
-  },
-  {
-    "type": "null"
-  }
-]
    • removedInput schema / properties / bpm / default
      Removed value: -null
    • addedInput schema / properties / bpm / type
      Added value: +"number"
    • addedInput schema / properties / pro_options / additionalProperties
      Added value: +false
    • removedInput schema / properties / pro_options / anyOf
      Removed value: -[
-  {
-    "$ref": "#/$defs/ProOptions"
-  },
-  {
-    "type": "null"
-  }
-]
    • removedInput schema / properties / pro_options / default
      Removed value: -null
    • addedInput schema / properties / pro_options / description
      Added value: +"Band (Pro) rhythm and paper choices, each optional: only user-supplied or source-established ones. Pass a source-established time_signature: omission uses N/4 and never detects 6/8, 9/8 or 12/8. Otherwise timing performance (quantized snaps to a reliable beat), subdivision found by Pro, tempo follow (fixed: one tempo, at bpm), page_size a4."
    • addedInput schema / properties / pro_options / properties
      Added value: +{
+  "bpm": {
+    "maximum": 300,
+    "minimum": 30,
+    "type": "number"
+  },
+  "page_size": {
+    "enum": [
+      "a4",
+      "letter"
+    ],
+    "type": "string"
+  },
+  "subdivision": {
+    "enum": [
+      "automatic",
+      "straight_sixteenths",
+      "eighth_triplets",
+      "sixteenth_triplets",
+      "swing_eighths"
+    ],
+    "type": "string"
+  },
+  "tempo": {
+    "enum": [
+      "follow",
+      "fixed"
+    ],
+    "type": "string"
+  },
+  "time_signature": {
+    "enum": [
+      "2/4",
+      "3/4",
+      "4/4",
+      "5/4",
+      "6/4",
+      "7/4",
+      "9/4",
+      "12/4",
+      "6/8",
+      "9/8",
+      "12/8"
+    ],
+    "type": "string"
+  },
+  "timing": {
+    "enum": [
+      "performance",
+      "quantized"
+    ],
+    "type": "string"
+  }
+}
    • addedInput schema / properties / pro_options / type
      Added value: +"object"
    • removedInput schema / properties / view / anyOf
      Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
    • removedInput schema / properties / view / default
      Removed value: -null
    • addedInput schema / properties / view / type
      Added value: +"string"
  2. Changed1 schema field changed
    • addedInput schema / properties / preview
      Added value: +{
+  "default": false,
+  "type": "boolean"
+}
  3. First observed

TDQS

A3.9/5.0
Behavior5/5

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

Beyond the annotations, the description discloses many operationally important traits: app-only access, ten-minute single-use reservation, no audio bytes received, size validation, possible lossless-to-MP3 compression, retention under the signed-in account, queueing behavior, provider-specific processing, and replay_only cache-miss restrictions. It also notes that ambiguous uploads retain their job identifier. This is rich behavioral context and does not contradict 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.

Conciseness4/5

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

The description is dense but front-loads the core reservation behavior and then adds relevant workflow, provider, and restriction details. It is lengthy for a tool description, but most sentences carry useful information; the main weakness is that the dense paragraph could be structured more cleanly.

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, non-idempotent, open-world mutation tool with no output schema and very low schema description coverage, the description does a good job covering the reservation workflow, return capability URL, provider behavior, and key restrictions. It is still incomplete for an agent trying to understand preview, audio_seconds, and review_instruments without inspecting the schema.

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 only 10% across 10 parameters, so the description must carry much of the semantic burden. It explains filename, exact byte size, provider, bpm, view, and replay_only meaningfully, but it leaves preview, audio_seconds, and review_instruments unexplained and treats processing options only generically.

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 precise verb and resource: reserve a ten-minute, single-use app-only upload without receiving audio bytes, then post raw bytes to the returned capability URL. It clearly distinguishes this from an actual byte-upload step, but it does not explicitly name or differentiate the closely related prepare_audio_upload sibling.

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?

Usage is implied through the workflow: this call reserves the upload and the panel later posts bytes to the returned capability URL. However, there is no explicit guidance on when to choose this versus prepare_audio_upload or other upload-related siblings, and no when-not-to-use conditions.

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