ABC sheet music + Strudel live coding studio with ext-apps widgets, harmony tools, and share links.
Scored across 7 tools
Each tool has a clearly bounded role: harmony analysis, ABC-to-Strudel conversion, ABC sheet-music playback, Strudel live coding, and guide/search lookup. The two play tools are separated by notation system and output mode, and the guides are explicitly tiered against search, so there is little ambiguity.
Names consistently follow a hyphenated verb_noun pattern: analyze-, convert-, get-, get-, play-, play-, search-. The repeated verbs are paired with distinct objects, and there is no mixing of casing or naming styles.
Seven tools is a well-scoped size for a music creation studio: theory, conversion, two playback modes, reference guides, and doc search all earn their place. Nothing feels redundant or bloated.
The main workflow is covered: analyze harmony, compose ABC sheet music, convert to Strudel, live-code, and consult documentation. The only minor gap is that live-pattern sessions have no explicit stop/update/management tool—the REPL requires the user to stop the previous player—but agents can work around this.
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/detect-key need notes or 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 and idempotentHint. The description adds transparency by noting it returns both ABC and Strudel forms and explains task-specific input requirements (e.g., 'detect-chord/detect-key need notes or chords'). This meaningfully extends beyond the annotations 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?
The description is efficiently structured as a single paragraph that lists tasks and required inputs without redundancy. It avoids repeating schema details while providing necessary context, though it is a bit dense.
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?
Given the absence of an output schema, the description clarifies the return formats (ABC chord-symbol spelling and Strudel form). It also explains parameter dependencies for each task, making the tool self-contained and usable without external references.
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 covers all 5 parameters with descriptions (100% coverage). The description adds valuable task-to-parameter mapping (e.g., 'suggest-progression/key-chords need a key'), which gives extra semantic clarity beyond the 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?
The description clearly states the tool's purpose with specific verbs: 'name a chord', 'guess the key', 'get a progression', 'list what fits a key'. It distinguishes itself from sibling tools (conversion, guides, playing, searching) by focusing on harmony analysis, making its role obvious.
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 explicit usage guidance: 'Use it before writing chord symbols for a style preset, or to check a harmonization.' While it doesn't explicitly mention alternatives or when not to use it, the guidance is direct and actionable.
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. Dates show when Glama detected each change.
get-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-docsClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity – fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge – works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge – works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Deterministic music theory for agents: analyze, voice, reharmonize, conduct — computed, not guessed
Create, co-edit, analyze, publish, and export collaborative step-sequencer sessions through MCP.
Write lyrics in 100+ styles, score them, generate full songs with 4 engines, split stems. OAuth.
AI music studio: song generation with vocals, covers, stems, voice conversion, mastering, editing.
Add one secure layer between your agents and this server.
