How do I use Epistemic DJ?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Epistemic DJ Generate a pattern for epistemic state: know=0.7, uncertainty=0.2, engagement=0.9" 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.

Epistemic DJ

Official

by Nubaeon

Overview Schema Source Related Servers Discussions Admin

Python

Remote

🎧 Epistemic DJ

TL;DR: Most music tools are one of two things — an app that just plays you stuff (Spotify), or a full production studio you need years to learn (a DAW). Nothing in between for people who want to shape their listening without becoming a producer. epistemic-dj is that middle ground: it learns what you actually like — not by watching what you skip, but by asking you and by really listening to your tracks — and keeps a record of why, so "why did you play me this" has a real answer instead of a shrug. With that, it can find you more of what you'd genuinely want, and build actual mashups: match the tempo, line up the beats, even pull the vocals off one track and lay them over another track's instrumental. Every step is checked against the real audio, never a genre-tag guess standing in for actually listening. Full story: docs/human/overview.md.

Status: alpha, developers only. This is a working local MCP server you run from source and drive via Claude — not a packaged app, no installer, no stability guarantees between commits. Expect rough edges. See docs/human/setup.md for the real setup process.

Music taste profiling & AI-driven mashup generation system.

Analyze, curate, and create music grounded in learned epistemic profiles. epistemic-dj builds taste models from real music analysis and listener preferences, then uses a calibrated AI (predict → measure → resolve, Brier-scored — the same discipline Empirica uses on itself) to curate and render actual mashups: not a lookup table, and never a metadata/genre guess standing in for listening to the track.

Three core workflows:

Epistemic → Sound (original, JS side): Transform your cognitive state into music. High uncertainty? Dissonant, chaotic patterns. Deep focus? Clean, driving beats. Celebrating a win? Full-on euphoric build-ups.
Taste Profiling & Curation (Python side): Build epistemic profiles of musical taste from your real Bandcamp collection and YouTube library/playlists, then:
- Analyze real audio (tempo, energy, valence — never metadata alone)
- Curate tracks matching your taste profile, with the why attached
- Calibrate every prediction against real measurement, Brier-scored, so confidence means something
Mashup Rendering (Python side, new): Beatmatch and overlay real tracks into an actual rendered mashup — tempo-matched via pitch-preserving time-stretch, alignment-scored via real audio cross-correlation (not a guess), auto-corrected against its own measurement. Offline, calibrated composition — not a real-time DJ-booth tool (see docs/human/overview.md for that distinction). Full-track overlay and selective stem overlay (vocals from one track over another's instrumental, via Demucs) both work today.

Features

Epistemic State → Sound (JS)

MCP Tools for Claude Code integration
Pattern Generator - 13 epistemic vectors → Strudel live coding patterns
Mood Presets - focus, energize, reflect, debug, celebrate
Web UI - Interactive sliders + embedded Strudel REPL

Music Taste Profiling & Curation (Python)

Bandcamp + YouTube integration - real collection/library ingestion, cookie/header auth (no official personal-collection API exists for either)
Real audio analysis - tempo, energy (kinetic_energy), mood (valence) fit via a DEAM-trained regression, and key/mode (Krumhansl-Schmuckler correlation over chroma) — never metadata guessing
Calibration loop - every prediction (energy, tempo, tempo compatibility, key compatibility) is logged, resolved against real measurement, and Brier-scored — self-correcting confidence, not a static number
Taste profiling - findings/patterns/anti-patterns as real Empirica- style artifacts, so "why did you play me this" has an actual answer

Mashup Rendering (Python, new)

Beatmatching - pitch-preserving time-stretch (librosa phase vocoder) to a real measured target tempo, octave-aware (half/double-time) compatibility scoring
Harmonic mixing - real key/mode detection (chroma + Krumhansl-Schmuckler correlation), Camelot-wheel compatibility scoring between two tracks, same predict/measure/resolve calibration loop as tempo
Real renders - full-track overlay (render_mashup), fixed vocals-over-instrumental stem overlay (render_stem_mashup), and arbitrary independent stem combination from both tracks (render_multistem_mashup, e.g. drums+bass from one track under vocals+other from another) all write actual audio files (epistemic-dj/renders/)
Alignment scoring - genuine cross-correlation of onset-strength envelopes measures how well two tracks' beats actually line up, not a guess — and the render auto-corrects using its own signal
Beat-snapped render start (render_mashup only, not yet the stem-based renders) - the offset snaps to the nearest real detected beat instead of trusting an arbitrary fixed-second position (default on, snap_offset_to_beat=False to disable) — not full downbeat/phrase detection, that needs a heavier model
Stem-separation quality, calibrated - real measured leakage score (pairwise onset-envelope correlation across a track's own separated stems) surfaced on every stem-based render, AND closed through the same predict → measure → resolve → Brier loop as tempo/key (cheap short-excerpt separation predicts the worst-leaking stem pair, verified this session to hold up on real audio unlike a metadata guess)
EQ-aware overlay (render_mashup's highpass_b_hz, opt-in) - high-passes the overlaid track's sub-bass before summing (standard DJ "bass swap"), instead of a flat gain-sum — measured 56-60% reduction in bass-band spectral clash on real audio (mixing.render. spectral_band_overlap), reported before/after so the effect is checkable, not just asserted
Robust tempo measurement - checkpoint spread beyond threshold triggers a denser re-measure rather than trusting a single-window octave guess (two signal-processing octave-correction heuristics were tried and both made things worse on real audio — more real measurements won, not cleverness)
Next: YouTube upload pipeline; Bandcamp export (lowest priority, no confirmed public upload API)

Generative Composition (upcoming, JS)

Strudel Integration - Algorithmic music composition via live-coding
Profile-Driven Generation - Generate original music grounded in taste models
Cross-Fade Patterns - Smooth transitions between epistemic states

Related MCP server: MCP Music Studio

Quick Start

# JS side: Epistemic State -> Sound
npm install
node src/generator/epistemic-to-strudel.js --mood celebrate   # pattern generator
node src/mcp/server.js                                        # MCP server
npx serve src/web                                              # web UI

# Python side: taste profiling, calibration, mashup rendering
cd python
uv sync
uv run epistemic-dj-mcp

# Optional: stem separation (render_stem_mashup) needs the extra --
# heavy, GPU-dependent deps kept out of the default install
uv sync --extra separation

See docs/human/setup.md for connecting your real Bandcamp/YouTube accounts (both need a one-time manual credential step — there's no OAuth flow for either).

MCP Tools (JS side)

`generate_pattern`

Generate a Strudel pattern from epistemic vectors.

{
  "vectors": {
    "know": 0.7,
    "uncertainty": 0.3,
    "engagement": 0.8,
    "clarity": 0.6,
    "coherence": 0.7,
    "signal": 0.5,
    "completion": 0.4
  },
  "mode": "full"
}

`generate_mood`

Generate a pattern for a mood preset.

{
  "mood": "focus"
}

`explain_mapping`

Understand how vectors map to music.

`crossfade_pattern`

Generate transition patterns between states.

MCP Tools (Python side)

The full tool list is large (Bandcamp/YouTube search+ingestion, taste findings/patterns/mixtapes, audio analysis, calibration, rendering) — see python/epistemic_dj/mcp_server.py for the authoritative, documented list. Highlights:

bandcamp_get_collection / youtube_get_playlist_tracks — real source ingestion
audio_analyze_track — real tempo/energy/valence from actual audio
calibration_predict_tempo / calibration_resolve / calibration_brier — the predict → measure → resolve → score loop
calibration_predict_tempo_compatibility / calibration_resolve_tempo_compatibility — pairwise mixability, audio-grounded on both ends
audio_analyze_key — real key/mode/Camelot code from actual audio
calibration_predict_key_compatibility / calibration_resolve_key_compatibility — pairwise harmonic mixability (Camelot wheel distance), same calibration discipline as tempo
calibration_predict_stem_leakage / calibration_resolve_stem_leakage — worst pairwise stem-separation leakage, predicted from a cheap excerpt, resolved against a fuller one, Brier-scored
render_mashup — real time-stretched, beat-aligned overlay render, writes actual .wav output; highpass_b_hz opts into EQ-aware overlay
render_stem_mashup — Demucs-separated vocals overlaid on another track's instrumental, same beatmatch/alignment machinery as render_mashup (requires uv sync --extra separation)
render_multistem_mashup — arbitrary stem selection from BOTH tracks (e.g. drums+bass from A, vocals+other from B), same machinery, independent overlay control instead of a fixed vocals/instrumental split (requires uv sync --extra separation)

Epistemic → Musical Mappings (JS side)

Vector	Musical Parameter
know	Scale consonance (pentatonic → diminished)
uncertainty	Pattern degradation, probability
engagement	Tempo (60-140 BPM), drum intensity
clarity	Filter cutoff (dark → bright)
coherence	Rhythmic stability
signal	Note density, hi-hat patterns
state	Reverb/room size
change	Pattern variation (jux, rev)
completion	Build-up intensity
impact	Overall volume

Claude Code Integration

Add to your Claude Code MCP config:

{
  "mcpServers": {
    "epistemic-dj": {
      "command": "node",
      "args": ["/path/to/epistemic-dj/src/mcp/server.js"]
    }
  }
}

Then in Claude:

Generate a pattern for my current epistemic state:
- know: 0.6 (decent understanding)
- uncertainty: 0.4 (some unknowns)
- engagement: 0.8 (highly focused)

Roadmap

Epistemic State → Sound (JS, stable)

Pattern generator (vectors → Strudel)
MCP server with tools
Web UI with sliders
WebSocket bridge for real-time updates
Empirica integration for automatic state tracking

Taste Profiling & Curation (Python, in progress)

Bandcamp + YouTube source integration (real ingestion, not mocked)
Real audio analysis (tempo/energy/valence from actual audio)
Calibration loop (predict → measure → resolve → Brier score), generalized beyond a single quantity
Full onboarding-interview taste profile builder
LLM curator matching profiles to sources at scale

Mashup Rendering (Python, in progress)

Full phase-by-phase detail: docs/dev/architecture.md.

Tempo prediction + pairwise compatibility, audio-grounded
Real time-stretched, beat-aligned overlay renders + auto-alignment
Stem separation (Demucs) for selective overlay — render_stem_mashup
Robust tempo measurement (adaptive checkpoint densification on instability, rather than a single-window octave-correction guess)
Independent multi-stem overlay (render_multistem_mashup) + stem-separation leakage diagnostic
Harmonic mixing: key/mode detection + Camelot-wheel compatibility scoring, calibrated (predict → measure → resolve)
Beat-snapped render offset (nearest real detected beat, not an arbitrary fixed second) — true downbeat/phrase detection remains a stretch goal (needs madmom or similar, not plain librosa)
Calibrate stem-separation leakage: worst pairwise leakage score, predict → measure → resolve → Brier, cheap-excerpt tolerance (0.15) set from real measured deltas, not guessed
EQ-aware overlay: high-pass the overlaid track's sub-bass before summing (render_mashup's highpass_b_hz, opt-in), measured 56-60% bass-band clash reduction on real audio
YouTube upload pipeline
Bandcamp export (lowest priority — no confirmed public upload API)

Generative Composition (planned)

Profile-driven music generation (compose new tracks from taste models)
Feedback loop (music influences cognition?)
Cross-practice composition (mix epistemic state with taste profiles)
Empirica artifact integration (log music as a form of thought)

Project structure

Two languages, on purpose — see docs/dev/architecture.md for why:

src/ — existing JS/ESM MCP server: epistemic vectors → Strudel patterns (this doc, above)
python/ — Python MCP server: Bandcamp + YouTube integration, real audio analysis, calibration loop, mashup rendering. Quickstart: cd python && uv sync && uv run epistemic-dj-mcp
docs/human/ — product narrative and vision, for people
docs/dev/ — technical architecture, for engineers and future Claude sessions

License

MIT

Credits

Built with:

Strudel - Live coding music in the browser
MCP SDK - Model Context Protocol
Empirica - Epistemic self-assessment

Available Tools

5 tools

crossfade_patternC

Generate a series of patterns that transition between two epistemic states

ParametersJSON Schema

Name	Required	Description
`to`	Yes	Target epistemic state
`from`	Yes	Starting epistemic state
`steps`	No	Number of intermediate patterns

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden of behavioral disclosure, but it only describes the core action. It does not mention whether this is a pure generation operation, what the output format is, whether it makes changes, or any side effects or requirements.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence that is front-loaded with the main action and clearly structured. It has no wasted words and directly conveys the tool's purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is too terse given the lack of annotations and output schema. It does not explain what 'patterns' or 'epistemic states' mean, how the transition works, what the resulting series looks like, or any constraints on the steps parameter. More context is needed for an agent to invoke this tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema descriptions for from, to, and steps already cover 100% of parameters with meaningful clarity. The description adds the concept of 'transition between two epistemic states' which hints at the from/to semantics but does not add significant detail beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: generating a series of patterns that transition between two epistemic states, with a specific verb and resource. It distinguishes from sibling tools like generate_pattern by emphasizing the transition between two states, though it does not explicitly name alternatives or exclusions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 like generate_pattern or generate_mood. The description only states what the tool does, not the context or conditions under which it should be selected.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

explain_mappingB

Explain how epistemic vectors map to musical parameters

ParametersJSON Schema

Name	Required	Description	Default
`vector`	No	Specific vector to explain (optional, explains all if not provided)

TDQS

B3.4/5.0

Behavior2/5

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 states the action but does not disclose the output format, whether the parameter is optional, or any specific behavior beyond 'explain'. For a read-only explanation tool, the risk is low, but the lack of detail about response or parameter behavior leaves gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence, front-loaded with the verb 'Explain'. It avoids unnecessary words and is easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a simple tool with one optional parameter and no output schema. The description provides the core subject but does not describe the expected return format or any additional context about epistemic vectors or musical parameters. Since there is no output schema, the description should at least hint at the nature of the explanation, which it does not.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema fully describes the single parameter 'vector' with 'Specific vector to explain (optional, explains all if not provided)', which is 100% coverage. The tool description adds no additional parameter information, so it does not augment the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the specific verb 'Explain' and clearly identifies the resource: 'how epistemic vectors map to musical parameters'. This distinguishes it from sibling tools like generate_pattern or get_pattern_url, which perform generation or fetching. It is clear and specific.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not explicitly state when to use this tool over siblings or provide exclusions. There is no mention of alternatives or prerequisites. However, the purpose itself implies it should be used when the user seeks an explanation of the mapping concept, so usage is implied rather than explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

generate_moodB

Generate a pattern for a specific mood preset

ParametersJSON Schema

Name	Required	Description	Default
`mood`	Yes	Mood preset to generate

TDQS

B3.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden for behavioral disclosure. It only states what the tool does without describing any side effects, permissions, output format, or limitations. This is a significant gap for a tool that 'generates' something.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence, front-loaded with the verb and resource. It contains no fluff or redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with a single parameter and no output schema, the description is minimally adequate but lacks details about the generated pattern's nature or return value. It is not misleading but leaves gaps about expected output and broader context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already fully documents the single 'mood' parameter with enum values and a description. The tool description adds no additional meaning beyond the schema, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific verb and resource: generate a pattern for a mood preset. It distinguishes from sibling tools by limiting to mood presets, though it does not explicitly name alternatives. The purpose is direct and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool versus alternatives like generate_pattern or explain_mapping. The description implies usage for mood presets but lacks explicit context or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

generate_patternA

Generate a Strudel music pattern from epistemic vectors. Returns code that can be pasted into strudel.cc

ParametersJSON Schema

Name	Required	Description	Default
`mode`	No	Pattern complexity mode	full
`vectors`	Yes	Epistemic state vectors (0-1 scale)
`includeComments`	No	Include explanatory comments in output

TDQS

A3.5/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden of behavioral disclosure. It only says 'Returns code' without mentioning side effects, external calls, determinism, permission needs, error behavior, or what happens to the input vectors. For a generation tool that takes a complex epistemic vector object, this is a significant transparency gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two short sentences with no fluff. The first sentence front-loads the action and input. The second sentence clarifies the output format. Every phrase earns its place, making it highly concise and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has a complex input (nested object with 13 properties) and no output schema, yet the description only provides a high-level purpose. It does not explain how to choose values for the vectors, what each mode ('full', 'minimal', 'drums') means in terms of output, or what the generated code looks like. While the schema details parameter semantics, the description lacks guidance on usage nuances and expected output behavior, making it only minimally complete for a tool of this complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the input schema already describes every parameter and vector sub-property. The description adds the context that these are 'epistemic vectors' and that the result is Strudel code, but it does not explain how mode, includeComments, or individual vector values affect the output. The schema already handles the heavy lifting, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: it 'Generate a Strudel music pattern from epistemic vectors' and 'Returns code that can be pasted into strudel.cc.' This is a specific verb+resource+output. It does not explicitly differentiate from sibling tools like 'crossfade_pattern' or 'generate_mood', but the unique input ('epistemic vectors') and output code makes the purpose fairly distinct.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context: the tool is for generating Strudel code from epistemic vectors. It implies that the agent should use it when it has such vectors and needs a pattern to paste into strudel.cc. It does not state exclusions or alternatives, but the context is explicit enough to guide selection among siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_pattern_urlB

Get a shareable URL for the current pattern on strudel.cc

ParametersJSON Schema

Name	Required	Description	Default
`pattern`	No	Strudel pattern code (optional, uses last generated if not provided)

TDQS

B3.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It simply states what the tool does without mentioning side effects, authentication requirements, rate limits, or details about the returned URL (e.g., permanence, format). This is minimal and leaves potential safety concerns unaddressed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence that leads with the action and includes the target service. Every word adds value, with no redundancy or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple with one optional parameter and no output schema. The description explains the core function but omits details about the result format or any caveats. Given the low complexity, the description is minimally adequate but could benefit from a note about the returned URL's nature or the meaning of 'current pattern'.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema provides 100% coverage of the parameter, including its optionality and fallback behavior ('uses last generated if not provided'). The description adds no additional parameter semantics, but the schema already fully explains the parameter, meeting the baseline for full coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action ('Get a shareable URL') for a specific resource ('current pattern on strudel.cc'). This clearly distinguishes it from sibling tools like generate_pattern or crossfade_pattern, which have different purposes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not provide any guidance on when to use this tool versus alternatives. It does not mention exclusions, preconditions, or sibling tools, leaving the agent to infer usage from the name alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

5 tool updatesv0.1.0Aug 9, 2026
- First observedcrossfade_pattern
- First observedexplain_mapping
- First observedgenerate_mood
- First observedgenerate_pattern
- First observedget_pattern_url

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.5/5.0

Scored 2026-08-09 19:45 across 5 tools

Disambiguation4/5

Most tools have distinct purposes: explain_mapping provides conceptual explanation, generate_pattern and generate_mood both generate patterns but from different inputs, crossfade_pattern creates transitions between states, and get_pattern_url handles sharing. Some overlap exists between generate_* and crossfade_pattern, but descriptions clarify the differences.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (explain_mapping, crossfade_pattern, generate_pattern, generate_mood, get_pattern_url). The style is uniform and predictable.

Tool Count5/5

Five tools is within the ideal range and each tool addresses a core aspect of the workflow: understanding, generating, transitioning, and sharing patterns. No tool feels redundant or excessive.

Completeness4/5

The tool set covers the main lifecycle: explain, generate (two modes), crossfade, and get a shareable URL. Minor gaps exist, such as no explicit tool for modifying or listing existing patterns, but the core workflow is covered.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

mcp-producerOAuth
io.github.AceDataCloud
MCP server for Producer/Riffusion AI music generation
Audio Processing AI & Machine Learning
22
Keyboardia A
io.github.adewale
Create, co-edit, analyze, publish, and export collaborative step-sequencer sessions through MCP.
Audio Processing Multimedia Processing
713
strata
ai.klavis
MCP server for progressive tool usage at any scale (see https://klavis.ai)
Agent Orchestration Autonomous Agents Developer Tools
25,748
Music Studio A
io.github.linxule
ABC sheet music + Strudel live coding studio with ext-apps widgets, harmony tools, and share links.
Entertainment & Media Multimedia Processing Audio Processing
7270

Related MCP Servers

sonic-mcp
Audio Processing Entertainment & Media Code Execution
AJBogo9
A
license
A
quality
D
maintenance
MCP server that connects Claude Code to Sonic Pi for AI-assisted beat making, enabling live code execution and pattern management.
Updated 3 months ago (2026-06-10 18:36 UTC)
21
MIT
MCP Music Studio
Audio Processing Multimedia Processing
linxule
A
license
Not graded
quality
B
maintenance
Two-mode creative music studio for AI: scored composition (ABC notation with sheet music) and live performance (Strudel live coding with TidalCycles), with interactive UI rendering inline in Claude Desktop and other MCP clients.
Updated 7 days ago (2026-09-08 12:08 UTC)
65 npm
70
MIT
io.github.peterkolbe/ableton
Multimedia Processing Audio Processing
peterkolbe
A
license
A
quality
C
maintenance
MCP server that bridges Ableton Live with AI models, enabling real-time project inspection and control such as track overview, device parameters, and audio analysis.
Updated 4 months ago (2026-05-15 14:27 UTC)
12
MIT
oscine
Audio Processing Multimedia Processing
chazmaniandinkle
A
license
Not graded
quality
C
maintenance
An MCP server that exposes a synthesizer composer's command catalog as tools, enabling Claude to compose, sound-design, and mix in a live browser session.
Updated a month ago (2026-08-13 18:35 UTC)
MIT