ABC sheet music + Strudel live coding: songs, videos and live jam sessions in ext-apps widgets.
Scored across 10 tools
Most tools target distinct actions (harmony analysis, ABC-to-Strudel conversion, sheet playback, live playback, session read/write, sharing). The only real overlap is between get-music-guide, get-strudel-guide, and search-music-docs, which all supply reference material, but the descriptions clearly separate curated guides from semantic search and split by domain (ABC vs Strudel).
All ten names are consistent snake_case with a verb-first pattern (analyze-, convert-, create-, get-, play-, search-, update-). Even the longer compound names (convert-abc-to-strudel, create-share-link) follow the same convention, making the set fully predictable.
Ten tools is well within the ideal range and each earns its place across theory, conversion, two playback modes, live-session control, guides, and sharing. No redundant or filler tools are present.
The surface covers the full music workflow: harmony analysis, format conversion, sheet and live playback, session read/write, documentation, and sharing. Minor gaps exist, such as no explicit stop/close tool for playback or sessions, but these are largely handled by the player or human actions and are easy to work around.
Music theory helper: name a chord from notes, guess the key, get a progression, or list what fits a key. Returns both the ABC chord-symbol spelling (for play-sheet-music) and the Strudel form (for play-live-pattern). Tasks: detect-chord (notes -> chord name + what to play next), detect-key (notes or chords -> best key + diatonic chords), suggest-progression (key [+ romanNumerals] -> chord symbols), scale-for-chord (chords -> the scale to improvise over each), key-chords (key -> every diatonic triad, seventh, and chord scale). Use it before writing chord symbols for a style preset, or to check a harmonization.
| Name | Required | Description | Default |
|---|---|---|---|
| key | No | Key, e.g. "C", "A minor", "F# major". For suggest-progression/key-chords. | |
| task | Yes | What to work out. detect-chord needs notes; detect-key needs notes or chords; scale-for-chord needs chords; suggest-progression/key-chords need a key. | |
| notes | No | Note names, e.g. ["c4","e4","g4","b4"] or ["C","Eb","G"]. For detect-chord/detect-key. | |
| chords | No | Chord symbols, e.g. ["Dm7","G7","Cmaj7"]. For detect-key/scale-for-chord. | |
| romanNumerals | No | Roman numerals to render in the key, e.g. ["ii7","V7","Imaj7"] or ["I","V","vi","IV"]. Optional for suggest-progression — omit it to get common progressions instead. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the read-only, side-effect-free nature is covered. The description adds valuable behavioral detail beyond that: it states that the tool returns both ABC chord-symbol spelling (for play-sheet-music) and Strudel form (for play-live-pattern), which tells the agent what outputs to consume. It also notes that omitting romanNumerals yields common progressions, adding a behavioral nuance not in the schema or annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-structured: it leads with a one-line purpose, then lists output forms, then breaks down each task with inputs and outputs. Every sentence adds information—no filler or tautology. It is on the longer side but justified by the breadth of five distinct tasks. The front-loading of purpose and task list helps an agent quickly grasp the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 must convey what results look like; it does this by stating each task's output (e.g., 'notes -> chord name + what to play next', 'key -> every diatonic triad, seventh, and chord scale'). It covers all five tasks, their inputs, and the dual output formats. While it doesn't discuss error handling or edge cases, for a read-only analysis tool with full schema coverage this is sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so every parameter is already documented. The description adds useful guidance on parameter usage, such as mapping tasks to required inputs and explicitly noting that romanNumerals is optional and should be omitted for common progressions. This goes beyond the schema's per-field descriptions by clarifying inter-parameter dependencies and the conditional nature of optional parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear, specific statement of purpose: 'Music theory helper: name a chord from notes, guess the key, get a progression, or list what fits a key.' It enumerates all five tasks explicitly and states that output includes both ABC chord-symbol and Strudel forms. This is a distinct resource (music theory analysis) with no confusion with sibling tools like conversion or playback.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a concrete use case: 'Use it before writing chord symbols for a style preset, or to check a harmonization.' It also details which input each task requires (e.g., 'detect-chord needs notes'). While it doesn't explicitly say when NOT to use it or name alternative tools, the task enumeration and input requirements make the appropriate usage clear enough for correct selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and idempotent hints. The description goes beyond by explaining that it returns runnable code (no side effects) and transparently lists what is lost (grace notes, dynamics, etc.), which is additional behavioral transparency beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is detailed and covers purpose, output structure, transformations, limitations, and usage, but each sentence adds value. It is somewhat long but remains focused and information-dense, not redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description fully explains the return value (runnable Strudel code) and its structure (setcps, bar groups, chord voicing). It also covers limitations and downstream usage, making the tool's behavior clear without needing additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all parameters, but the description adds meaning by explaining how `voice` affects output (single voice selection, stacking for multiple voices) and references play-sheet-music for `abcNotation`. This goes beyond the schema descriptions, enriching parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool converts ABC notation into Strudel mini-notation for live remixing, with a specific verb ('Turn... into') and resource. It also implies a distinct workflow from siblings by mentioning the downstream play-live-pattern tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context for when to use (live remixing, multi-voice stacking) and explains output usage, but does not explicitly name alternatives or conditions for choosing this tool over siblings like play-sheet-music or search-music-docs. Usage is implied rather than explicitly contrasted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reference for ABC sheet music. Topics: genres (complete templates: jazz, blues, folk, rock, bossa, a 3/4 minuet, a lullaby), styles (what each accompaniment preset does), instruments (GM list + combos), drums (patterns + percussion notes), abc-syntax (notation reference), arrangements (multi-voice patterns), midi-directives (%%MIDI reference).
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | Reference topic. Start with 'genres' for complete examples, 'styles' to understand presets, or 'instruments' for the full instrument list. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuine content-level context by spelling out what each topic returns (complete genre templates, preset behavior, GM list plus combos, drum patterns plus percussion notes), which tells the agent what to expect from the call.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense sentence with the resource statement front-loaded and the topic inventory following as a compact list; every clause maps to a real capability. Slightly list-heavy, but there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter, read-only reference tool with no output schema, the description covers the topics well enough that the agent knows what each call yields. The only missing element is routing versus the sibling search and guide tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with a single enum parameter, so the schema already carries the parameter semantics and baseline is 3. The description largely restates the enum values, though it does add specificity for 'genres' (jazz, blues, folk, rock, bossa, minuet, lullaby) that is not in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a concrete resource ('Reference for ABC sheet music') and enumerates the seven content topics, so an agent knows exactly what kind of artifact this returns. However, it never differentiates itself from the closely named sibling search-music-docs or get-strudel-guide, leaving the agent to infer that this is a static reference rather than a search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied by the nature of a reference tool; the description gives no when-to-use framing and never names alternatives such as search-music-docs for free-text lookup or get-strudel-guide for the other notation language. The routing hint ('Start with genres...') lives in the schema's enum description, not in the tool description itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Only for a live session (play-live-pattern session: true). Reads whether the player is up and what it played, its errors and silences, and what the human did since your last read: taps, changes to remember() state, code they ran, a Pass to you, or End. Read it before assuming a piece played. With wait: 'pass' it listens until the human presses Pass, so a whole back-and-forth set fits in one turn: update-session, get-session(wait: 'pass'), answer, listen again.
| Name | Required | Description | Default |
|---|---|---|---|
| wait | No | Listen instead of just reading: 'pass' until the listener presses Pass, 'activity' until they play. Returns at once if that already happened since your last read, else after ~40 s — call again to keep listening. | |
| session | Yes | The session id from play-live-pattern's result (16 lowercase letters/digits). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare it as a non-destructive read, so the safety profile is covered; the description adds genuinely new context by disclosing the delta semantics ("what the human did since your last read"), which explains why idempotentHint is false. It could still say more about what happens on concurrent reads, but the added behavioral value is real.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Dense but front-loaded: the live-session restriction and read purpose come first, then the return contents, then the wait workflow. Nearly every clause carries information, though the final workflow sentence is slightly packed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the burden of describing returns and does so concretely (player state, plays, errors, silences, taps, remember() changes, code, Pass, End). An agent has everything needed to call it correctly and interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3; the description earns an extra point by explaining the practical effect of wait:'pass' (a whole back-and-forth set in one turn) beyond the schema's mechanical timeout description. The session id parameter is well covered by the schema pattern.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (reads) and resource (live session state) and enumerates exactly what is returned: whether the player is up, what it played, errors, silences, and human actions. It distinguishes itself from siblings by tying session creation to play-live-pattern and the write path to update-session.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit precondition ("Only for a live session") and a concrete rule of thumb ("Read it before assuming a piece played"), plus an end-to-end workflow with update-session and the wait:'pass' loop. When-to-use and how-it-fits-with-alternatives are both covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reference and recipes for Strudel live coding. Music: genres (complete templates: techno, house, dnb, ambient, jazz, lofi, synthwave), mini-notation, sounds (synths, 71 drum banks, 128 GM instruments, vcsl samples), effects, patterns, tips (tempo, common mistakes), advanced (samples, wavetables, signals, chord voicings). Visuals: visuals (draw methods, presets, themes), hydra (shader backgrounds, H(pattern), the audio-reactive a.fft). Optional modules — the code is real browser JavaScript: stage (your own canvases, onFrame/onEvent/onTap, say), film (scenes on bars, text, narration), interactive (taps into notes, faders/pads/xy, tilt/mic, remember() for controls you draw, live sessions), craft (what makes a piece land), debugging (what the player reports back), gallery (complete pieces; fetch one with piece).
| Name | Required | Description | Default |
|---|---|---|---|
| piece | No | With topic 'gallery': the complete code of one piece (the index lists them). | |
| topic | Yes | Reference topic. Start with 'genres' for working templates, 'sounds' for instruments, 'visuals' for draw methods and presets, 'hydra' for shader backgrounds, 'advanced' for sample loading. For a music video or film: 'craft', 'stage', 'film', then gallery piece 'first-light'. For taps, controls, a drawn grid or a jam: 'interactive' alone (take only the sections you need), then gallery piece 'weather-machine' or 'trade-a-beat'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds that the returned material is 'real browser JavaScript' with runnable templates and that gallery pieces are complete code, which is useful context about output nature, but it says nothing about response size, format, or truncation for a guide with 15 topics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose is front-loaded in the first clause, and every parenthetical enumerates content that maps to a real enum value rather than being filler. The nested parentheticals get dense, but no sentence is redundant with the others.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only reference tool with 100% schema coverage and no output schema, the description tells the agent what each of the 15 topics yields, which is the information needed to pick a topic. Only the return format (markdown? code blocks?) is unstated, a minor gap for a documentation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and both parameters are enums with their own schema descriptions, so the schema already carries the semantics. The description reinforces the `piece` linkage to the gallery topic ('gallery (complete pieces; fetch one with `piece`)') but adds no syntax or format detail beyond the schema — the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening line states a specific resource ('Reference and recipes for Strudel live coding') and the body enumerates exactly what the guide covers (mini-notation, sounds, effects, visuals, hydra, stage, film, etc.), so the agent knows this is a documentation/content-retrieval tool. It never distinguishes itself from the sibling get-music-guide or search-music-docs, which is the only thing keeping it from a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by listing topics and noting 'fetch one with `piece`', but never states when to call this instead of get-music-guide or search-music-docs. The genuinely useful routing advice ('Start with genres...', 'For a music video or film: craft, stage, film') lives in the topic schema description, not in the tool description, so the description itself only implies the workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Live-code music in Strudel (TidalCycles mini-notation in JavaScript) and play it in a player the user can edit. Layer drums, bass and melody with stack(): 71 drum-machine banks, 128 GM instruments, synths and a full effects chain. Add .pianoroll() for a live piano roll (or .punchcard()/.scope()/.spectrum(), one per pattern), pass visuals for a ready-made animation and theme for the editor colours. Each call creates a NEW player. Optional, when you want more (get-strudel-guide topic in brackets): shader backgrounds that follow the music — start with await initHydra(), lock to the beat with H(pattern), react to the sound with () => a.fft[0] ('hydra'); canvases, scenes and spoken lines for music videos and films ('stage', 'film'); taps, faders, pads and controls you draw, played by the user; tilt and mic, which follow the phone on the browser player (a chat's frame usually blocks them) ('interactive'); complete pieces ('gallery'). To jam back and forth, or to change a piece while it plays, pass session: true, then use update-session and get-session.
The Strudel REPL renders inline with an editable code editor, visualizations, and playback controls.
| Name | Required | Description | Default |
|---|---|---|---|
| bpm | No | Tempo in BPM (40-300). Converts to setcps() automatically. | |
| code | Yes | Strudel pattern code. Uses TidalCycles mini-notation in JavaScript. Use stack() to layer drums, bass, and melody. Set tempo with setcps(bpm/60/4) or use the bpm parameter. The REPL plays the LAST expression: setup lines (await initHydra(), all(), setcps()) go BEFORE the pattern. Double quotes are mini-notation — use single quotes for plain strings and URLs. One draw method per pattern; pass a.fft values as functions (() => a.fft[0]). | |
| theme | No | Editor colour scheme. It also sets the ground the visuals sit on, so pick a dark one when the visual is the point (e.g. 'nord', 'sonicPink', 'tokyoNight'). | |
| title | No | Pattern title displayed in the widget header (e.g. 'Midnight Rain'). | |
| session | No | Optional: keep this player open as a live session. update-session then swaps new code in on the bar, and get-session reports what played and what the user did. For a jam, or a piece you change while it plays. Give the user something to play — taps, a fader, a grid (topic 'interactive') — or they answer by editing the code and pressing Pass. The log is kept until 2 hours idle. | |
| visuals | No | A ready-made visual for code that has none of its own: pianoroll, punchcard, scope or spectrum (drawn behind the code), or hydra-kaleid, hydra-pulse, hydra-wash or hydra-feed (shader backgrounds). It only fills a layer the code leaves empty, and shaders are skipped for viewers who prefer reduced motion. Your own visual is the better result (topics 'visuals' and 'hydra'). | |
| autoplay | No | Start playing immediately (default: true). May require user click due to browser autoplay policy. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnly, non-destructive, not idempotent), and the description adds substantial behavioral context beyond them: each call creates a NEW player, session logs persist until 2 hours idle, autoplay may need a user click, shaders are skipped for reduced-motion viewers, and `visuals` only fills an empty layer. This is exactly the extra context annotations cannot carry.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core action and the mechanism, then organized by optional capability with guide topics in brackets — an efficient structure. It is dense and occasionally list-like ('71 drum-machine banks, 128 GM instruments'), but almost every clause carries usable information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex 7-parameter tool with no output schema, the description covers the essential surface: what renders (inline REPL with editor, visuals, controls), the session lifecycle, and where to look for advanced topics. Nothing an agent needs to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3, but the description adds real meaning beyond it: theme 'sets the ground the visuals sit on, so pick a dark one', visuals 'only fills a layer the code leaves empty', and session's bar-synced swap and idle-log retention. The `code` parameter guidance (quotes vs mini-notation, draw-method limits) also reinforces the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: live-coding Strudel music and playing it in an editable player, with detail on layering drums/bass/melody via stack(). It is clearly distinguishable from siblings like play-sheet-music or convert-abc-to-strudel, and even describes the rendered REPL widget.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Rich routing guidance: it explains when to pass `visuals`, `theme`, and `session: true`, and explicitly names the follow-up flow (update-session / get-session) plus the get-strudel-guide topics for extensions. It does not explicitly say when to choose a different sibling tool (e.g., play-sheet-music), so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Write a score in ABC notation and play it as sheet music: a melody, a harmonized piece, a multi-voice arrangement or a well-known tune, on any of the 128 General MIDI instruments. Put chord symbols above the notes and add a style (rock, jazz, bossa, waltz, folk...) for drums, bass and chords. The user can edit the score in the player, change its style and instrument, and download WAV or MIDI. The result confirms the parse; it returns no audio. Start with get-music-guide topic 'genres'; 'abc-syntax' and 'instruments' for the rest.
The music player renders inline with interactive playback controls.
| Name | Required | Description | Default |
|---|---|---|---|
| style | No | Accompaniment style. Adds drums, bass, and chord patterns automatically. Your ABC needs chord symbols ("C", "Am") for accompaniment to work. Options: rock, jazz, bossa, waltz, march, reggae, folk, classical. | |
| swing | No | Swing as the share of the beat given to its first half. 50 = straight, 60 ≈ 3:2, 66 = triplet swing, 75 = maximum (dotted eighth + sixteenth). Anything at or below 50 is treated as no swing. Only takes effect in an x/4 or x/8 meter. | |
| tempo | No | Tempo in BPM (40-240). Overrides Q: in ABC notation. | |
| title | No | Piece title (overrides T: in ABC). Shown in the widget header and used as the filename stem for the WAV/MIDI downloads. | |
| drumIntro | No | Bars of count-in before the melody starts (0-8). Needs a style preset — the count-in is played by that style's drum kit, so without a style you get silent bars instead. | |
| transpose | No | Transpose by semitones (-12 to 12). Positive=higher, negative=lower. Rewrites the notation and the key signature, so the printed score matches what plays. | |
| instrument | No | Default instrument for the main voice — any of the 128 General MIDI names (e.g. 'Flute', 'Cello', 'Banjo', 'Alto Sax'). Matching is fuzzy and picks the lowest GM program among the hits, so 'sax' gives Soprano Sax; the result text names what you actually got whenever it isn't what you asked for. Use get-music-guide with topic 'instruments' for the full list, or %%MIDI program N in the ABC to set a program per voice. | |
| abcNotation | No | ABC notation string. Include chord symbols ("C", "Am7") above notes for auto-accompaniment with style presets. | X:1 T:Twinkle, Twinkle Little Star M:4/4 L:1/4 K:C C C G G | A A G2 | F F E E | D D C2 | G G F F | E E D2 | G G F F | E E D2 | C C G G | A A G2 | F F E E | D D C2 | |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds genuinely useful behavior beyond that: the result only confirms the parse and returns no audio, the player renders inline with interactive controls, and the user can edit style/instrument and export WAV or MIDI. It does not describe size limits or parse-failure behavior, which is a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose is front-loaded in the first sentence and the rest is compact. There is mild redundancy between 'The user can edit the score in the player' and 'The music player renders inline with interactive playback controls', which could be merged, but nothing is seriously wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description correctly carries the return-value burden by stating the result confirms the parse and returns no audio. It also covers the accompanying guide tools. It could be slightly more explicit about what a successful parse result contains, but it is complete enough for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter is already documented in the schema, including style enums, swing semantics, tempo override, transpose key rewriting, and drumIntro's style dependency. The description mostly restates this ('add a style for drums, bass and chords', 'chord symbols above the notes') and adds no new parameter-level detail beyond pointing at get-music-guide, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource ('Write a score in ABC notation and play it as sheet music') and enumerates the supported shapes (melody, harmonized piece, multi-voice arrangement, well-known tune). It clearly separates this tool from siblings like convert-abc-to-strudel and play-live-pattern, which produce different outputs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit onboarding routing: 'Start with get-music-guide topic genres; abc-syntax and instruments for the rest', and it states the user can edit and download afterward. It does not, however, say when to prefer this over play-live-pattern or convert-abc-to-strudel, so the alternative-selection guidance is incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search detailed documentation for Strudel live coding or ABC/ABCJS notation. Returns relevant code examples and explanations from the official docs. Use this when the curated guides (get-strudel-guide, get-music-guide) don't cover what you need — for specific functions, advanced techniques, or when you're unsure about syntax. Powered by semantic search over strudel.cc and ABCJS docs.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | What you want to know. Be specific. Good: 'how to use FM synthesis with envelope' or 'chop and slice sample manipulation'. Bad: 'effects' or 'help'. | |
| library | No | Which library to search: 'strudel' for live coding patterns, 'abcjs' for sheet music notation. | strudel |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains that the tool returns relevant code examples and explanations, and annotations cover read-only and open-world behavior. There is no contradiction, though it could add a bit more detail about result limits or whether results are pulled live from docs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, well-organized, and front-loads the main purpose, then provides usage context and parameter guidance without unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description gives enough context about what the tool returns and when to use it. With no output schema, the stated return type of examples and explanations is sufficient for an agent to understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The query parameter includes concrete good and bad examples, and the library parameter clearly explains the two enum choices and defaults. This adds strong meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches documentation for Strudel or ABC/ABCJS notation and returns examples and explanations. It is specific about the resource and distinguishes itself from the curated guide tools listed as siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use this tool when the curated guides (get-strudel-guide, get-music-guide) do not cover the need. It also mentions the library options, giving clear selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Only for a live session. Swaps new code into the session's player while the music keeps playing. Send the WHOLE pattern, as for play-live-pattern. It lands on the next bar (quantize 1, the default), the next multiple of n bars, or at once (0): set quantize to your phrase length (8-bar phrase → 8). If the player answers within a few seconds, the result says whether it ran the code, or its error. To change a piece's remember() state, ship a merge, not a new start value (get-strudel-guide topic 'interactive').
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | The complete new Strudel pattern (same rules as play-live-pattern's code). | |
| session | Yes | The session id from play-live-pattern's result (16 lowercase letters/digits). | |
| quantize | No | Land on the next multiple of this many cycles (bars). 1 = next bar (default), 4/8 = phrase, 0 = now. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare non-readonly, non-destructive, non-idempotent, but the description adds real behavior: playback continues uninterrupted, code lands on a quantized boundary, and the result may report success or a code error only if the player responds within a few seconds. It also discloses the merge semantics needed to change remember() state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Five dense sentences, front-loaded with the live-session constraint and the core action; every sentence carries operational information. Slightly long sentences, but nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description still explains what the result reports and its timing caveat, plus session-id provenance from play-live-pattern. An agent has everything needed to call this correctly in the live-session workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 a heuristic the schema lacks: set quantize to the phrase length (8-bar phrase → 8) and that 1 is the next bar. It also reinforces that code must be the WHOLE pattern, matching play-live-pattern's rules.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: it swaps new code into a live session's player without stopping playback. The opening constraint 'Only for a live session' immediately separates it from play-live-pattern, which starts a session rather than updating one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit preconditions (live session only), routes the agent to play-live-pattern for the code rules, specifies how to pick quantize (phrase length, 0 for immediate), and names get-strudel-guide topic 'interactive' for the merge-not-new-start case. Both alternatives and when-not conditions are covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get-strudel-guide1 field changedInput schema / properties / piece / enumPrevious value: -[
- "first-light",
- "duet",
- "petri-dish",
- "lossy-terminal",
- "signal-corruption",
- "weather-machine",
- "two-decks",
- "trade-a-beat"
-]New value: +[
+ "first-light",
+ "duet",
+ "petri-dish",
+ "lossy-terminal",
+ "signal-corruption",
+ "weather-machine",
+ "two-decks",
+ "trade-a-beat",
+ "still-water",
+ "lullaby"
+]create-share-link17 fields changedInput schema / properties / pattern / descriptionAdded value: +"The arguments you gave play-live-pattern (theme and session are not carried)."Input schema / properties / pattern / properties / autoplay / descriptionRemoved value: -"Start playing immediately (default: true). May require user click due to browser autoplay policy."Input schema / properties / pattern / properties / bpm / descriptionRemoved value: -"Tempo in BPM (40-300). Converts to setcps() automatically."Input schema / properties / pattern / properties / code / descriptionPrevious value: -"Strudel pattern code. Uses TidalCycles mini-notation in JavaScript. Use stack() to layer drums, bass, and melody. Set tempo with setcps(bpm/60/4) or use the bpm parameter. The REPL plays the LAST expression: setup lines (await initHydra(), all(), setcps()) go BEFORE the pattern. Double quotes are mini-notation — use single quotes for plain strings and URLs. One draw method per pattern; pass a.fft values as functions (() => a.fft[0])."New value: +"The Strudel code, as for play-live-pattern."Input schema / properties / pattern / properties / sessionRemoved value: -{
- "description": "Open a LIVE SESSION: this player stays open as one performance. update-session swaps in new code on the next bar without a new player and says whether it ran; get-session reads the player's runtime reports and what the user did (taps, code edits, handing you the turn). Use it to iterate on a long piece, to check that a piece really played, or to jam back-to-back. Its log (reports, taps, edits, your updates) is kept on the server until 2 hours idle.",
- "type": "boolean"
-}Input schema / properties / pattern / properties / themeRemoved value: -{
- "description": "Editor colour theme; the visuals stage and its readability scrim are derived from it, so it also decides whether a shader sits on a dark or light ground — prefer a dark one when the visual is the point (e.g. 'nord', 'sonicPink', 'tokyoNight'). Not carried into share links or the browser fallback.",
- "enum": [
- "strudelTheme",
- "algoboy",
- "archBtw",
- "androidstudio",
- "atomone",
- "aura",
- "bbedit",
- "blackscreen",
- "bluescreen",
- "bluescreenlight",
- "CutiePi",
- "darcula",
- "dracula",
- "duotoneDark",
- "eclipse",
- "fruitDaw",
- "githubDark",
- "githubLight",
- "greenText",
- "gruvboxDark",
- "gruvboxLight",
- "sonicPink",
- "materialDark",
- "materialLight",
- "monokai",
- "noctisLilac",
- "nord",
- "redText",
- "solarizedDark",
- "solarizedLight",
- "sublime",
- "teletext",
- "tokyoNight",
- "tokyoNightDay",
- "tokyoNightStorm",
- "vscodeDark",
- "vscodeLight",
- "whitescreen",
- "xcodeLight"
- ],
- "type": "string"
-}Input schema / properties / pattern / properties / title / descriptionRemoved value: -"Pattern title displayed in the widget header (e.g. 'Midnight Rain')."Input schema / properties / pattern / properties / visuals / descriptionRemoved value: -"Ready-made visual, for when the code has none of its own. pianoroll/punchcard/scope/spectrum draw onto the 2D canvas behind the code; hydra-kaleid (rotating kaleidoscope), hydra-pulse (shape driven by a rhythm), hydra-wash (slow ambient noise) and hydra-feed (the piano roll mirrored and trailed) are WebGL shader backgrounds. A preset fills the MISSING layer: a hydra preset is skipped only if the code already calls initHydra(), a 2D preset only if the code already has a draw method — so hydra-wash layers happily under your own .pianoroll(). Hydra presets are dropped for viewers who prefer reduced motion. Writing your own visual is still the better result (draw methods: topic 'visuals'; shaders: topic 'hydra')."Input schema / properties / score / descriptionAdded value: +"The arguments you gave play-sheet-music."Input schema / properties / score / properties / abcNotation / descriptionAdded value: +"The ABC notation, as for play-sheet-music."Input schema / properties / score / properties / drumIntro / descriptionRemoved value: -"Bars of count-in before the melody starts (0-8). Needs a style preset — the count-in is played by that style's drum kit, so without a style you get silent bars instead."Input schema / properties / score / properties / instrument / descriptionPrevious value: -"Default instrument for the main voice — any of the 128 General MIDI names (e.g. 'Flute', 'Cello', 'Banjo', 'Alto Sax'). Matching is fuzzy and picks the lowest GM program among the hits, so 'sax' gives Soprano Sax; the result text names what you actually got whenever it isn't what you asked for. Use get-music-guide with topic 'instruments' for the full list, or %%MIDI program N in the ABC to set a program per voice."New value: +"General MIDI instrument name, as for play-sheet-music."Input schema / properties / score / properties / style / descriptionRemoved value: -"Accompaniment style. Adds drums, bass, and chord patterns automatically. Your ABC needs chord symbols (\"C\", \"Am\") for accompaniment to work. Options: rock, jazz, bossa, waltz, march, reggae, folk, classical."Input schema / properties / score / properties / swing / descriptionRemoved value: -"Swing as the share of the beat given to its first half. 50 = straight, 60 ≈ 3:2, 66 = triplet swing, 75 = maximum (dotted eighth + sixteenth). Anything at or below 50 is treated as no swing. Only takes effect in an x/4 or x/8 meter."Input schema / properties / score / properties / tempo / descriptionRemoved value: -"Tempo in BPM (40-240). Overrides Q: in ABC notation."Input schema / properties / score / properties / title / descriptionRemoved value: -"Piece title (overrides T: in ABC). Shown in the widget header and used as the filename stem for the WAV/MIDI downloads."Input schema / properties / score / properties / transpose / descriptionRemoved value: -"Transpose by semitones (-12 to 12). Positive=higher, negative=lower. Rewrites the notation and the key signature, so the printed score matches what plays."get-session1 field changedInput schema / properties / wait / descriptionPrevious value: -"Listen instead of just reading: 'pass' holds until the listener presses Pass, 'activity' until they play (a few seconds after their first move). Returns at once if that already happened since your last read, and after ~40 s if not — call again to keep listening. Lets you stay in the booth for a whole set."New value: +"Listen instead of just reading: 'pass' until the listener presses Pass, 'activity' until they play. Returns at once if that already happened since your last read, else after ~40 s — call again to keep listening."get-strudel-guide1 field changedInput schema / properties / topic / descriptionPrevious value: -"Reference topic. Start with 'genres' for working templates, 'sounds' for instruments, 'visuals' for draw methods and presets, 'hydra' for shader backgrounds, 'advanced' for sample loading. For a music video, film or interactive piece: 'craft', then 'stage', 'film' or 'interactive', and a worked example from 'gallery'."New value: +"Reference topic. Start with 'genres' for working templates, 'sounds' for instruments, 'visuals' for draw methods and presets, 'hydra' for shader backgrounds, 'advanced' for sample loading. For a music video or film: 'craft', 'stage', 'film', then gallery piece 'first-light'. For taps, controls, a drawn grid or a jam: 'interactive' alone (take only the sections you need), then gallery piece 'weather-machine' or 'trade-a-beat'."play-live-pattern3 fields changedInput schema / properties / session / descriptionPrevious value: -"Open a LIVE SESSION: this player stays open as one performance. update-session swaps in new code on the next bar without a new player and says whether it ran; get-session reads the player's runtime reports and what the user did (taps, code edits, handing you the turn). Use it to iterate on a long piece, to check that a piece really played, or to jam back-to-back. Its log (reports, taps, edits, your updates) is kept on the server until 2 hours idle."New value: +"Optional: keep this player open as a live session. update-session then swaps new code in on the bar, and get-session reports what played and what the user did. For a jam, or a piece you change while it plays. Give the user something to play — taps, a fader, a grid (topic 'interactive') — or they answer by editing the code and pressing Pass. The log is kept until 2 hours idle."Input schema / properties / theme / descriptionPrevious value: -"Editor colour theme; the visuals stage and its readability scrim are derived from it, so it also decides whether a shader sits on a dark or light ground — prefer a dark one when the visual is the point (e.g. 'nord', 'sonicPink', 'tokyoNight'). Not carried into share links or the browser fallback."New value: +"Editor colour scheme. It also sets the ground the visuals sit on, so pick a dark one when the visual is the point (e.g. 'nord', 'sonicPink', 'tokyoNight')."Input schema / properties / visuals / descriptionPrevious value: -"Ready-made visual, for when the code has none of its own. pianoroll/punchcard/scope/spectrum draw onto the 2D canvas behind the code; hydra-kaleid (rotating kaleidoscope), hydra-pulse (shape driven by a rhythm), hydra-wash (slow ambient noise) and hydra-feed (the piano roll mirrored and trailed) are WebGL shader backgrounds. A preset fills the MISSING layer: a hydra preset is skipped only if the code already calls initHydra(), a 2D preset only if the code already has a draw method — so hydra-wash layers happily under your own .pianoroll(). Hydra presets are dropped for viewers who prefer reduced motion. Writing your own visual is still the better result (draw methods: topic 'visuals'; shaders: topic 'hydra')."New value: +"A ready-made visual for code that has none of its own: pianoroll, punchcard, scope or spectrum (drawn behind the code), or hydra-kaleid, hydra-pulse, hydra-wash or hydra-feed (shader backgrounds). It only fills a layer the code leaves empty, and shaders are skipped for viewers who prefer reduced motion. Your own visual is the better result (topics 'visuals' and 'hydra')."get-strudel-guide1 field changedInput schema / properties / piece / enumPrevious value: -[
- "first-light",
- "duet",
- "petri-dish",
- "lossy-terminal",
- "signal-corruption",
- "weather-machine",
- "two-decks"
-]New value: +[
+ "first-light",
+ "duet",
+ "petri-dish",
+ "lossy-terminal",
+ "signal-corruption",
+ "weather-machine",
+ "two-decks",
+ "trade-a-beat"
+]get-strudel-guide1 field changedInput schema / properties / piece / enumPrevious value: -[
- "first-light",
- "duet",
- "petri-dish",
- "lossy-terminal",
- "signal-corruption",
- "weather-machine"
-]New value: +[
+ "first-light",
+ "duet",
+ "petri-dish",
+ "lossy-terminal",
+ "signal-corruption",
+ "weather-machine",
+ "two-decks"
+]create-share-link1 field changedInput schema / properties / pattern / properties / sessionAdded value: +{
+ "description": "Open a LIVE SESSION: this player stays open as one performance. update-session swaps in new code on the next bar without a new player and says whether it ran; get-session reads the player's runtime reports and what the user did (taps, code edits, handing you the turn). Use it to iterate on a long piece, to check that a piece really played, or to jam back-to-back. Its log (reports, taps, edits, your updates) is kept on the server until 2 hours idle.",
+ "type": "boolean"
+}get-sessionget-strudel-guide1 field changedInput schema / properties / piece / enumPrevious value: -[
- "first-light",
- "duet",
- "petri-dish",
- "lossy-terminal",
- "signal-corruption"
-]New value: +[
+ "first-light",
+ "duet",
+ "petri-dish",
+ "lossy-terminal",
+ "signal-corruption",
+ "weather-machine"
+]play-live-pattern1 field changedInput schema / properties / sessionAdded value: +{
+ "description": "Open a LIVE SESSION: this player stays open as one performance. update-session swaps in new code on the next bar without a new player and says whether it ran; get-session reads the player's runtime reports and what the user did (taps, code edits, handing you the turn). Use it to iterate on a long piece, to check that a piece really played, or to jam back-to-back. Its log (reports, taps, edits, your updates) is kept on the server until 2 hours idle.",
+ "type": "boolean"
+}update-sessionget-strudel-guide3 fields changedInput schema / properties / pieceAdded value: +{
+ "description": "With topic 'gallery': the complete code of one piece (the index lists them).",
+ "enum": [
+ "first-light",
+ "duet",
+ "petri-dish",
+ "lossy-terminal",
+ "signal-corruption"
+ ],
+ "type": "string"
+}Input schema / properties / topic / descriptionPrevious value: -"Reference topic. Start with 'genres' for working templates, 'sounds' for instruments, 'visuals' for draw methods and presets, 'hydra' for shader backgrounds, 'advanced' for sample loading."New value: +"Reference topic. Start with 'genres' for working templates, 'sounds' for instruments, 'visuals' for draw methods and presets, 'hydra' for shader backgrounds, 'advanced' for sample loading. For a music video, film or interactive piece: 'craft', then 'stage', 'film' or 'interactive', and a worked example from 'gallery'."Input schema / properties / topic / enumPrevious value: -[
- "mini-notation",
- "sounds",
- "effects",
- "patterns",
- "genres",
- "tips",
- "visuals",
- "hydra",
- "advanced"
-]New value: +[
+ "mini-notation",
+ "sounds",
+ "effects",
+ "patterns",
+ "genres",
+ "tips",
+ "visuals",
+ "hydra",
+ "advanced",
+ "stage",
+ "film",
+ "interactive",
+ "craft",
+ "debugging",
+ "gallery"
+]analyze-harmony1 field changedInput schema / properties / task / descriptionPrevious value: -"What to work out. detect-chord/detect-key need notes or chords; suggest-progression/key-chords need a key."New value: +"What to work out. detect-chord needs notes; detect-key needs notes or chords; scale-for-chord needs chords; suggest-progression/key-chords need a key."create-share-linkTurn recordings, videos and sheet music into playable, editable scores. Transcribe audio or video (files or links) to sheet music, read sheet-music photos and PDFs, convert MIDI, MusicXML and ABC, edit notes in conversation with previews and undo, and export PDF, MIDI, MusicXML, guitar TAB, jianpu and audio. Hosted remote server with OAuth sign-in; one instrument, voice or solo piano is free.
Create, co-edit, analyze, publish, and export collaborative step-sequencer sessions through MCP.
Write, edit, transpose and play guitar tabs and staff notation in Cesure.
Deterministic music theory for agents: analyze, voice, reharmonize, conduct — computed, not guessed
Add one secure layer between your agents and this server.
