Skip to main content
Glama
Sign In
MuseScore MCP Server

MuseScore MCP Server

by ghchen99
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Highlight Notes

highlight_notes

Mark matching notes, drum pieces, or pitches with translucent boxes across selected measures to visually identify specific hits and chord tones in a score.

Instructions

Highlight individual hits like a highlighter pen: a translucent box around each matching note, as wide as the note and as tall as the whole staff (taller if the note sits above or below it). Hits close enough for their boxes to touch share one box. Use drums (e.g. ["crash"]) or pitches to pick notes in a chord. start_beat/end_beat limit it to part of a bar. Boxes are sized to the current layout: if the layout changes a lot, clear and highlight again. Remove with clear_highlights.

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": {
      "start_measure": "<start_measure>"
    },
    "name": "highlight_notes"
  }
}

Input Schema

NameRequiredDescriptionDefault
colorNoHighlight color as "#rrggbb" (default yellow)#ffd600
drumsNoDrum kit pieces to mark, e.g. ["crash"], ["kick", "snare"], ["hi-hat"]
opacityNoOpacity from 0 to 1
pitchesNoMIDI pitches to mark (e.g. 57 for crash 2). Combined with drums; all notes if both are empty.
end_beatNoLast beat in end_measure to include, the whole beat (e.g. 4 = through the end of beat 4). Defaults to the end of the measure.
last_staffNoLast staff (0-based, inclusive). Defaults to first_staff.
start_beatNoBeat in start_measure where coloring starts (1-based; fractions allowed, e.g. 3.5 for the 'and' of 3). A beat is the time signature's denominator: a quarter in 4/4, an eighth in 6/8. Defaults to the start of the measure.
end_measureNoLast measure (1-based, inclusive). Defaults to start_measure.
first_staffNoFirst staff (0-based)
start_measureYesFirst measure (1-based)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.3/5.0
Behavior4/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 well: it discloses the visual rendering rule, the box-merging behavior for adjacent hits, and the important caveat that boxes are sized to the current layout and go stale if the layout changes. It leaves unstated whether repeated calls add to or replace existing highlights and whether highlights persist in the saved score.

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?

The core visual concept is front-loaded in the opening clause, then filtering, range, and lifecycle details follow in a sensible order. The parenthetical about boxes being taller for notes above or below the staff is slightly wordy but earns its place by clarifying the rendering rule.

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 10-parameter, annotation-free mutation of the score view with no output schema, the description covers rendering, selection, scoping, staleness, and cleanup adequately. The remaining gap is return behavior and add-vs-replace semantics, which an agent would want before calling it repeatedly.

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 and the schema already documents every field including defaults and 1-based indexing. The description adds a bit beyond that by explaining how drums and pitches combine to select notes within a chord and that beat bounds scope the call to part of a bar.

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 names a specific verb and resource (highlight individual note hits) and immediately defines the rendered result — a translucent box as wide as the note and as tall as the staff. The note-level scope implicitly separates it from sibling highlighting tools such as highlight_bars, highlight_symbols, and highlight_markings, and clear_highlights is named for removal.

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 concrete usage context: pick notes by drum name or MIDI pitch, and restrict to part of a bar with start_beat/end_beat. It also sets lifecycle expectations — re-run after large layout changes, and use clear_highlights to remove — but never explicitly says when to choose highlight_bars or highlight_symbols instead.

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