Skip to main content
Glama
Sign In
MuseScore MCP Server

MuseScore MCP Server

by ghchen99
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Find Groove Sections

find_groove_sections

Maps groove sections by identifying the groove bar, exact and near copies, and fills, then proposes measure-repeat signs for exact copies, a collapse range, and flags near copies for approval.

Instructions

Map the sections of a groove-based part (drums by default): for each section the groove bar, the bars that copy it exactly, near copies (with the hits that differ), and fills. Proposes measure-repeat signs for exact copies only, as ready-made apply_measure_repeats groups, and a collapse_to_repeat range for a 'groove bar x N' chart. Show near copies to the user and only replace them once approved: a repeat sign deletes their differences.

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

Input Schema

NameRequiredDescriptionDefault
stavesNoStaff indices to analyse (0-based). Defaults to the drum staves.
toleranceNoHow similar (0-1, share of identical hits) a bar must be to its groove to count as a near copy
end_measureNoLast measure to analyse (1-based, inclusive). Defaults to the end of the score.
start_measureNoFirst measure to analyse (1-based)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.9/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 it does disclose the important behaviors: drums are analysed by default, output is a proposal ('ready-made apply_measure_repeats groups') rather than an applied edit, and accepting a repeat sign destroys near-copy differences. It stops short of stating outright that the tool itself is read-only or describing the size/shape of the result.

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?

Three dense sentences, front-loaded with the core action before output details and the caution about approval. Every clause carries information, though the long middle sentence listing outputs is somewhat hard to parse at speed.

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?

There is no output schema, so the description usefully enumerates what is returned and how the proposals map to sibling tools. For a 4-parameter analysis tool with full schema coverage, this covers what an agent needs to call it and act on the result, with only the exact result format left unspecified.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so staves, tolerance, start_measure and end_measure are already fully documented in the input schema. The description adds only the 'drums by default' intent behind the staves parameter and does not elaborate on tolerance behavior or measure-range interaction beyond what the schema says. Baseline 3 is appropriate.

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 opens with a specific verb and resource ('Map the sections of a groove-based part') and enumerates the outputs: groove bar per section, exact copies, near copies with differing hits, and fills. It is clearly distinct from mutating siblings and points at apply_measure_repeats and collapse_to_repeat as downstream consumers, though it never explicitly contrasts itself with find_repeated_measures.

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 clear situational guidance: use it to locate groove sections, show near copies to the user, and only replace them once approved. The warning that 'a repeat sign deletes their differences' tells the agent not to skip approval. It lacks an explicit statement of when a different analysis tool (e.g. find_repeated_measures) is the better choice.

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