ABC sheet music + Strudel live coding: songs, videos and live jam sessions in ext-apps widgets.
Scored across 10 tools
Each tool targets a distinct resource+action: harmony analysis, ABC->Strudel conversion, score playback, live-pattern playback, session read/update, share links, and docs. The only real overlap is the trio of documentation lookups (get-music-guide, get-strudel-guide, search-music-docs), which are separated only by domain and a 'use when the guides don't cover it' fallback rule. play-sheet-music vs play-live-pattern is clearly split by notation format, so misselection risk there is low.
Every tool follows the same kebab-case verb_noun pattern (analyze-, convert-, create-, get-, play-, search-, update-). The verbs are meaningful and predict the action. No camelCase or mixed-convention outliers.
Ten tools is a well-scoped surface for a music-creation server with two playback engines plus session, docs, and sharing support. Each tool maps to a distinct capability with no obvious filler.
The lifecycle is largely covered: analyze -> author (ABC or Strudel) -> convert -> play -> live-edit -> share, plus references. Minor gaps exist: no tool to list, revoke, or inspect existing share links, no explicit stop/teardown for a live session, and no way to ingest existing MIDI/audio files. These are workarounds rather than blockers.
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?
The annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered and the description is consistent with it. Beyond that it discloses the dual output contract (ABC chord-symbol spelling for play-sheet-music, Strudel form for play-live-pattern), which is genuinely useful behavior an agent would not know from annotations alone.
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 front-loaded with the overall purpose and then moves to a compact task list; almost every clause carries information, including the output-format and consumer notes. It is somewhat dense with arrow notation and parenthetical asides, but nothing is 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?
With no output schema, the description carries the burden of explaining returns, and it does reasonably well: it states the two output encodings and sketches what each task yields (chord name + what to play next, best key + diatonic chords, chord symbols, scales, full diatonic sets). Exact return field shapes and error behavior for invalid notes remain unspecified, which keeps it short of a 5.
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 all five parameters, the task enum, and the optional romanNumerals behavior are already documented in structured form. The description echoes that mapping ("detect-chord needs notes; suggest-progression/key-chords need a key") but adds no syntax, formatting, or edge-case detail beyond the schema, so the baseline of 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 concrete role ("Music theory helper: name a chord from notes, guess the key, get a progression, or list what fits a key") and then enumerates all five task modes with input -> output arrows, so an agent can match a user request to a mode without opening the schema. It also differentiates itself from siblings by naming the exact downstream consumers, play-sheet-music and play-live-pattern.
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 a clear usage context ("Use it before writing chord symbols for a style preset, or to check a harmonization") and per-task input prerequisites, which tells the agent when each mode applies. What it lacks is explicit when-not guidance or named alternatives for cases where another sibling (e.g. get-music-guide or search-music-docs) would be the better call.
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?
Goes well beyond the annotations (readOnly/idempotent/non-destructive already cover safety) by describing the exact output shape: setcps() from the Q: tempo, one [...] bar group per bar inside note("..."), and a chord("...").voicing() layer with a single stack() because 'Strudel plays only the last expression'. It also discloses transformation rules (@ weights, ~ for rests, nested triplets, key-signature folding, %%MIDI program) and enumerates what is lost (grace notes, dynamics, repeats, lyrics, other voices, inline tempo changes, short final bar, gchord/drum accompaniment).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the purpose and the return contract, and the dense lost-features list is genuinely informative rather than filler. It is a single long paragraph with heavy em-dash nesting, so scanning takes effort even though nearly every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, and the description compensates fully by specifying the generated code's structure, the required wrapper expression, and the fidelity losses an agent should warn about. Nothing needed to call it correctly or interpret its result is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3; the description still adds meaning by explaining the voice parameter's arrangement workflow (re-run per voice and stack() them) and by tying `sound` to the tune's %%MIDI program default. It does not restate parameter types or formats, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Turn an ABC melody into Strudel mini-notation') plus the downstream intent ('so a scored piece can be remixed live'). It is clearly distinguishable from siblings like play-sheet-music and play-live-pattern because it produces code rather than playing anything.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly routes the agent forward: the result is meant to be 'pass[ed] to play-live-pattern', and it explains the multi-voice workflow ('Pick a single voice with `voice`; re-run per voice and stack() them for a full arrangement'). It lacks an explicit when-not-to-use statement or a direct contrast with play-sheet-music, which is only hinted at in the abcNotation schema text.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 readOnly, idempotent, non-destructive, and closed-world, so the safety profile is fully covered. The description adds that content is static reference material (patterns, templates, GM lists) but says nothing about return format or size, which matters for a guide that returns lengthy notation snippets.
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 front-loaded sentence with a compact topic list; every clause earns its place by telling the agent what lives behind each enum value. No redundant restatement of the tool name or annotations.
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 single-parameter read-only lookup with no output schema, the description covers the full topic space and is sufficient to invoke correctly. The only real gap is not indicating output shape or rough length of the returned reference material.
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% and each enum value carries a short description, so the baseline is satisfied. The description goes beyond the enum names by explaining the substance of each topic (e.g., genres include a 3/4 minuet and lullaby, instruments include GM list plus combos), which helps the agent pick the right topic on the first call.
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-resource pair ('Reference for ABC sheet music') and enumerates the seven topic areas it covers. The agent knows this is a static knowledge lookup, though nothing in the text distinguishes it from siblings like get-strudel-guide or 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 parenthetical notes ('complete templates', 'what each accompaniment preset does') hint at what each topic is for, and the schema description advises starting with 'genres' or 'styles'. But the description itself gives no explicit when-to-use-this-vs-alternatives guidance, particularly against the sibling docs/search tools.
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 readOnlyHint=true and destructiveHint=false, so safety is covered; the description's real addition is that reads are cursor-like ('since your last read'), which explains the otherwise puzzling idempotentHint=false. It also discloses blocking behavior via wait: 'pass'. That said, those wait semantics are largely duplicated from the schema, so the value beyond structured data is moderate.
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 crucial constraint ('Only for a live session') and organized from purpose to return values to usage pattern. The final sentence is long and comma-chained, but every clause carries procedural information, so little 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?
There is no output schema, and the description compensates by enumerating exactly what a read yields: player state, played content, errors, silences, and human actions including taps, remember() changes, code execution, Pass and End. Combined with the blocking guidance and the ~40 s timeout carried in the schema, an agent has everything needed to call and interpret it.
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?
With 100% schema coverage the baseline is 3, and the description clears that by showing the parameters in action: wait: 'pass' is explained as listening until the human presses Pass so an entire exchange fits in one turn, plus a full call sequence (update-session, get-session(wait: 'pass'), answer, listen again). It does not add anything for the session id, which the schema already fully specifies.
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?
Names a specific verb (reads) and a scoped resource (a live session), then enumerates exactly what is returned: player up/down, what it played, errors, silences, and human actions since the last read. The opening line distinguishes it from the general session tooling by tying it to play-live-pattern's session flag.
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, session: true) and a concrete decision rule: 'Read it before assuming a piece played.' It also shows the intended call pattern with update-session for a back-and-forth loop. It stops short of naming alternatives for non-live inspection, but the exclusion is clear enough to route an agent.
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?
The annotations already establish that this is a read-only, idempotent, non-destructive, closed-world reference lookup. The description adds useful content-scope context, including that optional modules are real browser JavaScript and that gallery pieces are fetchable, but it does not describe response size, formatting, or freshness/versioning 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 opening sentence is front-loaded and the content is dense with specific, relevant examples rather than filler. However, the second sentence is a long, semicolon-heavy catalogue packed with nested parentheses, which reduces scanability and could be structured more cleanly.
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 two-parameter reference lookup with fully described enums and no output schema, the description gives a broad and useful inventory of available content. The main remaining gap is that it does not explicitly describe the returned format, such as reference text versus code snippets, but the purpose is otherwise adequately specified.
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 have enum values plus explanatory schema text. The description reinforces the topic taxonomy and mentions `piece` for gallery retrieval, but it adds little parameter meaning beyond the already strong schema documentation, so the 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 identifies this as a reference/recipe lookup for Strudel live coding and enumerates the covered domains, so an agent can tell it apart from action-oriented siblings like play-live-pattern or analyze-harmony. It does not explicitly differentiate itself from closely related reference/search siblings such as get-music-guide or 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 description implies usage by cataloguing available topics and noting that gallery pieces can be fetched with the `piece` parameter, but it gives no explicit when-to-use/when-not-to-use guidance relative to sibling tools. It also relies on the schema's topic guidance rather than the description itself to route topic selection.
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 already declare readOnly, non-destructive, non-idempotent and closed-world, so the safety profile is covered. The description adds genuinely useful behavioural facts beyond them: each call creates a NEW player, autoplay may be blocked by browser policy, visuals are skipped for reduced-motion viewers, the session log is kept until 2 hours idle, and phone tilt/mic are usually blocked in a chat frame. Residual tension: 'creates a NEW player' implies a state-creating side effect that sits awkwardly with readOnlyHint=true, but it is disclosed rather than hidden and no output/return shape is described.
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 core purpose is correctly front-loaded in sentence one, and the decisive sibling routing (session -> update-session/get-session) sits at the end where it is easy to find. However, the middle 'Optional, when you want more' sentence is a ~120-word packed enumeration of hydra/stage/film/interactive/gallery topics that is hard to parse and largely irrelevant to invoking the tool correctly, pushing length past what the task needs.
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 code-execution tool with 7 parameters, one required, no output schema and a rich enum surface, the definition covers what an agent needs: code authoring rules (last expression plays, setup lines first, quoting conventions, one draw method per pattern), tempo handling, session lifecycle, and what the user will actually see. Nothing needed to call 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 every parameter (bpm range, code, theme, title, session, visuals, autoplay) is already documented in the schema, which sets the baseline at 3. The description adds modest extra meaning: session is tied to update-session/get-session and to the 2-hour log window, and visuals is constrained to empty layers. Most of the parameter text otherwise restates the schema (e.g. the setcps and reduced-motion notes already live on bpm and visuals).
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 first sentence states a specific verb and resource ('Live-code music in Strudel ... and play it in a player the user can edit') and immediately names the rendering target (the Strudel REPL with inline editor and playback controls). It distinguishes itself from its siblings by naming update-session, get-session and get-strudel-guide by name and role. An agent can tell this apart from play-sheet-music or convert-abc-to-strudel without opening any schema.
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 routed explicitly: use `visuals` only as a fallback for code with no visual of its own ('It only fills a layer the code leaves empty ... Your own visual is the better result'), use `session: true` specifically 'to jam back and forth, or to change a piece while it plays', and then use update-session/get-session. Optional advanced capabilities are listed with the get-strudel-guide topic to consult, which is an explicit next-step routing rather than vague guidance.
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?
The description adds behavior the annotations don't cover: the result merely confirms the parse and returns no audio, the player renders inline with interactive controls, the user can edit score/style/instrument, and WAV/MIDI downloads are offered. That is genuinely useful context for an agent deciding what to expect. It doesn't contradict readOnlyHint=true, since nothing is persisted server-side; gaps remain around whether the widget/session state is retained across calls.
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 core capability and constraints are front-loaded in the first two sentences, with guidance and return-value notes following. The trailing sentence 'The music player renders inline with interactive playback controls' partially repeats the earlier 'user can edit the score in the player' and could be folded in.
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 an 8-parameter, all-optional rendering tool with no output schema, the description covers input expectations, prerequisite (chord symbols for accompaniment), expected return (parse confirmation, no audio) and follow-up guide topics. It is nearly complete; only the persistence/lifecycle of the inline widget is left unstated.
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 schema already documents style, swing, tempo, title, drumIntro, transpose, instrument and abcNotation in detail. The description reinforces a few points (128 GM instruments, chord symbols for accompaniment, style examples) but adds little beyond what the schema states. Baseline 3 applies when the schema carries the semantic load.
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 sentence gives a specific verb and resource ('Write a score in ABC notation and play it as sheet music') plus the range of outputs (melody, harmonized piece, multi-voice, well-known tune). It is clearly distinguishable from siblings like play-live-pattern and convert-abc-to-strudel, which the description implicitly frames by centering on a written score rather than a live pattern or a Strudel conversion.
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 workflow routing: start with get-music-guide topic 'genres', then 'abc-syntax' and 'instruments' for the rest. It also states a prerequisite for accompaniment (chord symbols required for style presets). What's missing is explicit when-not guidance, e.g. when to prefer play-live-pattern or convert-abc-to-strudel instead.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=true and idempotentHint=false, so the safety profile is covered. The description adds genuinely new behavioral context: retrieval is semantic rather than exact-match and is backed by the official strudel.cc and ABCJS docs, which tells the agent how to phrase queries and how much to trust results. It stops short of saying how many results come back or how ranking works, which keeps it off a 5.
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?
Three sentences, front-loaded with purpose, then routing guidance, then the underlying mechanism. No redundancy with the name or title, and 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 two-parameter read-only search with full schema documentation and no output schema, the definition covers purpose, retrieval mechanism, source corpora, and when to prefer it over siblings. The only mild gap — result count and ranking — is minor for a semantic search tool and partly implied by the return description.
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% and the schema already explains both parameters in depth, including good/bad query examples and the strudel vs abcjs enum meanings. The description only adds the indirect hint that `library` maps to the two indexed doc sources; it contributes nothing about query length or formatting beyond what the schema states. 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?
States a specific verb and resource ('Search detailed documentation') and immediately scopes it to two named corpora, 'Strudel live coding or ABC/ABCJS notation'. It also names the sibling guides it complements, so an agent can distinguish it from get-strudel-guide and get-music-guide without opening either schema.
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?
Explicitly gives the selection condition: use this when 'the curated guides (get-strudel-guide, get-music-guide) don't cover what you need', and enumerates the trigger cases — specific functions, advanced techniques, uncertain syntax. This is a clear when-to-use plus named alternatives, leaving little to inference.
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?
Goes well beyond the annotations: it discloses that playback continues uninterrupted, that the change lands on a musical boundary, that errors are reported back if the player responds within seconds, and the subtle gotcha about shipping a merge rather than a new start value for remember() state. This is exactly the kind of context annotations cannot convey.
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 and dense with useful content; the precondition and the timing behavior come first. A few clauses restate the schema's quantize values, which is minor redundancy but not wasteful enough to hurt.
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 mutation tool with no output schema, it covers precondition, timing semantics, result/error feedback, a state-mutation caveat, and points to the guide for the tricky case. An agent has everything needed to invoke it correctly.
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 the baseline is 3, but the description adds real meaning: the quantize value should match phrase length (with a concrete example), and code must be the WHOLE pattern rather than a fragment. This exceeds what the schema text alone communicates.
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 while playback continues. The phrase 'Only for a live session' plus 'as for play-live-pattern' implicitly contrasts it with the sibling that starts a live session, though it never names that alternative explicitly.
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 a clear precondition ('only for a live session') and usage guidance for quantize tied to musical phrasing ('8-bar phrase → 8'). It does not explicitly say when not to use it or name the tool to create a session first, leaving that inference to the agent.
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 / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"convert-abc-to-strudel1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"create-share-link1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"get-music-guide1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"get-session1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"get-strudel-guide1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"play-live-pattern1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"play-sheet-music1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"search-music-docs1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"update-session1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"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-linkRead-only sheet music discovery and practice tools, with browser-local recognition guidance.
ScoreStarling is an all-in-one AI sheet music assistant. Ask for anything to do with sheet music: transcribe a song from audio, video or a link, read a PDF or photo, add chords, change the key, make it easier, turn it into guitar TAB or jianpu, or arrange it for another instrument. Every change lands on a real score you can hear, fix and download (PDF, MIDI, MusicXML, guitar TAB, jianpu, audio). Hosted remote server with OAuth sign-in. Free accounts get monthly credits and free previews; prices are at scorestarling.com/pricing. Setup: https://scorestarling.com/mcp
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.
Add one secure layer between your agents and this server.
