The Strudel MCP Server provides comprehensive AI-powered music generation and live coding by directly controlling Strudel.cc in a browser.
Core Features:
Browser Control & Pattern Editing: Initialize Strudel.cc, write/append/insert/replace/clear patterns, and control playback (play, pause, stop)
AI Music Generation: Create complete patterns across 8+ genres (techno, house, dnb, ambient), generate drum sequences, basslines, melodies, and variations (subtle to extreme)
Music Theory Tools: Generate scales, chord progressions, Euclidean rhythms, polyrhythms, and apply music theory concepts
Pattern Manipulation: Transpose, reverse, stretch, quantize, humanize, set BPM, and add swing
Audio Effects & Analysis: Add/remove effects, perform real-time FFT spectrum analysis, rhythm/tempo/key detection
Session Management: Save/load patterns with metadata and tags, undo/redo functionality
Enables AI-powered music generation and live coding through Strudel.cc, providing pattern management, audio analysis, and real-time control of TidalCycles/Strudel patterns for interactive music creation.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Strudel MCP Server create a techno beat at 128 BPM"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
🎵 MCP server for AI-assisted live-coding music via strudel.cc
Unofficial fan project. Not affiliated with, or endorsed by, the Strudel project. This adapter exists to make live-coding music accessible to beginners who want to try pattern-based music without learning the whole ecosystem first.
Status: Beta | 88% statement coverage | Published to npm | Actively developed
A Model Context Protocol (MCP) server that drives Strudel.cc from Claude for AI-assisted live-coding music, pattern generation, and algorithmic composition.
Current State: Beta. The core workflow (init → compose → playback → analyze) works reliably with real audio output. npm test reports ~3060 passing tests, 88.99% statement coverage / 79.99% branch coverage. CI is hardened with OpenSSF Scorecard, SHA-pinned actions, CODEOWNERS, Dependabot, and lint as a blocking gate.
What "Beta" means here:
Tool schemas are stable within minor versions; breaking changes require a major bump
Multi-session is supported as of v3.0.0 (#108) — named sessions get isolated browser, history, and audio-capture state
Upstream @strudel/* dependencies pinned to known-good versions; Dependabot bumps gated on CI
Expect hands-on iteration for non-standard patterns — report rough edges, they get fixed
Related MCP server: Filopastry
28 MCP tools covering pattern editing, playback, audio analysis, generation, history, sessions, MIDI import/export, and Gemini-backed assists. Each tool is enum-parameterized to keep the protocol surface small: pattern_store({ action }), edit_pattern({ mode }), transform({ op }), analyze({ include }), history({ action }), playback({ action }), effect({ action }), shape({ dimension }), audio_capture({ action }), browser_window({ action }), generate_part({ role }), generate_rhythm({ type }), music_theory({ query }), session({ action }), ai_assist({ task }), ... The 58 legacy single-verb aliases that forwarded to these were removed in v4.0.0 (#178).
4 MCP resources for catalog browsing without burning tool calls: strudel://examples, strudel://patterns, strudel://styles, strudel://docs/tools.
Real browser automation of Strudel.cc through Playwright.
Multi-session support — every browser-touching tool accepts an optional session_id; sessions have isolated browser pages, undo/redo/history stacks, and audio-capture services.
Audio analysis via Web Audio API (FFT spectrum, tempo detection, key detection, rhythm complexity).
Template-based pattern generation across 8 genres (techno, house, dnb, ambient, trap, jungle, jazz, experimental); optional Gemini-backed ai_assist for feedback, suggestions, and jamming.
Music theory helpers: 14 scales, 8 chord progression styles, euclidean and polyrhythm generation.
Pattern persistence: JSON-backed save/load with tags + the in-memory edit history (undo/redo/restore/compare).
Result envelope on every tools/call: clients branch on { ok, errorCategory, isRetryable } instead of parsing free-text.
~3060 passing tests: npm test runs ~3020 unit/integration/example tests in parallel, then 36 browser-validation tests serially against real Chromium. The coverage figure below is from the first tier, which is the one CI also runs — the browser tier adds ~0.2 points and CI does not execute it, so counting it would document coverage nothing verifies.
88.99% statement coverage / 79.99% branch coverage (90.5% functions, 89.75% lines), checked against coverage/coverage-summary.json by a drift guard.
Lint blocking in CI: 0 errors, ~195 warnings (mostly any in test mocks).
OIDC trusted publishing to npm with SLSA build provenance attestation on every release.
Not Production-Ready: This is experimental software under active development. Use for exploration and experimentation. Expect breaking changes, bugs, and incomplete features. See the Contributing section to help improve it.
7 example patterns ship in patterns/examples/, grouped by genre:
Ambient: ambient-pad (70 BPM)
Dnb: dnb-classic (174 BPM)
House: house-classic (125 BPM)
Jazz: jazz-ii-v-i (120 BPM)
Jungle: amen-break (165 BPM)
Techno: techno-driving (130 BPM)
Trap: trap-modern (140 BPM)
Each example is a JSON file with pattern code, BPM, key, and a description, and each sets the tempo it declares (#367). See patterns/examples/README.md for details. Agents can also list these via the strudel://examples MCP resource without making any tool calls.
@williamzujkowski/strudel-mcp-serverThis project was renamed from @williamzujkowski/strudel-mcp-server to @williamzujkowski/live-coding-music-mcp to make the unofficial fan-project status unambiguous (see #97). The old package is deprecated on npm.
If you were using the old package:
# Remove old
npm uninstall -g @williamzujkowski/strudel-mcp-server
# Install new
npm install -g @williamzujkowski/live-coding-music-mcpUpdate your MCP client config. The bin name changed from strudel-mcp to live-coding-music-mcp:
// BEFORE
{
"mcpServers": {
"strudel": { "command": "strudel-mcp" }
}
}
// AFTER
{
"mcpServers": {
"live-coding-music": { "command": "live-coding-music-mcp" }
}
}The MCP server's internal identity string also changed from strudel-mcp-enhanced to live-coding-music-mcp. If you have a client that keys on that string (logs, allowlists, permission policies), update it accordingly.
All tool names and schemas are unchanged.
Requirement | Version | Notes |
Node.js | 22.x+ | LTS required |
npm | 10+ | Comes with Node.js |
Chromium | Latest | Auto-installed by Playwright |
Audio output | Any | Required for playback (speakers/headphones) |
Optional: Docker for containerized deployment.
npm install -g @williamzujkowski/live-coding-music-mcp
# Install browser (required once)
npx playwright install chromium# Clone repository
git clone https://github.com/williamzujkowski/live-coding-music-mcp.git
cd live-coding-music-mcp
# Install dependencies
npm install
# Install Chromium for browser automation
npx playwright install chromium
# Build the project
npm run buildGet from install to your first generated pattern in under two minutes.
npm install -g @williamzujkowski/live-coding-music-mcp
npx playwright install chromium # one-timeBuilding from source instead? See Installation → From Source.
Edit your Claude Desktop config file:
OS | Config path |
macOS |
|
Windows |
|
Linux |
|
Add the server:
{
"mcpServers": {
"live-coding-music": {
"command": "live-coding-music-mcp"
}
}
}Restart Claude Desktop. The server appears under the 🔌 plug icon.
# If installed globally
claude mcp add strudel live-coding-music-mcp
# If built from source
claude mcp add strudel node /path/to/live-coding-music-mcp/dist/index.js# From a global install
echo '{"jsonrpc":"2.0","method":"tools/list","id":1}' | live-coding-music-mcp
# From source
npm run validateYou should see a JSON response listing 28 tools. If you see fewer, the build is out of date — run npm run build.
In Claude, ask:
Initialize Strudel and compose a techno beat.
What you'll see: A Chromium window opens (visibly — this is the live editor, not a hidden process) and lands on strudel.cc. Claude calls init, then compose({ style: "techno" }). A 4-on-the-floor pattern appears in the CodeMirror editor and starts playing through your speakers.
Prefer headless mode (no browser window)? Set "headless": true in config.json before the first init call — see Configuration. Note that tempo detection currently reflects how often the agent polls rather than the audio itself (#322), in headed or headless mode alike.
Quick Reference below: tool cheat sheet for common operations.
Usage Examples: multi-step workflows (composition, audio analysis, AI-assisted jamming).
patterns/examples/: 18 ready-to-play patterns across 7 genres plus 4 longform pieces. Agents can browse them via the strudel://examples MCP resource without burning tool calls.
Common operations as one-line tool calls:
Action | Tool call |
Initialize browser |
|
Create a techno beat in one shot |
|
Play pattern |
|
Stop playback |
|
Get current pattern |
|
Analyze audio (all features) |
|
Detect tempo only |
|
Save pattern |
|
Undo last edit |
|
Edit current pattern |
|
Create an isolated session |
|
The legacy single-verb tools (play, stop, save, undo, write, generate_pattern, ...) were deprecated aliases during the 3.0.x line and were removed in v4.0.0 (#178). Use the consolidated tools above.
One-shot workflow:
compose with style: "dnb", key: "Am", tempo: 174, auto_play: true28 tools across 15 categories:
Tool | Description |
| Initialize Strudel in browser |
Tool | Description |
| Mutate the current session pattern. mode=write replaces the editor contents (default; mirrors the old write tool exactly, including optional pattern validation and auto_play). mode=append concatenates |
| Get current pattern code |
Tool | Description |
| Control transport on the current session. action=play starts the editor pattern. action=pause halts the clock where it is, so play resumes mid-cycle. action=stop ends playback. Example: playback({ action: "play" }). For pattern editing use edit_pattern; for tempo use set_tempo. |
| Set BPM. Writes setcpm(bpm/4), assuming one bar of 4/4 per cycle. |
Tool | Description |
| Persist patterns to disk and read them back. Use action=save to write the current session pattern under a name; action=load to restore a named pattern into the current session; action=list to enumerate the on-disk catalog (optionally filtered by tag). Example: pattern_store({ action: "save", name: "my-jam", tags: ["techno"] }). For session lifecycle (create/destroy/list active sessions) use the session tool — pattern_store deals with on-disk patterns, not runtime sessions. |
| Convert a .mid file into a playable Strudel pattern (Phase 1: literal transcription, #201). Use source="base64" with data= for inline bytes, or source="path" with data= to read from the patterns/midi/ directory (path traversal blocked). Drum tracks (MIDI channel 10) emit one s() lane per sample so simultaneous kicks/hats do not collide. Pitched tracks emit note("...").s("piano") with simultaneous notes merged into [a,b,c] chord tokens. Phase 2+ (structural compression, voice separation, LLM idiomatic pass) tracked in separate issues. Example: import_midi({ source: "path", data: "drumloop.mid", steps_per_cycle: 16 }). For the reverse direction (Strudel → MIDI) use the export_midi tool. |
Tool | Description |
| Navigate or inspect the pattern edit history. action=undo reverts the last edit on the targeted session. action=redo replays a previously-undone edit. action=list returns recent entries with timestamps and previews (limit defaults to 10). action=restore jumps the editor to a specific entry by id (current pattern goes on the undo stack). action=compare diffs two entries by id (or one entry vs current pattern). Example: history({ action: "list", limit: 5 }) — recent edits, newest first. For on-disk saved patterns use pattern_store — history deals with the in-memory edit timeline of the current session. |
Tool | Description |
| Generate, write, and play a complete pattern in one step. Auto-initializes default browser if needed. |
| Generate a single instrumental layer and append it to the current session pattern. role=drums takes |
| Generate a rhythmic pattern and append it to the current session. type=euclidean produces a Euclidean rhythm with |
Tool | Description |
| Music-theory queries. query=scale returns the notes of a scale (e.g. "C major scale: C, D, E, F, G, A, B"). query=chord_progression returns a chord progression for the key/style AND writes the resulting chord pattern into the current session. Example: music_theory({ query: "scale", root: "C", scale: "major" }). For pattern generation (drums/bass/melody) use generate_part; for rhythmic patterns use generate_rhythm. |
Tool | Description |
| Apply a single transform op to the current session pattern. op=transpose shifts notes by |
| Add or remove a Strudel effect on the current session pattern. action=add appends |
| Shape the current pattern along one of three high-level dimensions. dimension=mood applies a mood profile (dark/euphoric/melancholic/aggressive/dreamy/peaceful/energetic) with optional intensity 0-1. dimension=energy applies an energy level (integer 0-10). dimension=refine applies a directional refinement: faster/slower/louder/quieter/brighter/darker/"more reverb"/drier. All three auto-play by default. Example: shape({ dimension: "mood", target_mood: "dark", intensity: 0.8 }). For raw transform ops use transform; for explicit effects use effect. |
Tool | Description |
| Gemini-backed pattern assistance. task=feedback returns creative critique on the current pattern (optionally with audio analysis). task=suggest analyzes the currently playing audio and suggests a complementary Strudel pattern as text (not auto-executed). task=jam generates a fresh layer (drums/bass/melody/pad/texture) and merges it into the current pattern, then auto-plays. All three share Gemini auth + rate limiting. Example: ai_assist({ task: "jam", layer: "bass" }). Needs GEMINI_API_KEY, or a logged-in claude/agy/codex CLI on PATH (#252). For non-AI pattern generation use generate_part; for full compositions use compose. |
Tool | Description |
| Audio analysis on the currently-playing pattern. include=["all"] (default) returns the full spectrum + features object, matching the pre-consolidation behaviour. include=["tempo"] returns only BPM with confidence. include=["key"] returns detected key + scale + confidence. include=["spectrum"] returns FFT features (bass, mid, treble, brightness, etc.). include=["rhythm"] returns rhythm-only analysis (complexity, density, syncopation). Combining values returns an object keyed by category, e.g. analyze({ include: ["tempo", "key"] }) → { tempo: {...}, key: {...} }. Example: analyze({ include: ["tempo"] }) to cheaply re-check BPM during a session. For static pattern analysis (no browser) use analyze_pattern_local; for runtime validation use validate_pattern_runtime. |
| Validate pattern with runtime error checking (monitors Strudel console for errors) |
| Validate pattern syntax against the local StrudelEngine, which runs in a sandboxed child process (no browser required) |
| Static analysis (events/cycle, complexity, optional BPM) without browser playback |
| Enumerate events the pattern would emit between two cycle indices (max 16 cycles) |
| Transpile pattern source via StrudelEngine; returns transpiled code or syntax error |
Tool | Description |
| Manage isolated Strudel browser sessions (multi-session, #108). action=create starts a new named session (sessions share one browser but isolated contexts). action=destroy closes a named session and releases its resources. action=list returns metadata for all active sessions (id, created, last_activity, is_playing, is_default). action=switch changes the default session that subsequent tool calls route to when no session_id is passed. Example: session({ action: "create", session_id: "live-set-1" }). For the on-disk pattern catalog use pattern_store(action=list) — session(action=list) lists runtime sessions, not saved patterns. |
Tool | Description |
| Export current pattern to MIDI file. Parses note(), n(), and chord() functions. |
| Interact with the visible Strudel browser window. action=show brings the window to the foreground. action=screenshot captures the current editor view to disk (optional |
Tool | Description |
| Record audio output from the live Strudel session. action=start begins streaming capture (optional |
Tool | Description |
| Inspect server and browser state. level=status returns a quick state snapshot (cache read, <15ms SLA), plus which config.json was read and any warnings from it. level=full returns detailed browser diagnostics including caches, errors, and performance. level=perf returns server-side timing metrics + top bottlenecks. level=memory returns process memory usage. level=errors returns captured console errors and warnings from Strudel. Default level=full preserves the pre-consolidation behaviour. Example: diagnostics({ level: "status" }) — millisecond-cheap. For screenshots use browser_window; for tool listings use the strudel://docs/tools resource. |
Tool | Description |
| Record a window of live Strudel audio and write it to a file. Returns a path plus what was actually recorded, not a wall of base64 — prefer this over audio_capture when you want the audio to exist somewhere. format=wav (default) decodes to 16-bit PCM a DAW will open; format=webm writes the raw Opus recording. Reports silent captures instead of writing a silent file and claiming success. Audio must already be playing: call playback({ action: "play" }) first. Example: export_audio({ duration: 4000, filename: "take-01" }). |
Auto-generated from source. 28 tools registered.
Create a Simple Beat
You: Initialize Strudel and create a simple techno beat
Claude: [Initializes browser]
[Generates and writes pattern]
[Starts playback]
Pattern created:
setcpm(130/4)
stack(
s("bd*4"),
s("~ cp ~ cp"),
s("hh*8").gain(0.4)
).gain(0.8)Generate a Bassline
You: Add a techno bassline in C
Claude: [Generates bassline]
[Appends to current pattern]
Added: note("c2 c2 c2 c2").s("sawtooth").cutoff(800)Jazz Composition
You: Create a jazz progression in F major with a walking bass
Claude: Generated progression: "Gm7" "C7" "Fmaj7"
Pattern:
stack(
note("Gm7" "C7" "Fmaj7").struct("1 ~ ~ ~").s("piano"),
note("g2 c2 f2").s("sine").gain(0.7)
)Drum & Bass Track
You: Generate a complete drum & bass track at 174 BPM
Claude: [Creates multi-layer pattern with drums, bass, and pads]
// dnb pattern in C at 174 BPM
setcpm(174/4)
stack(
// Drums
s("bd ~ ~ [bd bd] ~ ~ bd ~, ~ ~ cp ~ ~ cp ~ ~").fast(2),
// Bass
note("c1 ~ ~ c2 ~ c1 ~ ~").s("square").cutoff(400),
// Pads (atmospheric)
note("c3 eb3 g3 bb3").s("sawtooth")
.attack(2).release(4).room(0.8).gain(0.6)
)Live Audio Analysis
You: Analyze what's playing and show me the frequency breakdown
Claude: Audio Analysis Results:
{
"connected": true,
"features": {
"average": 78.5,
"peak": 180,
"peakFrequency": 120,
"bass": 145,
"mid": 82,
"treble": 45,
"isPlaying": true,
"brightness": "balanced"
}
}
Strong bass presence detected - typical for techno/house patterns.Pattern Variations
You: Create a glitchy variation of the current pattern
Claude: [Applies glitch transformation]
Added: .sometimes(x => x.chop(8).rev).rarely(x => x.speed(-1))Layered Ambient Track
You: Create an ambient soundscape with multiple layers
Claude: [Generates complex multi-layer pattern]
setcpm(90/4)
stack(
// Deep bass drone
note("c1").s("sine").attack(4).release(8).gain(0.5),
// Texture pad
note("c3 eb3 g3").s("sawtooth")
.attack(2).release(6).room(0.9).gain(0.4),
// Sparse percussion
s("bd ~ ~ ~, ~ ~ ~ hh:8").room(0.9).gain(0.3),
// Melodic sparkles
note("c5 g5 eb5 bb5").struct("~ 1 ~ 1 ~ ~ 1 ~")
.s("triangle").delay(0.5).room(0.8).gain(0.3)
)Save and Load Patterns
You: Save this pattern as "techno-groove-1" with tags "techno" and "experimental"
Claude: Pattern saved as "techno-groove-1"
---
You: List all my techno patterns
Claude: Saved patterns with tag "techno":
• techno-groove-1 [techno, experimental] - 2025-10-23T19:30:00.000Z
• acid-bassline [techno, acid] - 2025-10-23T18:15:00.000Z
---
You: Load "acid-bassline"
Claude: Loaded pattern "acid-bassline"
[Pattern written to editor]Generate Euclidean Rhythms
You: Create a 5/8 euclidean rhythm with kick drum
Claude: Generated Euclidean rhythm (5/8)
Pattern: s("bd").struct("1 ~ 1 ~ 1 1 ~ 1")Complex Polyrhythms
You: Generate a polyrhythm with kick (4/16), snare (7/16), and hi-hat (3/16)
Claude: Generated polyrhythm
stack(
s("bd").euclid(4, 16),
s("cp").euclid(7, 16),
s("hh").euclid(3, 16)
)AI-Assisted Composition
You: Analyze the mood of my current pattern and suggest complementary elements
Claude: [Analyzes pattern structure and audio features]
Your pattern has:
- Energetic rhythm (130 BPM)
- Strong bass presence
- Minimal melodic content
Suggestions:
1. Add arpeggiated synth for movement
2. Include occasional breaks/fills
3. Layer atmospheric pad for depth
Would you like me to add any of these?
You: Add an arpeggiated synth in C minor
Claude: [Generates and adds]
note("c4 eb4 g4 bb4 c5").struct("1 1 1 1 1 1 1 1")
.s("triangle").delay(0.25).room(0.3).gain(0.5)Tools are exercised against real Strudel.cc interaction through the browser test suite; those are skipped in CI (require Playwright + audio) but run locally:
# Run integration tests
npm run test:integration
# Run browser tests
node tests/strudel-integration.js
# Run npm test to see current pass/fail/skip counts{
"headless": false, // Set true for background operation
"strudel_url": "https://strudel.cc/",
"patterns_dir": "./patterns",
"exports_dir": "./exports",
"audio_analysis": {
"fft_size": 2048, // power of 2 in [32, 32768]; code default is 1024
"smoothing": 0.8 // number in [0, 1]; default 0.8
}
}strudel_url is the REPL the browser is pointed at — set it to run against a self-hosted or
pinned Strudel build. Only http/https are accepted; anything else falls back to the default
with a logged warning. patterns_dir is where pattern_store reads and writes.
exports_dir is where export_midi({format:"file"}) writes. Exported filenames are reduced to a
basename and confined to this directory — a name containing path separators is sanitized rather
than honoured, and the response reports the path actually written.
Unknown top-level keys are logged as warnings at startup rather than silently ignored.
audio_analysis.fft_size tunes the FFT bin count on the AnalyserNode attached to Strudel's audio graph — larger = better frequency resolution at higher CPU cost. smoothing is the analyser's smoothingTimeConstant (higher = steadier spectrum, more lag). Invalid values fall back to defaults with a warning; the frequency-band boundaries inside analyze rescale automatically so band Hz coverage stays consistent across FFT sizes.
The server is a thin MCP dispatcher (src/server/server.ts, ~520 lines) over twelve per-domain tool modules (src/server/tools/*.ts), ten services (MusicTheory, PatternGenerator, SessionManager, AudioCaptureService, AudioExportService, GeminiService, MIDIExportService, MIDIImportService, StrudelEngine, PatternSandbox) plus a provider-agnostic AI transport layer (src/services/ai/), two controllers (StrudelController for Playwright, AudioAnalyzer for Web Audio API), and a JSON-on-disk PatternStore. Browser automation drives the editor on strudel.cc through window.strudelMirror.editor.dispatch(...) rather than keyboard simulation — about 80% faster.
For the full breakdown — component diagram, per-component responsibilities, directory layout, data flow, and optimization strategies — see ARCHITECTURE.md.
setcpm(130/4)
stack(
s("bd*4").gain(0.9),
s("~ cp ~ cp").room(0.2),
s("hh*16").gain(0.4).pan(sine.range(-0.5, 0.5)),
note("c2 c2 eb2 c2").s("sawtooth").cutoff(800)
).swing(0.05)setcpm(174/4)
stack(
s("bd ~ ~ [bd bd] ~ ~ bd ~, ~ ~ sn:3 ~ ~ sn:3 ~ ~").fast(2),
s("hh*16").gain(0.5),
note("e1 ~ ~ e2 ~ e1 ~ ~").s("sine:2").lpf(200)
)// Jazz ii-V-I in F
stack(
note("Gm7" "C7" "Fmaj7").struct("1 ~ ~ ~").s("piano"),
note("g2 c2 f2").s("sine").gain(0.7)
)# Build image
docker build -t live-coding-music-mcp .
# Run container
docker run -it --rm live-coding-music-mcp
# Or use docker-compose
docker-compose upFor development setup, scripts, debugging, adding new tools, and the release process, see DEVELOPMENT.md.
Quick links:
Setup — git clone to npm test
Adding new tools — module pattern + envelope helpers
Release process — gh release create triggers the publish workflow
Contributing — commit conventions and PR flow
The Configuration section above covers runtime config (config.json). ARCHITECTURE.md covers the system design.
Measured against the current StrudelController cache + Strudel.cc on a developer machine:
Operation | Latency |
Browser initialization | 1.5–2 s (with resource blocking) |
Pattern write | 50–80 ms (cached CodeMirror editor access) |
Pattern read (cached) | 10–15 ms |
Play / pause / stop | 100–150 ms |
Audio analysis (single FFT) | 10–15 ms |
Tempo detection | <100 ms (onset-based; reports poll cadence, not tempo — #322) |
Key detection | <100 ms (Krumhansl-Schmuckler, Pearson; bass-register accuracy depends on |
Pattern generation | <100 ms (template-based) |
Process resident memory | ~120–150 MB |
Create Custom Scales
// The MusicTheory service supports 15+ built-in scales
// You can request any combination:
You: Generate a lydian scale starting on D
Claude: D lydian scale: D, E, F#, G#, A, B, C#Complex Chord Progressions
You: Create a jazz ii-V-I progression in Bb with extended voicings
Claude: Generated jazz progression in Bb: "Cm7" "F7" "Bbmaj7"
Pattern:
note("Cm7" "F7" "Bbmaj7")
.struct("1 ~ ~ ~")
.s("sawtooth")
.add(note("7")) // Add 7th extensions
.room(0.4)Euclidean Patterns
You: Create a complex polyrhythm using euclidean patterns:
- Bass drum: 7 hits in 16 steps
- Snare: 5 hits in 16 steps
- Hi-hat: 11 hits in 16 steps
Claude: [Generates mathematically perfect polyrhythm]
stack(
s("bd").euclid(7, 16),
s("cp").euclid(5, 16),
s("hh").euclid(11, 16)
)Generative Variations
You: Create 3 variations of my current pattern: subtle, moderate, and glitchy
Claude: [Generates three variants]
Version 1 (subtle):
original.sometimes(x => x.fast(2))
Version 2 (moderate):
original.every(4, x => x.rev).sometimes(x => x.fast(2))
Version 3 (glitchy):
original.sometimes(x => x.chop(8).rev).rarely(x => x.speed(-1))Pattern Caching
// The server caches patterns intelligently:
// - Generated patterns stored before browser init
// - Editor content cached for 100ms
// - Audio analysis cached for 50ms
// For fastest performance:
1. Generate patterns before initializing browser
2. Initialize once and reuse the session
3. Batch multiple changes togetherHeadless Mode
// In config.json:
{
"headless": true, // Faster, no GUI
"strudel_url": "https://strudel.cc/",
"patterns_dir": "./patterns"
}Workflow Automation
You: Create a complete track:
1. Start with techno drums at 130 BPM
2. Add acid bassline in E
3. Layer ambient pads
4. Save as "track-001" with tags "techno", "acid", "experimental"
Claude: [Executes full workflow]
[Initializes browser]
[Generates drum pattern]
[Adds bassline]
[Layers pads]
[Saves with metadata]
Complete! Pattern saved as "track-001"Audio-Reactive Composition
You: Monitor the audio and suggest adjustments based on frequency balance
Claude: [Analyzes current playback]
Analysis shows:
- Bass: 180 (strong)
- Mid: 45 (weak)
- Treble: 30 (weak)
Recommendations:
1. Reduce bass gain by 20%
2. Add mid-range melodic content
3. Include hi-hat pattern for treble
Apply changes? [Yes/No]Dynamic Transformations
You: Apply these transformations in sequence:
1. Transpose up 3 semitones
2. Add 10% humanization
3. Apply reverb with 0.6 room size
4. Every 4th cycle, reverse the pattern
Claude: [Applies transformations]
Final pattern:
[original]
.transpose(3)
.nudge(rand.range(-0.1, 0.1))
.room(0.6)
.every(4, x => x.rev)Conditional Logic
You: Create a pattern that evolves:
- Bars 1-4: Simple kick pattern
- Bars 5-8: Add snare
- Bars 9-16: Add full drum kit
- Then loop with variations
Claude: [Generates evolving pattern]
s("bd*4")
.struct("1 ~ ~ ~")
.mask("<1 1 1 1 0 0 0 0>/4") // First 4 bars
.stack(
s("~ cp ~ cp")
.mask("<0 0 0 0 1 1 1 1>/8") // Bars 5-8
)
// Full complexity from bar 9
.every(8, x => x.sometimes(y => y.fast(2)))All patterns are validated before execution:
Dangerous gain levels (>2.0) are flagged
Eval blocks are rejected
Path traversal attacks are blocked in PatternStore
Be precise about what this does and does not give you:
The OS-level Chrome sandbox is disabled. Chromium is launched with --no-sandbox and
--disable-setuid-sandbox (src/StrudelController.ts) for headless
and container compatibility, where the sandbox otherwise needs CAP_SYS_ADMIN or user namespaces.
This is a deliberate trade-off, not a security feature.
The browser context is a fresh, non-persistent Playwright context — no profile on disk, no
cookies or storage carried over between runs, and no file:// navigation is ever performed.
Resource blocking is a performance optimization, not a security boundary. Images, fonts, and media are aborted to speed up page load; scripts, stylesheets, and network requests from strudel.cc are allowed through as normal.
Patterns are validated before execution (see above), which is the actual pre-execution control.
If you need real isolation, run the whole MCP server inside a locked-down container or VM. The server does not sandbox itself.
No authentication: The MCP server trusts all incoming requests
Local only: Designed for local development, not network deployment
Pattern execution: Patterns execute in browser context with audio access
Found a vulnerability? Please open a security issue or email the maintainer directly. Do not disclose publicly until patched.
Symptom: Error: Browser not initialized or Chromium launch fails
Solutions:
# Install Chromium for Playwright
npx playwright install chromium
# If that fails, try installing all browsers
npx playwright install
# Check Playwright installation
npx playwright --version
# For Linux, install dependencies
sudo npx playwright install-deps chromiumSymptom: Audio analysis shows connected: false
Solutions:
Ensure pattern is playing first:
You: Play the pattern, wait 2 seconds, then analyzeReinitialize the browser:
You: Stop, close the browser, reinitialize, and try againCheck audio context activation:
Audio contexts require user interaction on some systems
The browser window must be visible (not headless) for first run
Symptom: Pattern doesn't play or shows errors in console
Solutions:
Common issues:
1. Missing quotes: s(bd*4) → s("bd*4")
2. Unmatched parentheses: stack(s("bd")) → stack(s("bd")))
3. Invalid note names: note("h2") → note("c2")
Test with minimal pattern first:
s("bd*4")
Then build complexity gradually.Symptom: Claude can't find the server or tools
Solutions:
# Verify server is built
npm run build
# Check if server responds
echo '{"jsonrpc":"2.0","method":"tools/list","id":1}' | node dist/index.js
# Should return JSON with 28 tools
# Reinstall MCP server in Claude
claude mcp remove strudel
claude mcp add strudel node $(pwd)/dist/index.js
# Restart Claude
claude chatSymptom: Operations take longer than expected
Solutions:
Enable caching (default, but verify):
Editor caching: 100ms TTL
Audio analysis: 50ms TTL
Use headless mode for faster operation:
// config.json
{ "headless": true }Batch operations:
Instead of:
- Add drums
- Add bass
- Add melody
Do:
- Generate complete pattern with drums, bass, and melodyReduce browser overhead:
Close other browser instances
Disable browser DevTools
Use resource blocking (enabled by default)
Symptom: pattern_store({ action: "save" }) fails or patterns don't persist
Solutions:
# Check patterns directory exists
ls -la ./patterns
# Create manually if needed
mkdir -p ./patterns
# Verify write permissions
touch ./patterns/test.json
rm ./patterns/test.json
# Check for invalid pattern names
# Valid: "techno-beat-1", "my_pattern", "track001"
# Invalid: "pattern/with/slashes", "name:with:colons"# Keyboard shortcut uses Meta (Cmd) key
# Already handled by ControlOrMeta
# If Chromium crashes on M1/M2:
npx playwright install chromium --with-deps# Install system dependencies
sudo npx playwright install-deps chromium
# If running in Docker/headless environment:
# Ensure config.json has headless: true# Use PowerShell or Git Bash
# Paths should use forward slashes in config.json
# If Chromium doesn't launch:
npx playwright install chromiumEnable Verbose Logging
# Set environment variable
DEBUG=* node dist/index.js
# Or in Claude:
You: Enable detailed logging for the next operationCheck Browser State
You: Show me the current browser initialization state
and any cached patterns
Claude: Browser state:
- Initialized: true
- Cached patterns: 2
- Undo stack depth: 5
- Last operation: edit_pattern (2.5s ago)Validate Pattern Syntax
You: Before playing, validate this pattern syntax:
s("bd*4, ~ cp ~ cp")
Claude: [Checks syntax]
Valid Strudel pattern.
Ready to play.If you encounter issues not covered here:
Check existing issues: GitHub Issues
Run integration tests: npm run test:integration
Enable debug mode: DEBUG=* npm start
Consult Strudel docs: Strudel.cc documentation
Create new issue: Include error messages, OS, Node version, and steps to reproduce
PRs welcome — bug fixes, docs, tests, new tools. See CONTRIBUTING.md for the contribution guide and DEVELOPMENT.md for setup and workflow.
For non-trivial work, open a GitHub issue first (issue policy in CLAUDE.md). For typos and small fixes, a PR directly is fine.
GitHub Discussions are open for use-case questions and design conversations.
AGPL-3.0-or-later — see LICENSE for the full text.
This project depends on @strudel/core, @strudel/mini, @strudel/tonal, and @strudel/transpiler, which are AGPL-3.0 licensed by the upstream Strudel project. Since we import from those packages and redistribute the combined work via npm, this project must be distributed under the same copyleft terms. If you fork or redistribute, you must keep the AGPL license and provide source access to any network-accessible users (AGPL §13).
Earlier versions of this package (including @williamzujkowski/strudel-mcp-server prior to deprecation) shipped with an MIT declaration — that was incorrect given the AGPL dependencies. v2.0.0 of @williamzujkowski/live-coding-music-mcp corrects the license to AGPL-3.0-or-later. v1.0.0 of this package is deprecated; install v2.0.0 or later (current: v4.0.0).
Strudel.cc — pattern-based live coding environment (this project is a fan adapter, not affiliated)
TidalCycles — original pattern language Strudel descends from
Anthropic — Claude and the MCP protocol
Playwright — browser automation
v4.0.0 — Open source, AGPL-3.0-or-later, experimental | Report issues | Contribute
This project is under active development. Core features work, but expect bugs and breaking changes. Not recommended for production use.
Gemini-backed pattern assistance. task=feedback returns creative critique on the current pattern (optionally with audio analysis). task=suggest analyzes the currently playing audio and suggests a complementary Strudel pattern as text (not auto-executed). task=jam generates a fresh layer (drums/bass/melody/pad/texture) and merges it into the current pattern, then auto-plays. All three share Gemini auth + rate limiting. Example: ai_assist({ task: "jam", layer: "bass" }). Requires GEMINI_API_KEY env var. For non-AI pattern generation use generate_part; for full compositions use compose.
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | Which AI task | |
| includeAudio | No | task=feedback: include audio analysis (default false) | |
| style | No | task=feedback/suggest: style hint | |
| role | No | task=suggest: role the suggested pattern fills (default complement) | |
| layer | No | task=jam: layer type to generate | |
| style_hint | No | task=jam: style guidance | |
| auto_play | No | task=jam: start playback after merge (default true) | |
| session_id | No | Optional session ID (#108). Omit to use default session. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses auth requirements, rate limiting, task-specific behaviors (e.g., jam merges and auto-plays, suggest returns text), and the optional audio analysis for feedback. However, it does not detail error handling or side effects of invalid inputs.
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 concise (7 sentences), front-loaded with the overall purpose, and structured clearly by task. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool (8 parameters, 3 tasks), the description covers all tasks, authentication, sibling alternatives, and provides a usage example. It adequately compensates for the lack of output schema by describing return behaviors.
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?
Input schema has 100% coverage, so baseline is 3. The description adds meaning by explaining how parameters relate to each task (e.g., includeAudio for feedback, layer for jam) and provides context 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 is a Gemini-backed pattern assistant with three distinct tasks (feedback, suggest, jam). It differentiates from siblings by recommending generate_part for non-AI generation and compose for full compositions.
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?
Explicit guidance is provided: when to use each task, prerequisites (GEMINI_API_KEY), and alternatives (generate_part, compose). An example invocation is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Audio analysis on the currently-playing pattern. include=["all"] (default) returns the full spectrum + features object, matching the pre-consolidation behaviour. include=["tempo"] returns only BPM with confidence. include=["key"] returns detected key + scale + confidence. include=["spectrum"] returns FFT features (bass, mid, treble, brightness, etc.). include=["rhythm"] returns rhythm-only analysis (complexity, density, syncopation). Combining values returns an object keyed by category, e.g. analyze({ include: ["tempo", "key"] }) → { tempo: {...}, key: {...} }. Example: analyze({ include: ["tempo"] }) to cheaply re-check BPM during a session. For static pattern analysis (no browser) use analyze_pattern_local; for runtime validation use validate_pattern_runtime.
| Name | Required | Description | Default |
|---|---|---|---|
| include | No | Which analyses to return. Default ["all"] preserves pre-consolidation behaviour. | |
| session_id | No | Optional session ID (#108). Omit to use default session. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes return structures for each include option, explains combining behavior, and mentions pre-consolidation behavior for 'all'. Lacks explicit read-only statement but overall transparent.
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?
Description is comprehensive but slightly lengthy; each sentence adds value and structure is clear. Could be more concise but still effective.
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?
No output schema, but description explains return values for each category. Covers main use cases and alternatives. Missing error handling but sufficient for most scenarios.
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% (baseline 3). Description adds meaning with explanations of enum values, default behavior, and examples of combining categories.
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?
Description clearly states 'Audio analysis on the currently-playing pattern' with specific analysis categories (tempo, key, spectrum, rhythm, all). Distinguishes from siblings analyze_pattern_local and validate_pattern_runtime.
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 provides when to use each include value, demonstrates with examples, and names alternatives: 'For static pattern analysis (no browser) use analyze_pattern_local; for runtime validation use validate_pattern_runtime.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Static analysis (events/cycle, complexity, optional BPM) without browser playback
| Name | Required | Description | Default |
|---|---|---|---|
| pattern | Yes | Pattern code to analyze |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior fully. It only states static analysis without browser playback, but omits whether it is read-only, output format, or any side effects. Insufficient for a tool with zero annotation coverage.
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 efficiently communicates the core purpose and key differentiator (no browser playback). 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?
With one parameter and no output schema, the description is minimal but covers the basics. However, it does not explain what the analysis returns or provide usage context (e.g., costs, limitations), leaving gaps for a full understanding.
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 baseline is 3. The description adds context about the analysis type but no additional meaning for the 'pattern' parameter beyond the schema. Adequate but not improved.
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?
Description specifies static analysis of events/cycle, complexity, and optional BPM, and explicitly excludes browser playback. This makes the purpose clear, though it does not explicitly state it is for patterns (implied by parameter name).
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?
No explicit guidance on when to use this tool vs alternatives like 'analyze' or 'validate_pattern_local'. The mention of 'without browser playback' hints at a scenario but does not name sibling tools or provide criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Record audio output from the live Strudel session. action=start begins streaming capture (optional format webm/opus, default webm). action=stop ends the stream and returns base64-encoded audio. action=sample captures a fixed-duration window in one call (100-60000ms, default 5000ms). Example: audio_capture({ action: "sample", duration: 3000 }). Audio must be playing for capture to record meaningful data. For MIDI export use export_midi; for runtime diagnostics use diagnostics. Note: the AudioCaptureService is currently a server-wide singleton — concurrent captures across sessions will conflict.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Capture action | |
| format | No | action=start: audio format (default webm) | |
| maxDuration | No | action=start: maximum capture duration ms | |
| duration | No | action=sample: duration ms (100-60000, default 5000) | |
| session_id | No | Optional session ID (#108). Routes page reference to the named session. Note: AudioCaptureService is currently server-wide — concurrent captures across sessions will conflict. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses singleton conflict (server-wide), requirement that audio must be playing, and return values (base64 for sample). Could be more explicit about error handling (e.g., stop without start), but overall sufficient.
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?
Well-structured, front-loaded with purpose, then actions, example, alternatives, and caveat. Every sentence adds value, though slightly verbose. Could be tightened slightly but still effective.
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?
No output schema or annotations, but description covers actions, required audio, singleton conflict, and example. Lacks error scenarios and full return format details, but given complexity of a 5-param tool, it is reasonably complete.
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%, baseline 3. Description adds significant context: explains each action's behavior against the action enum, and provides important caveat about concurrent conflict for session_id. This exceeds baseline.
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 records audio output from live Strudel session. Distinguishes actions (start, stop, sample) and explicitly mentions alternatives (export_midi, diagnostics), making it distinguishable from 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?
Provides explicit when-to-use guidance for each action (start, stop, sample) and context that audio must be playing. Also gives alternatives for MIDI export and diagnostics, excluding inappropriate uses.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Interact with the visible Strudel browser window. action=show brings the window to the foreground. action=screenshot captures the current editor view to disk (optional filename). Example: browser_window({ action: "screenshot", filename: "demo.png" }). For diagnostics (status/errors/perf) use diagnostics; for the editor itself use edit_pattern.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Window action | |
| filename | No | action=screenshot: optional output filename | |
| session_id | No | Optional session ID (#108). Omit to use default session. compose auto-init only applies to default session — named sessions must already exist. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description discloses that 'show brings window to foreground' and 'screenshot captures editor view to disk.' It also explains session_id behavior regarding compose auto-init. Minor omission: no mention of error states or file overwrite 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?
Concise, four sentences: purpose, two actions with brief explanation, example, and cross-reference to siblings. No 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?
Given no output schema and three parameters with one required, description covers main use cases. Includes example and alternatives. Could mention what happens on failure (e.g., screenshot to existing file) but overall sufficient.
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?
Input schema has 100% coverage of parameters with descriptions. The description adds minimal value beyond schema with an example for filename, but no additional semantic explanation for action or session_id that isn't already in 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?
Description clearly states it interacts with the Strudel browser window and lists two specific actions (show, screenshot). It distinguishes from sibling tools by referencing diagnostics and edit_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?
Provides explicit alternatives: 'For diagnostics use diagnostics; for the editor itself use edit_pattern.' Also includes an example and clarifies when to use session_id.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate, write, and play a complete pattern in one step. Auto-initializes default browser if needed.
| Name | Required | Description | Default |
|---|---|---|---|
| style | Yes | Genre: techno, house, dnb, ambient, trap, jungle, jazz, experimental | |
| tempo | No | BPM (default: genre-appropriate) | |
| key | No | Musical key (default: C) | |
| auto_play | No | Start playback immediately (default: true) | |
| get_feedback | No | Get AI feedback on the generated pattern (default: false) | |
| session_id | No | Optional session ID (#108). Omit to use default session. compose auto-init only applies to default session — named sessions must already exist. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses auto-initialization of the default browser, but does not indicate whether the operation is destructive (e.g., overwrites existing patterns), requires session prerequisites, or what the side effects are for the 'write' and 'play' actions.
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?
Two sentences (21 words) conveying the core purpose and a key behavioral note. Extremely concise and 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?
Despite the tool having 6 parameters and no output schema, the description is minimal. It does not explain what the tool returns, error scenarios, prerequisites (beyond browser), or how it interacts with the session system. For a complex generative tool, this leaves significant gaps.
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?
Input schema coverage is 100%, so baseline is 3. The description adds no parameter-specific information beyond what the schema already provides (e.g., no explanation of 'style' options or 'session_id' behavior). The brief mention of browser initialization is only tangentially related.
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 action ('Generate, write, and play a complete pattern in one step') and implies a combined workflow, distinguishing it from sibling tools that handle individual steps. However, it does not explicitly name alternatives or define what 'pattern' means.
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?
No guidance is given on when to use this tool versus other pattern-related tools. The description only mentions auto-initialization of the browser, which is a technical detail rather than usage context. There are no when-not or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect server and browser state. level=status returns a quick state snapshot (cache read, <15ms SLA). level=full returns detailed browser diagnostics including caches, errors, and performance. level=perf returns server-side timing metrics + top bottlenecks. level=memory returns process memory usage. level=errors returns captured console errors and warnings from Strudel. Default level=full preserves the pre-consolidation behaviour. Example: diagnostics({ level: "status" }) — millisecond-cheap. For screenshots use browser_window; for tool listings use the strudel://docs/tools resource.
| Name | Required | Description | Default |
|---|---|---|---|
| level | No | Which diagnostic surface to read (default: full) | |
| session_id | No | Optional session ID (#108). Applies to level=status, full, errors. Ignored for perf/memory (server-wide metrics). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It details what each level returns (e.g., 'server-side timing metrics + top bottlenecks' for perf), mentions the <15ms SLA for status, and explains that the default 'full' preserves pre-consolidation behavior. It also clarifies which parameters apply to which levels (session_id ignored for perf/memory). This is thorough.
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 moderately long but well-structured: it starts with the general purpose, then lists each level with its output, provides a default, and ends with an example and sibling references. Every sentence adds value, though some could be more concise.
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 no output schema, the description adequately explains return values for each level. It covers parameters (2, none required), clarifies dependency of session_id on levels, and mentions SLA. For a tool with moderate complexity (multiple modes, optional session ID), it is sufficiently complete.
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% (both parameters described). The description adds value by specifying that 'level' defaults to 'full', indicating that 'session_id' applies only to certain levels, and providing an example usage. This goes 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 states it inspects server and browser state, lists five specific diagnostic levels (status, full, perf, memory, errors), and explicitly distinguishes from sibling tool browser_window and resource strudel://docs/tools. This makes its purpose and scope very clear.
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 explains when to use each level (e.g., 'level=status returns a quick snapshot'), provides an SLA, notes the default behavior, and gives an example. It also tells when not to use this tool (for screenshots, use browser_window; for tool listings, use strudel://docs/tools). However, it doesn't explicitly state when to avoid using diagnostics entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mutate the current session pattern. mode=write replaces the editor contents (default; mirrors the old write tool exactly, including optional pattern validation and auto_play). mode=append concatenates code after the current pattern with a newline. mode=insert places code at the given line position. mode=replace runs a single string-replace from search to replace. mode=clear empties the editor. Example: edit_pattern({ mode: "write", pattern: "s("bd")", auto_play: true }). For reading the editor without mutating it use get_pattern; for the on-disk pattern catalog use pattern_store.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Which edit operation to perform (default: write) | |
| pattern | No | Pattern code (mode=write) | |
| code | No | Code to append/insert (mode=append/insert) | |
| position | No | Line number (mode=insert) | |
| search | No | Text to replace (mode=replace) | |
| replace | No | Replacement text (mode=replace) | |
| auto_play | No | Start playback after write (mode=write only, default: false) | |
| validate | No | Validate pattern before write (mode=write only, default: true) | |
| session_id | No | Optional session ID (#108). Omit to use default session. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description fully discloses mutation behavior, defaults (mode=write, validate=true, auto_play=false), and mode semantics. 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?
Description is moderately long but efficiently structured: first sentence general, then mode-by-mode, example, sibling differentiation. Every sentence serves a purpose; 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?
Given 9 parameters, 0 required, 5 modes, and no output schema, the description covers all modes, all parameters in context, and includes an example. No gaps remain.
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%, baseline 3. Description adds value by associating each parameter with the relevant mode (e.g., pattern for write, code for append/insert), beyond schema's standalone descriptions.
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?
Describes specific verb 'mutate' for 'current session pattern' and lists all five modes. Distinguishes from siblings get_pattern (reading) and pattern_store (on-disk catalog) 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?
Provides explicit guidance per mode with parameters and an example. Tells when not to use: use get_pattern for reading, pattern_store for catalog.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add or remove a Strudel effect on the current session pattern. action=add appends .<effect>(<params>). action=remove strips the last .<effect>(...) call from the pattern. Example: effect({ action: "add", effect: "lpf", params: "1000" }). For higher-level effect bundles (mood/energy/refine) use shape; for raw transforms use transform.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | add or remove the effect | |
| effect | Yes | Effect name (e.g. lpf, room, delay) | |
| params | No | Effect parameters (action=add only) | |
| session_id | No | Optional session ID (#108). Omit to use default session. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While no annotations are provided, the description discloses basic behavior (appending/stripping effect calls). However, it lacks details on side effects, error handling, or state changes beyond the pattern modification.
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?
Two sentences plus an example. Front-loaded with purpose, no wasted words. Efficient and easy to parse.
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 no output schema, the description implies the pattern is modified but doesn't specify return value or error conditions (e.g., removing a non-existing effect). Completeness is adequate but not thorough.
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%, but the description adds value by providing an example, listing effect examples (lpf, room, delay), and clarifying that params is only for action=add. This goes beyond the schema's static descriptions.
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?
Description clearly states the tool adds or removes a Strudel effect on the current session pattern. It specifies verbs 'add' and 'remove' and the resource 'pattern effect', and distinguishes from sibling tools 'shape' and 'transform'.
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 explains when to use each action (add appends, remove strips) and provides an example. Also differentiates from 'shape' for higher-level effect bundles and 'transform' for raw transforms.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export current pattern to MIDI file. Parses note(), n(), and chord() functions.
| Name | Required | Description | Default |
|---|---|---|---|
| filename | No | Output filename (optional, default: pattern.mid) | |
| duration | No | Export duration in bars (default: 4) | |
| bpm | No | Tempo in BPM (default: 120) | |
| format | No | Output format: file or base64 (default: base64) | |
| session_id | No | Optional session ID (#108). Routes page reference to the named session. Note: AudioCaptureService is currently server-wide — concurrent captures across sessions will conflict. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must carry the burden of behavioral disclosure. It does not mention side effects, error conditions, or whether the pattern is modified. The session_id parameter description seems unrelated to MIDI export, adding confusion.
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 two sentences, front-loaded with the main action. Every word adds value with no redundancy.
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 no output schema and 5 optional parameters, the description omits output format details, success/error handling, and typical usage scenarios. For a music domain tool, this is insufficient.
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 parameters are already well-documented. The description adds no additional parameter context beyond the schema, achieving baseline 3.
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 exports the current pattern to a MIDI file and specifies that it parses note(), n(), and chord() functions. This differentiates it from sibling tools like import_midi.
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?
No guidance is provided on when to use this tool versus alternatives (e.g., import_midi or other export formats). An AI agent lacks context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a single instrumental layer and append it to the current session pattern. role=drums takes style (e.g. "techno"/"house") and optional complexity 0-1. role=bass takes key (e.g. "C") + style. role=melody takes root/scale (e.g. C/minor) and optional length (notes). role=fill takes style and optional bars. Example: generate_part({ role: "drums", style: "techno", complexity: 0.7 }). For full compositions use compose; for rhythmic patterns use generate_rhythm; for music-theory queries use music_theory.
| Name | Required | Description | Default |
|---|---|---|---|
| role | Yes | Which part to generate | |
| style | No | role=drums/bass/fill: musical style | |
| complexity | No | role=drums: complexity 0-1 (default 0.5) | |
| key | No | role=bass: musical key | |
| root | No | role=melody: root note | |
| scale | No | role=melody: scale name | |
| length | No | role=melody: number of notes (default 8) | |
| bars | No | role=fill: number of bars (default 1) | |
| session_id | No | Optional session ID (#108). Omit to use default session. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description discloses mutation ('append it to the current session pattern') but lacks details on reversibility, error handling, or session management beyond session_id. No annotations provided to offset; would benefit from noting side effects more fully.
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?
Description is well-structured with role-specific paragraphs, an example, and a final line for sibling differentiation. Every sentence is informative, no 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?
Covers all roles, defaults, and examples. Lacks return value description (no output schema), which would aid agent understanding of what to expect. Otherwise thorough for a generative tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description adds conditional per-role parameter usage (e.g., role=drums takes style, complexity; role=melody takes root/scale), which significantly aids parameter selection beyond schema's flat listing.
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?
Description uses specific verb 'Generate' and distinct resource 'single instrumental layer' appended to session pattern. It clearly differentiates from siblings by naming alternatives (compose, generate_rhythm, music_theory).
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 this tool vs alternatives: 'For full compositions use compose; for rhythmic patterns use generate_rhythm; for music-theory queries use music_theory.' Also provides an example call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a rhythmic pattern and append it to the current session. type=euclidean produces a Euclidean rhythm with hits evenly distributed across steps (optional sound param, default "bd"). type=polyrhythm overlays multiple sound layers with given pattern numbers. Example: generate_rhythm({ type: "euclidean", hits: 3, steps: 8, sound: "hh" }). For complete patterns (drums/bass/melody) use generate_part; for whole compositions use compose.
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | Rhythm type | |
| hits | No | type=euclidean: hits count | |
| steps | No | type=euclidean: total steps | |
| sound | No | type=euclidean: sound to use (default bd) | |
| sounds | No | type=polyrhythm: sounds per layer | |
| patterns | No | type=polyrhythm: pattern numbers per layer | |
| session_id | No | Optional session ID (#108). Omit to use default session. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It explains the two modes and that the pattern is appended (state mutation). However, it does not detail side effects (e.g., overwriting, error handling) or prerequisites like session existence. This is adequate but not thorough.
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 concise (4 sentences) and well-structured: purpose first, then type explanations with example, then sibling alternatives. Every sentence adds value without redundancy.
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 tool with 7 parameters and mutation behavior, the description covers types, parameters, and alternatives. However, it lacks details on return value or error conditions. With no output schema, a note on what the tool returns would improve completeness.
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%, baseline 3. The description adds meaning by linking parameters to types (e.g., 'hits evenly distributed across steps') and stating defaults (sound default 'bd'). This enriches understanding 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 generates a rhythmic pattern and appends it to the current session. It specifies two types (euclidean, polyrhythm) and distinguishes itself from generate_part and compose, making the purpose unambiguous and differentiating it from 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?
Explicit guidance is provided: use generate_part for complete patterns and compose for whole compositions. The example demonstrates correct invocation, and the parameter descriptions clarify when each type applies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current pattern code
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | No | Optional session ID (#108). Omit to use default session. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits. It does not state whether the operation is read-only, has side effects, or requires specific permissions.
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 extremely concise but at the cost of missing important context. It is not verbose, but it does not add value beyond the bare minimum.
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 lack of output schema and the presence of many sibling tools, the description fails to provide enough context to understand what 'pattern code' is, what the tool returns, or how it relates to other pattern tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with a clear description for the session_id parameter. The description adds no further value beyond the schema, but the schema itself is adequate, 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 states the tool gets the current pattern code, identifying the verb and resource. However, 'pattern code' is somewhat vague without further context, and the description does not differentiate from similar sibling tools like 'query_pattern_events' or 'analyze_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?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of context, prerequisites, or exclusion criteria, leaving the agent to guess.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Navigate or inspect the pattern edit history. action=undo reverts the last edit on the targeted session. action=redo replays a previously-undone edit. action=list returns recent entries with timestamps and previews (limit defaults to 10). action=restore jumps the editor to a specific entry by id (current pattern goes on the undo stack). action=compare diffs two entries by id (or one entry vs current pattern). Example: history({ action: "list", limit: 5 }) — recent edits, newest first. For on-disk saved patterns use pattern_store — history deals with the in-memory edit timeline of the current session.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Which history operation to perform | |
| limit | No | Maximum entries (action=list, default 10) | |
| id | No | History entry ID (action=restore) | |
| id1 | No | First entry ID (action=compare) | |
| id2 | No | Second entry ID (action=compare, default: current pattern) | |
| session_id | No | Optional session ID (#108). Omit to use default session. Note: undo/redo/history stacks are currently server-wide; only the read/write target changes. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behaviors: undo reverts, redo replays, restore pushes current onto undo stack, compare diffs with defaults. It lacks details on side effects (e.g., idempotency) but covers the main 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 two short paragraphs, front-loaded with the purpose and actions, followed by an example and sibling distinction. Every sentence is informative, with no redundancy.
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 six parameters and no output schema or annotations, the description covers all actions, parameters, defaults, and an example. It omits error scenarios but is otherwise sufficient for an agent to use the tool 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%, but the description adds context beyond schema: it explains default limit (10), default id2 (current pattern), and the undo-stack effect of restore. This additional behavioral information enhances parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool navigates or inspects the pattern edit history, listing all five actions with clear verb-resource pairs. It explicitly contrasts with sibling tool pattern_store (in-memory vs on-disk), fully distinguishing its purpose.
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 explains when to use each action and provides an example. It explicitly directs users to pattern_store for on-disk patterns, though it does not cover all sibling tools or edge cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert a .mid file into a playable Strudel pattern (Phase 1: literal transcription, #201). Use source="base64" with data= for inline bytes, or source="path" with data= to read from the patterns/midi/ directory (path traversal blocked). Drum tracks (MIDI channel 10) emit one s() lane per sample so simultaneous kicks/hats do not collide. Pitched tracks emit note("...").s("piano") with simultaneous notes merged into [a,b,c] chord tokens. Phase 2+ (structural compression, voice separation, LLM idiomatic pass) tracked in separate issues. Example: import_midi({ source: "path", data: "drumloop.mid", steps_per_cycle: 16 }). For the reverse direction (Strudel → MIDI) use the analyze tool with task="export_midi".
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes | How to interpret `data` — raw base64 bytes or a filename under patterns/midi/ | |
| data | Yes | For source=base64: base64-encoded .mid bytes (≤1MB decoded). For source=path: basename of a .mid file under ./patterns/midi/ (path-traversal blocked). | |
| steps_per_cycle | No | Grid resolution per bar (integer 1-64). Default 16. | |
| bars | No | Cap on bars to emit. Default: full file. | |
| drum_map | No | Optional override / extension to the default GM percussion map. Keys are MIDI note numbers (as strings, since JSON object keys), values are Strudel sample names. Example: { "60": "cp", "61": "rim" }. Unmapped drums fall back to rests and are surfaced in the result summary. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description thoroughly discloses behavioral traits: file source constraints, drum track handling (s() lanes for non-collision), pitched track output (note().s('piano') and chord merging), and reference to future phases. This compensates for the lack of 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 efficient, front-loading the main purpose, then detailing source options, behavior, and an example. Every sentence adds value, though it could be slightly more structured with bullet points.
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 parameter count, lack of output schema, and no annotations, the description is quite complete. It covers input formats, behavior for drum and pitched tracks, and future phases. It does not fully specify the output structure of the pattern, but the example implies a pattern object.
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?
While the schema covers 100% of parameters and descriptions, the description adds meaningful context beyond the schema: explains the default for steps_per_cycle, the drum_map override behavior, and that unmapped drums result in rests surfaced in the summary.
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 converts a .mid file into a playable Strudel pattern, with specific mention of Phase 1 literal transcription. It distinguishes from the sibling tool export_midi by explicitly noting the reverse direction.
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 explains when to use source='base64' vs source='path', mentions path traversal blocking, and provides an example. It also indicates the reverse direction via analyze tool. However, it does not explicitly state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Initialize Strudel in browser
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as side effects, required permissions, or state changes. 'Initialize' implies setup but lacks specifics.
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, concise sentence that is front-loaded. It avoids verbosity, but could benefit from a bit more context without sacrificing 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?
Given no parameters, the description is minimally complete. However, the absence of output schema and annotations means the agent gains little insight into what initialization entails, which is a gap for a potentially impactful action.
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 tool has no parameters, so schema coverage is 100%. The description adds no parameter information but is not required to; baseline of 4 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 'Initialize' and the resource 'Strudel', indicating it sets up the Strudel environment. However, it does not differentiate from sibling tools like 'session' or 'browser_window' which might have overlapping 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?
No guidance is provided on when to use this tool versus alternatives. The description lacks context about prerequisites or typical usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Music-theory queries. query=scale returns the notes of a scale (e.g. "C major scale: C, D, E, F, G, A, B"). query=chord_progression returns a chord progression for the key/style AND writes the resulting chord pattern into the current session. Example: music_theory({ query: "scale", root: "C", scale: "major" }). For pattern generation (drums/bass/melody) use generate_part; for rhythmic patterns use generate_rhythm.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Which theory query | |
| root | No | Root note (query=scale; also used as key for chord_progression) | |
| scale | No | Scale type (query=scale) | |
| key | No | Key (query=chord_progression) | |
| style | No | Style (query=chord_progression: pop/jazz/blues/etc) | |
| session_id | No | Optional session ID (#108). Omit to use default session. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that chord_progression writes into the current session (side effect) and explains the output format for scale queries. However, it does not detail the chord progression output format or any error conditions.
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 concise (4 sentences) and front-loaded with the core purpose. Each sentence adds distinct value, including an example and sibling tool references.
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 6 parameters, no output schema, and a moderate complexity domain, the description is fairly complete. It covers both query types, inputs, side effects, and alternatives. Missing the exact output format for chord_progression prevents 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 coverage is 100% but description adds value: it explains that root also serves as key for chord_progression, gives an example usage, and illustrates the scale output format. This goes beyond the schema's parameter descriptions.
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 is for music-theory queries, detailing two query types (scale and chord_progression) with specific outputs. It distinguishes from sibling tools (generate_part, generate_rhythm) by explicitly stating their use cases.
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 guidance on when to use alternatives: 'For pattern generation (drums/bass/melody) use generate_part; for rhythmic patterns use generate_rhythm.' It also includes a concrete example.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Persist patterns to disk and read them back. Use action=save to write the current session pattern under a name; action=load to restore a named pattern into the current session; action=list to enumerate the on-disk catalog (optionally filtered by tag). Example: pattern_store({ action: "save", name: "my-jam", tags: ["techno"] }). For session lifecycle (create/destroy/list active sessions) use the session tool — pattern_store deals with on-disk patterns, not runtime sessions.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Which on-disk operation to perform | |
| name | No | Pattern name (required for save/load) | |
| tags | No | Tags to attach (save only) | |
| tag | No | Filter by tag (list only) | |
| session_id | No | Optional session ID (#108). Sources/targets the named session's current pattern; the on-disk catalog is shared across sessions. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description explains the behavioral intent of each action. However, it does not disclose potential side effects (e.g., overwriting on save, error on load of missing name) or details about the list output format. The session_id parameter is mentioned but its behavior when omitted is not fully explained.
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 core purpose and is relatively concise. It uses a semicolon-separated list for actions, which is efficient. However, it could be slightly shorter by omitting the example, though the example aids clarity.
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 (5 parameters, 3 actions, no output schema), the description covers the primary operations and sibling differentiation. However, it omits important details such as error conditions (e.g., what happens if name is missing for load), behavior of session_id when not provided, and any constraints (e.g., maximum pattern size or naming rules). The lack of output schema makes return value information absent.
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 has 100% description coverage, so the baseline is 3. The description adds value by clarifying the roles of action in a compact summary and by providing a usage example. It also explains the session_id parameter's cross-session sharing aspect, which goes beyond the 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 clearly states 'Persist patterns to disk and read them back' and enumerates three distinct actions (save, load, list). It explicitly distinguishes itself from the sibling tool 'session' by stating the scope is on-disk patterns, not runtime sessions.
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 explicit guidance: 'For session lifecycle (create/destroy/list active sessions) use the session tool — pattern_store deals with on-disk patterns, not runtime sessions.' Also includes an example call pattern.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Control transport on the current session. action=play starts the editor pattern. action=pause stops without resetting clock. action=stop ends playback. Example: playback({ action: "play" }). For pattern editing use edit_pattern; for tempo use set_tempo.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Transport action | |
| session_id | No | Optional session ID (#108). Omit to use default session. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adequately describes each action's effect (play starts editor pattern, pause stops without resetting clock, stop ends playback). Lacks detail on state resets or session requirements.
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?
Compact and well-structured: purpose first, then actions, example, and cross-references. Every sentence adds value.
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 simple schema (2 params, enum) and no output schema, the description fully covers usage, behavior, and alternatives. No gaps identified.
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%, but description adds meaning to action enum (play/pause/stop behaviors) and clarifies session_id optionality, exceeding baseline 3.
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 'Control transport on the current session' and lists specific actions (play, pause, stop), distinguishing itself from siblings like edit_pattern and set_tempo.
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 explicit actions and example, and directs when to use alternative tools (edit_pattern, set_tempo). Could further clarify prerequisites like session readiness.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Enumerate events the pattern would emit between two cycle indices (max 16 cycles)
| Name | Required | Description | Default |
|---|---|---|---|
| pattern | Yes | Pattern code to query | |
| start | No | Start cycle (default 0) | |
| end | No | End cycle (default 1) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the max cycle range (16 cycles) and the action (enumerate events), but omits behavioral details such as whether the tool is read-only, side effects, or error handling. Some transparency is present but incomplete.
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, front-loaded sentence with no filler. Every word contributes to understanding the tool's purpose and constraints.
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 no output schema and low complexity (3 params), the description adequately covers the core functionality. It states the action, range constraint, and max cycles. However, it could mention prerequisites (e.g., pattern existence) or return format.
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?
Input schema has 100% description coverage, so the schema already defines parameters. The description adds no extra semantic context beyond the schema's descriptions. Baseline score 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 uses the specific verb 'enumerate' and clearly states the resource ('events') and scope ('between two cycle indices, max 16 cycles'). It differentiates from siblings like 'get_pattern' by focusing on emitted events rather than the pattern itself.
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 alternatives, nor does it mention scenarios where it should not be used. The usage context is implied only through the tool's name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage isolated Strudel browser sessions (multi-session, #108). action=create starts a new named session (sessions share one browser but isolated contexts). action=destroy closes a named session and releases its resources. action=list returns metadata for all active sessions (id, created, last_activity, is_playing, is_default). action=switch changes the default session that subsequent tool calls route to when no session_id is passed. Example: session({ action: "create", session_id: "live-set-1" }). For the on-disk pattern catalog use pattern_store(action=list) — session(action=list) lists runtime sessions, not saved patterns.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Session lifecycle action | |
| session_id | No | Session identifier (required for create/destroy/switch) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behaviors: sessions share a browser but have isolated contexts, destroy releases resources, switch changes routing for subsequent calls. However, it omits potential error conditions (e.g., invalid session_id).
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, starting with a clear one-line summary, then breaking down each action in bullet-like format, and ending with a contrast to a sibling tool. No superfluous 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?
Despite lacking annotations and output schema, the description covers all actions, explains the shared-browser-but-isolated-context behavior, and distinguishes from a sibling tool. It provides an example and sufficient detail for an agent to use the tool 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% with descriptions for both parameters. The description adds context for each action value but does not significantly extend the schema's semantic detail beyond the provided enum and parameter descriptions.
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 the tool as managing isolated browser sessions, explicitly differentiates from the sibling pattern_store by contrasting runtime sessions vs. on-disk patterns, and uses specific verb-resource pairs for each action (e.g., 'starts a new named session').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance for each action (create, destroy, list, switch) and directly advises when to use the sibling pattern_store instead, establishing clear usage boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set BPM
| Name | Required | Description | Default |
|---|---|---|---|
| bpm | Yes | Tempo in BPM | |
| session_id | No | Optional session ID (#108). Omit to use default session. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must reveal behavioral traits. It only states 'Set BPM', without disclosing side effects, permissions needed, or whether the change is destructive. The agent cannot infer if this is a safe operation or if it affects other settings.
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 extremely concise (two words), but lacks any structure or additional context. It is not verbose, but it sacrifices helpfulness. A balanced description would include a sentence on usage context.
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 tool's simplicity (2 params, no output schema), the description should still explain the effect on the session, return value, and relationship to other tempo-related siblings. It fails to do so, leaving the agent with insufficient 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 description coverage is 100%, so the input schema already explains both parameters. The description adds no additional meaning beyond what the schema provides. Baseline 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 'Set BPM' clearly states the action and resource (tempo/BPM). It is specific enough to understand the tool's primary function, though it lacks differentiation from sibling tools that might also modify tempo.
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?
No guidance is provided on when to use this tool versus alternatives. The optional session_id parameter hints at context, but the description does not explain when to include it or exclude it, nor does it mention any prerequisites or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Shape the current pattern along one of three high-level dimensions. dimension=mood applies a mood profile (dark/euphoric/melancholic/aggressive/dreamy/peaceful/energetic) with optional intensity 0-1. dimension=energy applies an energy level (integer 0-10). dimension=refine applies a directional refinement: faster/slower/louder/quieter/brighter/darker/"more reverb"/drier. All three auto-play by default. Example: shape({ dimension: "mood", target_mood: "dark", intensity: 0.8 }). For raw transform ops use transform; for explicit effects use effect.
| Name | Required | Description | Default |
|---|---|---|---|
| dimension | Yes | Which dimension to shape along | |
| target_mood | No | dimension=mood: target mood | |
| intensity | No | dimension=mood: intensity 0-1 (default 0.5) | |
| level | No | dimension=energy: integer level 0-10 | |
| direction | No | dimension=refine: faster, slower, louder, quieter, brighter, darker, "more reverb", drier | |
| auto_play | No | Start playback after shape (default true) | |
| session_id | No | Optional session ID (#108). Omit to use default session. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that all dimensions auto-play by default and mentions optional intensity with a default of 0.5. However, it does not explicitly state whether the shape operation is non-destructive or what the return value is, leaving some behavioral gaps.
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 paragraph that front-loads the main action and then details each dimension. All sentences are informative, but it could be slightly more concise by grouping the dimension descriptions more tightly. Still, it is well-structured and avoids redundancy.
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 tool has 7 parameters and no output schema, the description covers the core functionality well, including usage context and sibling differentiation. However, it lacks details on the return value or confirmation of success/failure, which would be helpful for an agent to fully understand the tool's effect.
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 all parameters described. The description adds significant value beyond the schema by explaining the meaning of each dimension, providing the example with target_mood and intensity, clarifying default values (intensity 0.5, auto_play true), and listing valid options for each dimension. This greatly aids parameter selection.
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: 'Shape the current pattern along one of three high-level dimensions.' It lists the three dimensions (mood, energy, refine) with specific examples and distinguishes itself from sibling tools by explicitly directing users to 'transform' for raw transforms and 'effect' for explicit effects.
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 guidance on when to use each dimension (mood, energy, refine) with their respective parameters. It also tells users when not to use this tool, directing them to 'transform' for raw operations and 'effect' for effects. An example usage is included, making the expected call pattern clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Apply a single transform op to the current session pattern. op=transpose shifts notes by semitones. op=reverse appends .rev to the pattern. op=stretch slows by factor (>1 slower, <1 faster). op=quantize snaps to the grid (e.g. "1/16"). op=humanize adds rand-nudge timing of amount (0-1). op=swing applies .swing(amount). op=scale applies a root/scale filter to notes. op=vary returns a variation of type (subtle/moderate/extreme/glitch/evolving). Example: transform({ op: "transpose", semitones: 7 }). For effects (add/remove) use effect; for mood/energy/refine use shape; for tempo use set_tempo.
| Name | Required | Description | Default |
|---|---|---|---|
| op | Yes | Which transform to apply | |
| semitones | No | op=transpose: integer semitones to shift | |
| factor | No | op=stretch: stretch factor | |
| grid | No | op=quantize: grid size (e.g. "1/16") | |
| amount | No | op=humanize/swing: amount 0-1 | |
| root | No | op=scale: root note (e.g. "C") | |
| scale | No | op=scale: scale name (e.g. "minor") | |
| type | No | op=vary: variation type (subtle/moderate/extreme/glitch/evolving) | |
| session_id | No | Optional session ID (#108). Omit to use default session. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes behavioral traits for each op, including side effects like appending '.rev' for reverse and mutating the session pattern. No annotations provided, so description carries burden well, though it could mention whether changes are reversible.
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 paragraph but is well-organized and front-loaded with the purpose. It efficiently covers all ops without excessive length. Could be slightly more structured with bullets, but still concise.
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 (9 parameters, 8 ops) and absence of output schema, the description covers all necessary details, including an example and differentiation from siblings. No gaps identified.
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 descriptions, but the description adds significant meaning by explaining each op's effect and parameter usage. Includes an example for transpose, which goes beyond schema bare descriptions.
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 applies a single transform operation to the current session pattern. It lists all eight ops and their effects, and differentiates from sibling tools like effect, shape, and set_tempo.
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 tells when to use this tool vs alternatives: 'For effects (add/remove) use effect; for mood/energy/refine use shape; for tempo use set_tempo.' Provides clear context and exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Transpile pattern source via StrudelEngine; returns transpiled code or syntax error
| Name | Required | Description | Default |
|---|---|---|---|
| pattern | Yes | Pattern code to transpile |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only mentions it returns transpiled code or a syntax error, but does not disclose side effects, safety (read-only or destructive), or any behavioral traits beyond the basic purpose. The agent is left uninformed about whether this modifies state or has prerequisites.
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 sentence that efficiently states the action, engine, and result. No unnecessary words; every part 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?
For a single-param read tool, the description covers the basic purpose, but without annotations or output schema, it lacks detail on return value format and precise behavior. It is minimally adequate but could benefit from explaining what 'transpiled code' looks like or when errors occur.
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 has 100% coverage with a description for the single 'pattern' parameter: 'Pattern code to transpile'. The description does not add further meaning beyond what the schema already provides (e.g., format, constraints, examples). Baseline 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 'transpile', the resource 'pattern source via StrudelEngine', and the outcome ('returns transpiled code or syntax error'). This distinguishes it from sibling tools like 'validate_pattern_local' or 'analyze_pattern_local', though it could be more specific about what transpilation entails.
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 no guidance on when to use this tool versus alternatives. No when-to-use, when-not-to-use, or comparison with siblings is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate pattern syntax against the in-process StrudelEngine (no browser required)
| Name | Required | Description | Default |
|---|---|---|---|
| pattern | Yes | Pattern code to validate |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description should cover behavioral aspects. It only states validation and engine context, omitting side effects, permissions, errors, or output format.
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 efficiently conveys core purpose and key differentiator (no browser required) with no waste.
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 simple 1-param tool, the description is adequate but lacks any usage context or details about return values, which could help the 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?
With 100% schema coverage, the description adds no additional meaning to the 'pattern' parameter beyond the schema's 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 explicitly states the tool validates pattern syntax using an in-process StrudelEngine, clearly distinguishing it from sibling 'validate_pattern_runtime' which likely requires a browser.
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?
No guidance on when to use this tool vs alternatives like validate_pattern_runtime. The agent is left to infer context from the description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate pattern with runtime error checking (monitors Strudel console for errors)
| Name | Required | Description | Default |
|---|---|---|---|
| pattern | Yes | Pattern code to validate | |
| waitMs | No | How long to wait for errors (default 500ms) | |
| session_id | No | Optional session ID (#108). Omit to use default session. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that it monitors the Strudel console for errors, but does not mention side effects of executing the pattern or any required permissions.
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?
Efficient single sentence with no waste.
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?
Lacks details about return format, error behavior, and potential for pattern execution side effects; adequate but not complete.
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%, description adds no additional meaning to parameters beyond schema definitions.
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 validates a pattern with runtime error checking, distinguishing it from siblings like validate_pattern_local (static) and analyze (general).
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?
No explicit guidance on when to use this vs alternatives like validate_pattern_local; usage implied but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Most tools have distinct purposes, but there is some overlap among analysis tools (analyze, analyze_pattern_local, diagnostics) and pattern modification tools (transform, effect, shape). Descriptions help differentiate, but agents might still select incorrectly without careful reading.
Tool names generally follow a verb_noun pattern, but a few are single verbs (analyze, compose, init). The style is mostly consistent with underscores, but occasional lack of underscores (e.g., ai_assist) is acceptable. Overall predictable.
27 tools is on the high side for a server focused on pattern generation. While they cover many aspects, some tools like query_pattern_events are niche. The count feels slightly excessive but still manageable.
The tool surface covers the full lifecycle: creation, editing, analysis, playback, persistence, session management, and audio export. A few gaps like tempo automation exist, but the overall set is well-scoped for the domain.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Music studio: ABC notation composition and Strudel live coding with ext-apps UI.
AI-powered browser automation — navigate, click, fill forms, and extract data from any website.
Generate AI music via the Lacuna Music API from MCP clients like Claude Desktop & Code.
AI-powered web automation. Navigate websites using AI agents for one page or a thousand
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/williamzujkowski/live-coding-music-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
