Music Studio

Convert ABC to Strudel

convert-abc-to-strudel

Read-onlyIdempotent

Turn an ABC melody into Strudel mini-notation so a scored piece can be remixed live. Returns runnable code — setcps() from the Q: tempo, one [...] bar group per bar inside note("<...>"), with a chord("<...>").voicing() layer stacked alongside it when the ABC has chord symbols (one stack(), because Strudel plays only the last expression) — then pass it to play-live-pattern. Durations become @ weights, rests become ~, triplets nest, the key signature is folded into the note names, and %%MIDI program picks the sound. Lists what was lost (grace notes, dynamics, repeats, lyrics, other voices, inline tempo changes, a short final bar, ABC's own gchord/drum accompaniment). Pick a single voice with voice; re-run per voice and stack() them for a full arrangement.

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": {
      "abcNotation": "<abcNotation>"
    },
    "name": "convert-abc-to-strudel"
  }
}

Input Schema

Name	Required	Description
`sound`	No	Strudel sound for the melody (defaults to the tune's %%MIDI program, else "gm_piano"). Use a GM soundfont name like gm_flute or gm_epiano1 — see get-strudel-guide topic 'sounds'.
`voice`	No	Which voice to convert, 1-based, counted across all staves (default 1). Multi-voice tunes report how many voices there are.
`abcNotation`	Yes	ABC notation to convert (the same string you'd pass to play-sheet-music).

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 7, 2026

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

AddedSep 8, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes well beyond the annotations (readOnly/idempotent/non-destructive already cover safety) by describing the exact output shape: setcps() from the Q: tempo, one [...] bar group per bar inside note("..."), and a chord("...").voicing() layer with a single stack() because 'Strudel plays only the last expression'. It also discloses transformation rules (@ weights, ~ for rests, nested triplets, key-signature folding, %%MIDI program) and enumerates what is lost (grace notes, dynamics, repeats, lyrics, other voices, inline tempo changes, short final bar, gchord/drum accompaniment).

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?

Front-loaded with the purpose and the return contract, and the dense lost-features list is genuinely informative rather than filler. It is a single long paragraph with heavy em-dash nesting, so scanning takes effort even though nearly every clause earns its place.

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?

There is no output schema, and the description compensates fully by specifying the generated code's structure, the required wrapper expression, and the fidelity losses an agent should warn about. Nothing needed to call it correctly or interpret its result is missing.

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; the description still adds meaning by explaining the voice parameter's arrangement workflow (re-run per voice and stack() them) and by tying `sound` to the tune's %%MIDI program default. It does not restate parameter types or formats, which is appropriate.

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 specific verb and resource ('Turn an ABC melody into Strudel mini-notation') plus the downstream intent ('so a scored piece can be remixed live'). It is clearly distinguishable from siblings like play-sheet-music and play-live-pattern because it produces code rather than playing anything.

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?

Explicitly routes the agent forward: the result is meant to be 'pass[ed] to play-live-pattern', and it explains the multi-voice workflow ('Pick a single voice with `voice`; re-run per voice and stack() them for a full arrangement'). It lacks an explicit when-not-to-use statement or a direct contrast with play-sheet-music, which is only hinted at in the abcNotation schema text.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Music Studio tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.