Skip to main content
Glama
Sign In
MuseScore MCP Server

MuseScore MCP Server

by ghchen99
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Add Tie

add_tie

Ties pitches shared by the chord at the cursor and the next chord, optionally only selected MIDI pitches. The cursor moves to the next chord so repeated calls continue a tie chain.

Instructions

Tie notes of the chord at the cursor to the same pitches in the next chord of that staff. A tie joins two notes of the same pitch into one longer sound. Only pitches in both chords can be tied: by default every such pitch is tied; pass pitches to tie only some of them (e.g. tie C and E of C-E-G into C-E-A with pitches=[60, 64]). Afterwards the cursor is on the second chord, so calling add_tie again continues a tie chain. Note that after add_note the cursor is already on the next position: move back to the first note (e.g. with prev_element) before calling add_tie. Write both chords completely before tying: MuseScore treats tied chords as one, so a pitch added afterwards with add_note(add_to_chord=True) to the second chord is also added, tied, to the first. While writing music, add_tied_note is usually simpler. Fails without changing the score when no pitch can be tied, e.g. when the next element is a rest.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "add_tie"
  }
}

Input Schema

NameRequiredDescriptionDefault
pitchesNoMIDI pitches to tie (e.g. [60, 64]). Default: every pitch that is in both chords.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.4/5.0
Behavior3/5

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

No annotations are supplied, so the description carries the full burden. It does well on the operation, distinguishing positions and failure modes, but it does not state permission or score-mutation side effects beyond cursor movement, nor does it specify whether failure is reported by exception, return value, or silent partial application.

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?

Purpose is front-loaded in the first sentence, and the remaining sentences handle exceptions and workflow details. It is somewhat long for a one-parameter tool, but most sentences add concrete information, so the length is mostly justified.

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?

The description covers the operation, the default behavior, the effect on cursor position, the chaining workflow, ordering constraints relative to add_note, and failure conditions. For a one-parameter tool with no output schema and no annotations, this is enough 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 already 100%, so the bar is higher. The description goes beyond the schema by explaining the default (all shared pitches tied) and by giving a worked example with concrete MIDI values showing partial selection. This meaningfully reduces ambiguity about what the optional pitches array does.

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 concrete verb and object: tie the pitches of the chord at the cursor to matching pitches in the next chord of that staff. It also delimits the operation (only pitches present in both chords can be tied), which separates it from add_note and add_tied_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 routing advice ('add_tied_note is usually simpler'), the preconditions for calling it after add_note (move back with prev_element), and the ordering requirement that both chords be complete first. It also names a failure case (next element is a rest) so the agent knows when not to expect success.

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