Skip to main content
Glama
Sign In
MuseScore MCP Server

MuseScore MCP Server

by ghchen99
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Set End Notes

set_end_notes

Add or replace end-of-score notes in a bold text frame, with one line per item; enable append to keep existing lines, or clear them by providing no heading and no lines.

Instructions

Print notes at the end of the score, in a text frame after the last bar: a bold heading and one line per item, e.g. a summary of how a chart differs from the original (what was collapsed, which differences were dropped, what stays written out). Replaces notes added before (the report's previous lists them), so it can be re-run; append=True keeps their lines and adds the new ones; no heading and no lines removes them. Edits the score file and reloads it (undo with restore_backup).

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": {
      "lines": "<lines>"
    },
    "name": "set_end_notes"
  }
}

Input Schema

NameRequiredDescriptionDefault
linesYesLines of text, e.g. ["Verses 1-3: groove x9 each", "Dropped: open-hat endings"]
appendNoKeep the lines already printed and add these after them (skipping repeats), e.g. when finishing a chart made in an earlier session
headingNoBold heading above the linesChanges from the original
score_pathNoPath of the score file. Defaults to the file of the score open in MuseScore.

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, the description carries the full burden and does so: it discloses that prior notes are replaced (listed in the report's `previous`), that append=True keeps existing lines and skips repeats, that empty heading and lines remove the notes, that the score file is edited and reloaded, and that restore_backup undoes it. These are exactly the side effects an agent needs before calling a mutation tool.

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?

It is a single dense paragraph, but front-loaded with purpose before consequences, and nearly every clause carries behavioral information. Some of the parenthetical example content ('what was collapsed, which differences were dropped, what stays written out') is slightly redundant with the schema's example lines.

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 description covers side effects, reversibility, and re-run safety well, and hints at a returned report containing `previous`. It does not address failure cases such as an invalid score_path or a score with no room for the frame, which is a modest remaining gap.

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, but the description adds meaning beyond the schema by explaining the combination semantics: append interacts with existing printed lines, and providing neither heading nor lines is the deletion path. That compound behavior is not derivable from the schema fields alone.

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?

The description states a specific verb and resource – printing notes into a text frame at the end of the score, after the last bar – and includes the concrete shape of the output (bold heading plus one line per item). This clearly separates it from add_text or set_score_header style siblings that also write text.

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?

It gives a concrete use case (summarizing how a chart differs from the original) and spells out the replace/append/clear conditions, including that it can be safely re-run. It never names an alternative tool such as add_text, but the when-to-use conditions are otherwise explicit.

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