MuseScore MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| MUSESCORE_MCP_HOST | No | Host used by the Python client to connect to the MuseScore plugin WebSocket bridge. | localhost |
| MUSESCORE_MCP_PORT | No | Port used by the Python client to connect to the MuseScore plugin WebSocket bridge. | 8765 |
| MUSESCORE_MCP_TIMEOUT | No | Send/response timeout in seconds for the bridge, overriding the default 30-second timeout. | 30 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| connect_to_musescoreB | Open the WebSocket to the MuseScore plugin; returns {"success": bool}. |
| ping_musescoreA | Ping the MuseScore WebSocket API to check the connection. Also performs a version handshake: the response carries the
server version and the plugin's version. If versionsMatch is
false, the installed plugin is out of sync with the server -
fix with |
| get_scoreA | Get the full score analysis (metadata, all measures, staves, notes, harmonies). |
| get_score_metadataA | Get score metadata only (title, composer, measures, staves, time/key signatures). |
| get_cursor_infoA | Get the current cursor position, the selection and a score summary. |
| processSequenceC | Process a sequence of documented plugin actions. Each entry is {action, params}; the available actions, their parameters and return shapes are specified in docs/ACTIONS.md. Sequences may nest one level (a processSequence action inside a sequence); edit actions are wrapped and rolled back per action. |
| run_qmlA | Execute QML/JavaScript code inside the MuseScore plugin and return its result. For complex score tasks that would otherwise need many round trips. The code is a function body, run as function(ctx, params, state):
|
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| agent_cookbook | run_qml reference: contract, ctx facade, known pitfalls, worked examples. |
| actions_reference | Full plugin action reference (ACTIONS.md). |
| install_prompt | Agent self-install instructions (INSTALL-PROMPT.md). |
TDQS
Scored across 7 tools
The read tools have a clear subset relationship (get_score_metadata is a lighter get_score) and connect/ping are distinguishable, but two generic escape hatches exist: processSequence runs documented actions while run_qml runs arbitrary code that can itself call ctx.processCommand, so their boundary is fuzzy. Descriptions help, but an agent must reason about which execution path to pick.
Six of seven tools follow a consistent snake_case verb_noun pattern (connect_to_musescore, get_score, get_cursor_info, run_qml, etc.). processSequence is the sole camelCase outlier, a minor but noticeable deviation from an otherwise predictable convention.
Seven tools is well within the sweet spot and the set is logically grouped (connection, reads, execution). The one arguable redundancy is get_score_metadata, whose output is already contained in get_score, so not every tool strictly earns its place.
Connection, health/version check, full and partial score reads, cursor/selection state, batched action sequencing, and arbitrary scripting give broad lifecycle coverage, including edits and rollback. Gaps are minor: no explicit disconnect/close tool and no tool to enumerate available actions (agents must consult docs/ACTIONS.md externally).