Skip to main content
Glama
Sign In
MuseScore MCP Server

MuseScore MCP Server

by ghchen99
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Make Part Score

make_part_score

Creates a separate score containing only selected parts, such as a drum kit, while preserving the original and handling damaged bars.

Instructions

Make a separate score containing only some parts (e.g. the drum kit) to build a chart in: saves the current score, writes a copy of its file without the other instruments (tempo, rehearsal marks, repeats and the title move to the kept staff), closes the original and opens the copy in its place (the plugin can only work in its own window). The original is saved and unchanged; if the copy can't be opened, the original is reopened. Works even when another instrument has a damaged bar. in_place=True instead removes the other instruments from the open score itself, without saving anything first (so a damaged bar in another instrument is never written again) and after backing up the full score (MusicXML export, plus a copy of its .mscz when it can be identified); it reports bars left that don't add up. Staff indices in the new score start again from 0.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "staves": "<staves>"
    },
    "name": "make_part_score"
  }
}

Input Schema

NameRequiredDescriptionDefault
stavesYesStaff indices (0-based) whose parts to keep
in_placeNoRemove the other instruments from the open score (after backing up the full score) instead of making a copy
score_pathNoPath of the current score's file. Defaults to the file of the score open in MuseScore.
output_pathNoWhere to save the new score (.mscz). Defaults to next to the original, named after the part.

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 so thoroughly: it discloses that the original is saved and unchanged, that the original is closed and the copy opened in its place, that the original is reopened if the copy fails, and that in_place mode first exports MusicXML plus a .mscz backup and reports bars that don't add up. These are exactly the side effects, failure modes and data-safety guarantees an agent needs before invoking a file-mutating operation.

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, and nearly every clause carries real information (safety of the original, fallback path, backup contents, index renumbering). The weakness is structure: it is one long paragraph with nested parentheticals, and the in_place mode switch is buried mid-sentence rather than set apart, which makes skimming harder than it needs to be.

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 mutation tool with no annotations and no output schema, the definition covers side effects, backup strategy, failure recovery, and a damaged-input edge case. The remaining gap is the return value: it mentions that a report of non-summing bars exists but not what the tool returns on success or failure, which matters since there is no output schema to fall back on.

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 the baseline is 3; the description earns a bump by explaining the consequence of in_place beyond the schema's wording (no save first, backup taken, damaged bars avoided, bars reported). It also clarifies that staff indices in the resulting score restart at 0, which affects how the kept staves map into the output. It adds no syntax detail for staves or output_path beyond what the schema already states.

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?

Opens with a specific verb and resource: "Make a separate score containing only some parts (e.g. the drum kit)" — an agent immediately knows this extracts a subset of staves into a new file. It goes further by distinguishing the two operating modes (copy-out vs. in_place removal), so the tool's scope is unambiguous without opening the schema.

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?

Gives a clear decision rule: default behaviour makes a copy, while "in_place=True instead removes the other instruments from the open score itself, without saving anything first", and explains why (avoiding rewriting a damaged bar). It also states a hard constraint on the tool's environment ("the plugin can only work in its own window"). It does not name any alternative sibling tool for the adjacent tasks, which keeps it short of a 5.

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