Skip to main content
Glama
MuseScore MCP Server

MuseScore MCP Server

by lenborje

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
MUSESCORE_MCP_HOSTNoHost used by the Python client to connect to the MuseScore plugin WebSocket bridge.localhost
MUSESCORE_MCP_PORTNoPort used by the Python client to connect to the MuseScore plugin WebSocket bridge.8765
MUSESCORE_MCP_TIMEOUTNoSend/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

CapabilityDetails
tools
{
  "listChanged": false
}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}
experimental
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
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 musescore-mcp install-plugin (then restart MuseScore and relaunch the plugin).

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):

  • ctx: plugin API facade - ctx.score (current Score), ctx.newCursor(), ctx.processCommand({action, params}), ctx.processElement(element), ctx.getScoreSummary(), ctx.getVoices(params), ctx.log(msg)

  • params: the params object of this call (yours to shape)

  • state: object persisting across run_qml calls (for multi-step work; mutate it, do not reassign it) The return value must be JSON-serializable (checked before commit). Undo-aware engraving changes in a run form one undo step; errors roll them back, including nested ctx actions. Playback/mixer actions, undo and recursive eval are rejected inside a run. Raw native writes bypassing MuseScore's undo stack (such as setMetaTag) are outside this guarantee. Call get_score before and after a run when you want your own before/after comparison - the server itself keeps no state. The code runs on MuseScore's GUI thread - an infinite loop freezes MuseScore unrecoverably. See docs/AGENT-COOKBOOK.md for patterns and known pitfalls. Requires the plugin property allowEval: true; otherwise returns an error explaining how to enable it.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription
agent_cookbookrun_qml reference: contract, ctx facade, known pitfalls, worked examples.
actions_referenceFull plugin action reference (ACTIONS.md).
install_promptAgent self-install instructions (INSTALL-PROMPT.md).

TDQS

B3.4/5.0

Scored across 7 tools

Disambiguation3/5

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.

Naming Consistency4/5

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.

Tool Count4/5

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.

Completeness4/5

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).

Maintenance

ActivityMaintained
ResponsivenessNo issues