Music studio: ABC notation composition and Strudel live coding with ext-apps UI.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.1/5 across 5 of 5 tools scored. Lowest: 3.2/5.
Each tool targets a distinct area: reference guides for different domains (ABC vs Strudel), live coding playback, sheet music playback, and documentation search. No overlap.
All tool names follow a consistent verb_noun pattern in snake_case: get-music-guide, get-strudel-guide, play-live-pattern, play-sheet-music, search-music-docs.
With 5 tools, the set is well-scoped for a music composition and live coding server. Each tool serves a clear purpose without bloat or thinness.
Core workflows are covered: reference, live coding, sheet music, and search. Minor gaps exist (e.g., no explicit project management or audio export), but the surface supports the server's purpose.
get-music-guideMusic Reference GuideAReturns 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.
get-strudel-guideStrudel Reference GuideBReference material for Strudel live coding (performance mode). Topics: mini-notation (pattern syntax), sounds (synths, 72 drum banks, 128 GM instruments), 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), advanced (visualization, 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, 'advanced' for visualization and sample loading. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, indicating a safe, read-only operation. The description reinforces this by calling it 'Reference material' and does not contradict annotations. However, it adds little behavioral context beyond the annotations, such as whether results are cached or real-time. A score of 3 is appropriate as the description adds topic scope but no new behavioral traits.
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 long sentence listing many topics with colons, which is somewhat structured but verbose. It is front-loaded with the main purpose, but the list could be more concise or broken into bullet points. Every sentence earns its place, but the density achieves minimal viable conciseness.
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 having a simple parameter and high schema coverage, the description does not explain what the tool returns (e.g., text with explanations, code examples, or structured data). Since there is no output schema, the description should at least mention the response format or that it provides detailed tutorials. This omission makes the tool less complete for an agent.
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 input schema provides 100% coverage with a single parameter 'topic' that has an enum of all possible values and a description suggesting starting points. The main description lists the same topics but does not add additional meaning beyond what the schema already provides. Therefore, it meets the baseline for high schema coverage.
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 it is 'Reference material for Strudel live coding', specifying the tool's function as a guide for a specific domain. The list of topics gives a comprehensive overview, and the title 'Strudel Reference Guide' distinguishes it from siblings like 'get-music-guide' which is likely a general music reference.
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 does not provide explicit guidance on when to use this tool versus its siblings or alternatives. It only lists topics without explaining under what circumstances to choose it. The input schema includes a hint to start with certain topics, but that is within the schema, not the main description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
play-live-patternPlay Live PatternALive-code music patterns using TidalCycles mini-notation in JavaScript. Layer drums, synths, and bass with stack(). Choose from 72 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() — use one visual per pattern). Use get-strudel-guide for genre templates, sound references, and advanced features like visualization, 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. | |
| title | No | Pattern title displayed in the widget header (e.g. 'Midnight Rain'). | |
| 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 indicate safe, idempotent, read-only behavior. The description adds context: the REPL is editable directly, autoplay may require user click due to browser policy, and visualizations are available. This goes 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 well-structured, front-loading the main purpose. It is detailed but not overly verbose; however, there is slight redundancy (REPL mentioned twice). It earns its length by covering key features.
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 complexity of live coding with a REPL and visualizations, the description covers core features, guides, and browser policies. No output schema exists, but the description explains what the REPL does. It is largely complete for agent use.
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%. The description adds minor context (e.g., bpm converts to setcps, code uses mini-notation, autoplay policy) but does not substantially enhance understanding beyond the schema. Baseline 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 the verb ('live-code music patterns') and the resource (TidalCycles mini-notation via Strudel). It distinguishes from sibling tools like play-sheet-music and get-strudel-guide by mentioning specific capabilities like stack(), visualizations, and that it uses a REPL.
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 mentions using get-strudel-guide for genre templates and advanced features, implying when not to use this tool. It provides clear context that this is for live coding patterns, but does not explicitly state exclusions relative to play-sheet-music.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
play-sheet-musicPlay Sheet MusicACompose 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 percentage (0-100). 0=straight, 33=light swing, 66=heavy swing. Great for jazz and blues. | |
| tempo | No | Tempo in BPM (40-240). Overrides Q: in ABC notation. | |
| title | No | Piece title (overrides T: in ABC). Displayed in the widget header. | |
| transpose | No | Transpose by semitones (-12 to 12). Positive=higher, negative=lower. | |
| instrument | No | Default instrument (e.g. 'Flute', 'Cello', 'Acoustic Grand Piano', 'Alto Sax'). Use get-music-guide with topic 'instruments' for the full list. | |
| 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?
Description adds behavioral context beyond annotations: it returns parse-status confirmation and renders a player with interactive playback controls, not raw audio. Annotations already declare readOnlyHint=true and idempotentHint=true, so no 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?
Concise and front-loaded with key purpose. No wasted sentences; essential caveats included efficiently.
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 7 parameters, no output schema, and good annotations, the description is complete. It explains the tool's output, behavior, and directs to sibling tools for additional info.
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% with detailed descriptions for all 7 parameters. The description does not add meaning beyond what the schema provides, so baseline 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 the tool composes and plays sheet music with visual notation, audio, and style presets. It distinguishes from siblings like get-music-guide by specifying its direct functionality.
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 states when to use (composing sheet music) and when not (does not return raw audio). Directs users to get-music-guide for genre templates and syntax reference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search-music-docsSearch Music DocumentationASearch 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 and openWorldHint. The description adds that it is 'Powered by semantic search over strudel.cc and ABCJS docs', which provides context about the search mechanism and source authority. No contradictions.
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 three sentences with no fluff. Each sentence adds value: what it does, when to use it, and how it works. Front-loaded with the main action.
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 it's a search tool with two parameters and no output schema, the description covers return content ('code examples and explanations'), usage context, and query formulation guidance. Siblings are referenced appropriately.
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%. The description adds valuable examples for the query parameter ('Good: ... Bad: ...') and explains the library parameter's enum values ('strudel for live coding patterns, abcjs for sheet music notation'). This goes beyond schema description.
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 uses a specific verb 'Search' on a clear resource 'detailed documentation for Strudel live coding or ABC/ABCJS notation'. It distinguishes from siblings by stating when to use this tool over the curated guides.
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 says 'Use this when the curated guides (get-strudel-guide, get-music-guide) don't cover what you need' and names those alternatives. Provides specific scenarios like 'specific functions, advanced techniques, or when you're unsure about syntax'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
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
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!
Sign in to create a connector for this server.