Skip to main content
Glama
Sign In
MuseScore MCP Server

MuseScore MCP Server

by ghchen99
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Add Tied Note

add_tied_note

Write the next note or chord tied to the chord before the cursor, extending it across a barline after adding a note. Specify pitches to tie only selected pitches or extra pitches for new chord tones.

Instructions

Write the next note or chord at the cursor, tied to the chord before the cursor: like pressing + in MuseScore's note input. Use it after add_note to hold a note longer, e.g. across a barline. By default the new chord repeats every pitch of the chord before it, all tied; pass pitches to tie only some of them, and extra_pitches for new pitches in the same chord without a tie (e.g. C-E-G into C-E-A: pitches=[60, 64], extra_pitches=[69]). Add new pitches this way, not with add_note(add_to_chord=True) afterwards: MuseScore treats tied chords as one and would also add the pitch, tied, to the chord before. A note longer than the rest of the bar is split at the barline into tied notes, and the cursor moves past all of it. Fails without changing the score when there is no note before the cursor or a pitch is not in it.

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": {
      "duration": "<duration>"
    },
    "name": "add_tied_note"
  }
}

Input Schema

NameRequiredDescriptionDefault
pitchesNoMIDI pitches of the chord before the cursor to continue with a tie. Default: all of them.
durationYesDuration of the new note as {"numerator": int, "denominator": int} (e.g. {"numerator": 1, "denominator": 8} for an eighth note)
extra_pitchesNoMIDI pitches to add to the new chord without a tie (e.g. [69])
advance_cursor_after_actionNoWhether to move the cursor past the new note

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.9/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden and does so: it discloses cursor movement, barline splitting into tied notes, and precise failure conditions (no note before cursor, pitch not in the chord) along with the guarantee that failure leaves the score unchanged. It also explains the surprising MuseScore behavior that motivates the extra_pitches path.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

Dense and front-loaded: the core action leads, followed by usage, the parameter nuance, and finally failure behavior. Every sentence contributes a distinct fact; there is no restatement of the title or name.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 4-parameter mutation tool with a nested duration object, no annotations, and no output schema, the description covers action, alternatives, parameter interplay, side effects on the cursor, and error behavior. An agent has everything needed to call it correctly.

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 baseline is 3, and the description earns extra credit by explaining the interaction between pitches and extra_pitches with a worked example (C-E-G into C-E-A: pitches=[60, 64], extra_pitches=[69]). The tie-vs-no-tie distinction between the two arrays is meaning beyond the schema's own wording. advance_cursor_after_action is only implicitly covered by "the cursor moves past all of it".

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?

States a specific verb and resource — "Write the next note or chord at the cursor, tied to the chord before the cursor" — and anchors it to a concrete analogy (pressing + in note input). This clearly separates it from the sibling add_tie (which ties existing notes) and add_note (which writes an untied note).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit when-to-use ("Use it after add_note to hold a note longer, e.g. across a barline") and an explicit when-not-to / alternative-workaround warning: add new pitches via extra_pitches rather than add_note(add_to_chord=True), with the reason spelled out. Nothing is left to inference.

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