Skip to main content
Glama
Sign In
MuseScore MCP Server

MuseScore MCP Server

by ghchen99
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Label Section Counts

label_section_counts

Write section bar counts into MuseScore rehearsal marks, in parentheses or beside labels, to show section length; rerun to replace counts or clear them.

Instructions

Write each section's bar count (e.g. '2x4+2'). placement='label' (default, the chart style the user chose) puts it in parentheses in the section label (rehearsal mark): 'Chorus 1 (2x4)', and sets the labels to label_size points with label_clearance spaces around them, so MuseScore places and spaces them. placement='beside' writes it in bold red right of the label at the label's height (moved past a text already there or up over notes); MuseScore doesn't leave room for it between systems, so it can run into dynamics of the system above: only on request. Without counts, uses song_structure's counts (the ones already written in the labels where they still add up). Running it again replaces the counts in either form; clear=True removes them.

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": "label_section_counts"
  }
}

Input Schema

NameRequiredDescriptionDefault
sizeNoFont size in points (placement='beside')
clearNoRemove the counts instead (at the given measures, or at every section label)
colorNoText color (placement='beside')#d62728
staffNoStaff to analyse when counts are computed (0-based). Defaults to the first drum staff.
countsNoCounts to write: [{"measure": 8, "text": "2x4+2"}] (measure = the bar holding the section label). Defaults to song_structure's counts.
placementNoIn parentheses in the section label, or as red text beside itlabel
label_sizeNoSection label font size in points (placement='label'; MuseScore's default is 14); None leaves it
label_clearanceNoMinimum space around section labels in staff spaces (placement='label'; MuseScore's default is 0.5); None leaves it

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.8/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 discloses substantial behavior: effects on label_size and label_clearance, idempotency (re-running replaces counts), removal via clear, and the risk of 'beside' colliding with dynamics. Minor gaps remain, such as what happens when no song_structure counts exist and none are provided.

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 description is a single dense paragraph that front-loads the main action but uses many clauses and semicolons, making it somewhat hard to scan. It is efficient with no redundant sentences, though bullet points or shorter sentences would improve structure.

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 an 8-parameter mutation tool with no annotations and no output schema, the description covers the key behaviors, defaults, side effects, and risks. It is nearly complete, with only minor omissions around edge cases like missing counts or connection requirements.

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, but the description adds meaning beyond the schema: it explains that default counts come from song_structure's already-written labels where they still add up, and clarifies the replacement and clear behaviors in context.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action – writing each section's bar count into the section label – with a concrete example format. It does not explicitly contrast with siblings like add_label or add_rehearsal_mark, so it falls short of full sibling differentiation.

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

Usage Guidelines3/5

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

It gives clear guidance for the placement parameter (default 'label', 'beside' only on request due to collision risk) and mentions using song_structure's counts. However, it provides no explicit guidance on when to use this tool versus alternatives such as add_label or song_structure.

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