ABC sheet music + Strudel live coding studio with ext-apps widgets, harmony tools, and share links.
Scored across 8 tools
Each tool has a clear distinct purpose: theory, conversion, sharing, two reference guides, live performance, sheet music, and search. However, get-music-guide and get-strudel-guide could be confused as both are reference material, though they target different domains (ABC/composition vs. Strudel live coding).
All tool names follow a consistent verb_noun pattern in snake_case (e.g., analyze-harmony, create-share-link, play-live-pattern). The verbs are diverse but the structure is uniform and predictable.
8 tools is well-scoped for a music studio server, covering composition, live coding, theory, conversion, sharing, and reference material. Each tool serves a distinct purpose and fits within the ideal 3-15 range.
The tool surface covers core workflows: composing, live-coding, harmonic analysis, format conversion, sharing, and reference lookup. Minor gaps include lack of explicit audio export or advanced editing tools, but these are not critical for the intended scope.
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.
Returns detailed reference material for music composition. Topics: instruments (GM instrument list + combos), drums (patterns + percussion notes), abc-syntax (notation reference), arrangements (multi-voice patterns), genres (complete ABC templates for jazz/blues/folk/rock/bossa/classical), styles (what each style preset does), 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=true, idempotentHint=true, destructiveHint=false. Description adds no additional behavioral traits beyond topic content, so it meets baseline without contradiction.
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?
Single sentence front-loads purpose and efficiently lists topics, though slightly dense; no wasted words.
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?
Covers all topics adequately and provides context for output; missing explicit return format, but acceptable for a reference tool with simple input.
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 100% with enum and description; description adds usage hints (starting points) that enhance understanding beyond schema alone.
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 it returns detailed reference material for music composition, listing specific topics. Sibling tools like 'play-live-pattern' and 'search-music-docs' are distinct, making purpose unambiguous.
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 starting suggestions ('Start with genres, styles, or instruments'), but does not explicitly contrast with sibling 'get-strudel-guide' or state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reference material for Strudel live coding (performance mode). Topics: mini-notation (pattern syntax), sounds (synths, 71 drum banks, 128 GM instruments, 128 vcsl orchestral/percussion samples), effects (filters, reverb, delay, FM synthesis, envelopes), patterns (transformations, probability, euclidean, arrangement), genres (complete templates: techno/house/dnb/ambient/jazz/lofi/synthwave), tips (tempo, common mistakes, ABC↔Strudel crossover), visuals (pianoroll/scope draw methods, the visuals presets and the theme parameter), hydra (WebGL shader backgrounds: initHydra, H(pattern), the audio-reactive a.fft object, recipes, cheat-sheet), advanced (sample loading, wavetables, ZZFX, continuous signals, chord voicings).
| Name | Required | Description | Default |
|---|---|---|---|
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description's 'Reference material' framing is consistent with that safety profile. The description adds topic scope but does not disclose additional behavioral traits such as output format or retrieval behavior.
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 a single dense sentence but is front-loaded with the core purpose and organized by clear topic categories. It is long yet each parenthetical adds value; bullet formatting could improve scannability, but there is no wasted text.
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, one-parameter reference tool with 100% schema coverage and strong annotations, the description covers the complete topic surface and provides enough context to invoke the tool correctly. No essential guidance appears to be 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%, and the single required topic parameter has an enum with descriptive starting points for genres, sounds, visuals, hydra, and advanced. The description's long topic list reinforces but does not add meaning beyond the schema, so 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 description opens with a specific resource and scope: 'Reference material for Strudel live coding (performance mode).' It then enumerates all topic areas, making it unmistakably distinct from broader siblings like get-music-guide and search-music-docs.
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 schema's enum description offers starting-point guidance (e.g., 'Start with genres for working templates'), but the tool description itself does not explicitly say when to use this tool versus siblings such as search-music-docs or get-music-guide. Usage context is implied rather than stated with exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Live-code music patterns using TidalCycles mini-notation in JavaScript. Layer drums, synths, and bass with stack(). Choose from 71 drum machine banks, 128 GM instruments, built-in synths, and a full effects chain. Patterns play in a REPL the user can edit directly. Add .pianoroll() to a pattern to show a live piano-roll animation in the widget (or .punchcard()/.scope()/.spectrum() — one draw method per pattern). For a custom animated background, start the code with await initHydra() and write Hydra shader code — H(pattern) locks it to the sequence, and () => a.fft[0] makes it react to the audio itself (Strudel's output, not the mic); see get-strudel-guide topic 'hydra'. Rather not hand-write one? visuals picks a ready-made animation for code that has none (pianoroll/punchcard/scope/spectrum, or hydra-kaleid/pulse/wash/feed). theme sets the code-editor colour scheme, which also tints the visuals — match it to the mood (teletext chiptune, sonicPink synthwave, nord ambient, gruvboxDark lofi). Each call creates a NEW player rather than updating the last one — for a tweak, send the whole revised pattern and ask the user to stop the previous one. Use get-strudel-guide for genre templates, sound references, and advanced features like arrangement and sample loading.
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 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. | |
| title | No | Pattern title displayed in the widget header (e.g. 'Midnight Rain'). | |
| visuals | No | 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'). | |
| 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?
Discloses key behavioral aspects: autoplay may require user click, each call spawns a new player (not updating the last), and visuals are skipped under certain conditions (e.g., hydra presets for reduced motion). It does not explicitly mention read-only or side-effect status, but the new-player note gives useful transparency. No contradiction with annotations detected.
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 long but well-structured, covering all necessary aspects without redundancy. It is information-dense, but some sentences are lengthy and could be broken down for easier scanning. However, the level of detail is appropriate given the tool's complexity, and the structure flows logically.
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?
Despite lacking an output schema, the description explains what the REPL returns to the user (inline editor, visualizations, playback controls) and sets expectations about player creation and theming. It also references companion tools for further guidance, giving a complete picture of how the tool fits into the broader ecosystem.
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 schema already describes parameters well, and the description adds substantial extra meaning: explains bpm conversion to setcps(), provides detailed notes on code syntax (double vs single quotes, last expression rule, draw method limits), clarifies theme impact on visuals, and elaborates on each visual preset's behavior (what gets skipped, layering). This goes far beyond 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 clearly states the tool's primary function: live-coding music patterns with Strudel/TidalCycles mini-notation. It enumerates key features (layering, visuals, themes, REPL behavior) and distinguishes itself from siblings like play-sheet-music and convert-abc-to-strudel by focusing on interactive performance.
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 practical usage guidance: explains the REPL's last-expression behavior, notes that each call creates a new player (with a recommendation to send revised code and ask user to stop previous), and directs users to get-strudel-guide for advanced features. However, it does not explicitly contrast when to use this tool versus convert-abc-to-strudel or play-sheet-music, leaving room for ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compose and play sheet music with visual notation, multi-instrument audio, and style presets. Write ABC notation for melodies, arrangements, harmonized pieces, or well-known tunes. Add a style (rock, jazz, bossa, waltz, folk...) for automatic drums, bass, and chord accompaniment. Returns a parse-status confirmation and renders the player; it does not return raw audio. Use get-music-guide for genre templates, instrument lists, and ABC syntax reference.
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?
Beyond the readOnly hint, the description discloses several behaviors: it rewrites notation and key signature on transpose, uses fuzzy matching for instrument selection and names the actual result, and explains that drumIntro produces silent bars without a style. It also clarifies that it returns a parse confirmation and renders inline, not raw audio.
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 structured into two clear paragraphs and covers key functionality without being excessively verbose. It includes some redundancy (e.g., 'renders the player' and 'renders inline with interactive playback controls') but remains readable and informative.
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 explains the return value (parse confirmation and inline player) and explicitly states that it does not return raw audio, which is critical for expectation setting. It also points to get-music-guide for reference and covers all parameters via the schema, so the context is largely complete. It does not mention error conditions or edge cases, but that is not critical for this 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?
The schema already provides 100% coverage with detailed descriptions for all 8 parameters, including defaults, ranges, and functional notes (e.g., style needing chord symbols). The tool description does not add significant additional parameter-specific semantics beyond what is in the schema, so a baseline score of 3 is appropriate.
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 that the tool composes and plays sheet music from ABC notation, with visual notation, multi-instrument audio, and style presets. It also specifies the output behavior (parse confirmation and inline player) and explicitly notes it does not return raw audio, distinguishing it from audio-returning tools.
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 gives explicit guidance to use get-music-guide for genre templates, instrument lists, and ABC syntax reference, indicating when not to use this tool for reference. It does not contrast with all sibling tools (e.g., play-live-pattern) but the detailed functionality and note about not returning raw audio provide sufficient context.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
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-linkget-strudel-guide2 fields changedInput schema / properties / topic / descriptionPrevious value: -"Reference topic. Start with 'genres' for working templates, 'sounds' for instruments, 'visuals' for animations and Hydra 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."Input schema / properties / topic / enumPrevious value: -[
- "mini-notation",
- "sounds",
- "effects",
- "patterns",
- "genres",
- "tips",
- "visuals",
- "advanced"
-]New value: +[
+ "mini-notation",
+ "sounds",
+ "effects",
+ "patterns",
+ "genres",
+ "tips",
+ "visuals",
+ "hydra",
+ "advanced"
+]play-live-pattern3 fields changedInput schema / 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."New 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])."Input schema / properties / theme / descriptionPrevious value: -"Editor colour theme — pick to match the mood (e.g. 'nord', 'sonicPink', 'githubLight')."New 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."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. Ignored if the code already visualises itself — writing your own .pianoroll() or initHydra() shader is still the better result (see get-strudel-guide topic 'visuals')."New 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')."analyze-harmonyconvert-abc-to-strudelget-strudel-guide2 fields changedInput schema / properties / topic / descriptionPrevious value: -"Reference topic. Start with 'genres' for working templates, 'sounds' for instruments, 'advanced' for visualization and sample loading."New value: +"Reference topic. Start with 'genres' for working templates, 'sounds' for instruments, 'visuals' for animations and Hydra backgrounds, 'advanced' for sample loading."Input schema / properties / topic / enumPrevious value: -[
- "mini-notation",
- "sounds",
- "effects",
- "patterns",
- "genres",
- "tips",
- "advanced"
-]New value: +[
+ "mini-notation",
+ "sounds",
+ "effects",
+ "patterns",
+ "genres",
+ "tips",
+ "visuals",
+ "advanced"
+]play-live-pattern3 fields changedInput schema / properties / code / maxLengthAdded value: +65536Input schema / properties / themeAdded value: +{
+ "description": "Editor colour theme — pick to match the mood (e.g. 'nord', 'sonicPink', 'githubLight').",
+ "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 / visualsAdded value: +{
+ "description": "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. Ignored if the code already visualises itself — writing your own .pianoroll() or initHydra() shader is still the better result (see get-strudel-guide topic 'visuals').",
+ "enum": [
+ "none",
+ "pianoroll",
+ "punchcard",
+ "scope",
+ "spectrum",
+ "hydra-kaleid",
+ "hydra-pulse",
+ "hydra-wash",
+ "hydra-feed"
+ ],
+ "type": "string"
+}play-sheet-music8 fields changedInput schema / properties / abcNotation / maxLengthAdded value: +65536Input schema / properties / drumIntroAdded value: +{
+ "description": "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.",
+ "maximum": 8,
+ "minimum": 0,
+ "type": "integer"
+}Input schema / properties / instrument / descriptionPrevious value: -"Default instrument (e.g. 'Flute', 'Cello', 'Acoustic Grand Piano', 'Alto Sax'). Use get-music-guide with topic 'instruments' for the full list."New 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."Input schema / properties / swing / descriptionPrevious value: -"Swing percentage (0-100). 0=straight, 33=light swing, 66=heavy swing. Great for jazz and blues."New 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 / swing / maximumPrevious value: -100New value: +75Input schema / properties / title / descriptionPrevious value: -"Piece title (overrides T: in ABC). Displayed in the widget header."New 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 / transpose / descriptionPrevious value: -"Transpose by semitones (-12 to 12). Positive=higher, negative=lower."New 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."Input schema / properties / transpose / typePrevious value: -"number"New value: +"integer"search-music-docs1 field changedInput schema / properties / query / maxLengthAdded value: +500get-music-guideget-strudel-guideplay-live-patternplay-sheet-musicsearch-music-docsDeterministic music theory for agents: analyze, voice, reharmonize, conduct — computed, not guessed
Create, co-edit, analyze, publish, and export collaborative step-sequencer sessions through MCP.
Generate, edit and stream royalty-free music, or search a licensed catalogue.
Autonomous music production for AI agents with MIDI generation, QC and provenance.
Add one secure layer between your agents and this server.