Click on "Deploy 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., "@sclang-mcp Please render a short pluck pattern to WAV and report its peak and RMS levels."
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.
An MCP server that lets an AI agent make music with SuperCollider.
The main problem with an agent making music is that it can't hear. So the core tool renders to a WAV file offline and reports peak and RMS levels, which tells the agent whether it produced silence or clipping. You listen to the file and give feedback. Realtime playback is there too.
Works on macOS (Intel and Apple Silicon) and Linux. It runs sclang as a subprocess, so there's no native code and no dependency on supercolliderjs.
Tool | What it does |
| Finds |
| Renders SuperCollider code to a WAV file offline (faster than realtime, no audio device needed) and returns the path plus level stats |
| Plays SuperCollider code in realtime on the default output for N seconds |
| Stops realtime playback |
sc_render expectsThe code you send must hand over what to render:
// Optional: custom instruments (a basic \default one is always included).
// Plain SynthDef objects, no .add or .store.
~defs = [
SynthDef(\pluck, { |out = 0, freq = 440, amp = 0.2|
var env = EnvGen.kr(Env.perc(0.01, 2), doneAction: 2);
Out.ar(out, Pluck.ar(WhiteNoise.ar, 1, 0.1, freq.reciprocal, 3) ! 2 * amp * env);
})
];
// Required: a Pattern...
~pattern = Pbind(\instrument, \pluck, \degree, Pseq([0, 2, 4, 7], 2), \dur, 0.25);
// ...or instead a raw Score for full control: ~score = Score([...]);Example result:
Rendered /path/to/renders/pluck.wav
4.00 s, 2 ch, 44100 Hz
peak 0.412 (-7.7 dBFS), rms 0.061 (-24.3 dBFS)Silent and clipping renders are flagged with a warning. sclang compile and runtime errors come back as the tool error.
sc_play runs your code after the server has booted (the server is s), for example Pbind(\degree, Pseq([0, 2, 4], inf), \dur, 0.2).play.
Related MCP server: SuperCollider MCP Server
Install SuperCollider
macOS: brew install --cask supercollider
Linux: your package manager, for example apt install supercollider-language supercollider-server
Add the server to your MCP client. For Claude Code:
claude mcp add sclang -- npx -y github:pimvanoerle/sclang-mcpOr in a JSON config:
{
"mcpServers": {
"sclang": {
"command": "npx",
"args": ["-y", "github:pimvanoerle/sclang-mcp"]
}
}
}Env var | Default | Meaning |
|
| Path to the |
|
| Where WAV files are written |
Code sent to these tools runs in sclang with your user's permissions. SuperCollider can run shell commands ("ls".unixCmd) and read and write files. Only connect this to an agent you'd trust with a shell. sc_play and sc_render run in a separate process per call, so a crash or hang can't take the MCP server down; renders time out after a duration-scaled limit.
npm install
npm test # builds, then drives the server over stdio with the MCP SDK client against a real sclangTests that need sclang are skipped when it isn't installed.
sc_render renders patterns and scores. Live-coding constructs that need a running server (buses, Routines that talk to s, effects chains outside a score) belong in sc_play, or in a ~score you build yourself.
Every pattern you render must end. An infinite Pbind (for example a delay written as Pbind(\dur, 4)) makes sclang loop while building the score until the render times out. Cap voices with Pfindur(seconds, pattern) and write one-shot delays as Pbind(\type, \rest, \dur, Pseq([4])).
Renders are 16-bit stereo WAV.
Renders are mixed straight to the output bus. For a reverb or limiter over everything, add a master synth at the tail of group 1 in a ~score; the idea is ~score.add([0.0, [\s_new, \master, 999, 1, 1]]) with a ReplaceOut synth.
MIT
Check that SuperCollider's sclang is installed and where renders are written.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 what is checked but not return values, side effects, safety profile, or error behavior, leaving behavior largely opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded, and free of waste. It directly states the two aspects of the check.
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?
Zero-param tool with no annotations or output schema. The description is minimal but partially compensates by implying the check returns install status and render path. It does not explain return format or failure behavior, leaving a gap for an agent interpreting results.
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?
Zero parameters, so baseline is 4 per rule. Description adds no parameter meaning because there are none to describe.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Check') and two concrete resources: sclang installation and render output location. It distinguishes itself from the render/play/stop siblings by being a diagnostic, though it does not name them 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?
No when-to-use guidance, no mention of alternatives or prerequisites. The agent must infer that this is a preflight check rather than an operation to run before/after renders.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Play SuperCollider code in realtime on the default audio output. Boots the server, runs the code (the server is s, e.g. Pbind(...).play or { SinOsc.ar(440) ! 2 * 0.1 }.play), and stops everything after duration seconds.
Returns once playback has started. Use sc_stop to cut it short. Only one playback runs at a time; a new call replaces the old one.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | SuperCollider code to run after the server has booted. | |
| duration | Yes | Seconds to keep playing before shutting down. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses the server-boot side effect, that it returns once playback has started rather than when audio finishes (async semantics), that everything stops after duration, and that a new call replaces any running playback. It omits failure/error behavior and any resource or output constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the action, then execution details, then return behavior and alternatives. Every sentence earns its place; the inline code examples are slightly bulky but functionally useful rather than 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?
No output schema exists, and the description compensates by stating the return timing ('Returns once playback has started'). No annotations exist, so it also supplies the behavioral context an agent needs. Only minor gaps remain, such as error handling when the code fails to compile.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: it explains that 'the server is `s`' and shows concrete code shapes (Pbind(...).play, { SinOsc.ar(440) ! 2 * 0.1 }.play) that clarify what the `code` string should contain, and reiterates duration as the auto-stop window.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (play) and resource (SuperCollider code) plus the execution context (realtime, default audio output). The phrase 'realtime on the default audio output' implicitly separates it from sc_render's offline rendering, and it names sc_stop 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?
Names the alternative for the opposite action ('Use sc_stop to cut it short') and states the concurrency rule ('Only one playback runs at a time; a new call replaces the old one'), which tells the agent what calling it again does. It does not explicitly contrast with sc_render or sc_check, so 4 rather than 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render SuperCollider code to a WAV file offline (faster than realtime, no audio hardware needed) and report level stats. The code runs in sclang and must provide what to render in one of three ways: ~pattern = Pbind(...) (or return a Pattern as the last expression); ~score = Score([...]) for raw server messages. Optionally set ~defs = [SynthDef(\name, {...}), ...] for any custom instruments the pattern uses (a basic \default instrument is always included). Use SynthDef objects without .add/.store. Example: ~defs = [SynthDef(\pluck, { |out=0, freq=440, amp=0.2| Out.ar(out, Pluck.ar(WhiteNoise.ar, 1, 0.1, freq.reciprocal, 3) ! 2 * amp * EnvGen.kr(Env.perc(0.01, 2), doneAction: 2)) })]; ~pattern = Pbind(\instrument, \pluck, \degree, Pseq([0, 2, 4, 7], 2), \dur, 0.25); The result includes peak/RMS so you can tell silence or clipping without listening. Returns the WAV path.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | SuperCollider code (see tool description). | |
| name | No | File name without extension. | render |
| tail | No | Extra seconds rendered after the content so releases and reverbs can ring out. | |
| duration | Yes | Length of the musical content in seconds. | |
| sampleRate | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does substantial work: it explains the required code contract (~pattern, ~score, ~defs), that a basic \default instrument is always included, that SynthDefs must be used without .add/.store, and that results include peak/RMS to detect silence or clipping and return a WAV path. It still omits where on disk the file lands, overwrite/collision behavior, and error handling.
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 purpose is front-loaded in the first sentence, and the code contract plus example follow in a logical order. The escaped-quote example is long but earns its place for a DSL-driven tool, though it makes the block somewhat dense.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description must cover returns, and it does ('returns the WAV path', peak/RMS stats). Combined with the code contract instructions, an agent has what it needs to invoke this correctly; only disk destination and lifecycle details are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 80%, so the baseline is 3, but the description meaningfully enriches the most important parameter by spelling out the three accepted code shapes and providing a full working example. That adds real meaning beyond the schema's terse 'SuperCollider code (see tool 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?
States a specific verb and resource — render SuperCollider code to a WAV file — plus the key distinction that it runs offline and faster than realtime. The parenthetical '(faster than realtime, no audio hardware needed)' implicitly separates it from the realtime sc_play sibling, so an agent can pick correctly without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The offline/faster-than-realtime framing gives clear context for when this tool is the right choice over realtime playback. It does not explicitly name sc_play/sc_stop or state exclusions, so it stops short of full when/when-not guidance, but the context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stop realtime playback started by sc_play.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden, and it discloses very little. It does not say whether stopping resets playback position, whether it errors or no-ops when no playback is active, or whether it affects other sessions — all relevant for a state-changing control operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single short sentence that front-loads the action and its scope with no wasted words. Every clause earns its place by naming both the effect and the originating tool.
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 zero-parameter, no-output-schema control tool, the description covers the essential purpose and counterpart. It stops short of the operational details an agent might need — behavior on error, whether state is reset, or confirmation of effect — leaving it minimally viable rather than 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?
The tool takes zero parameters, so the schema baseline of 4 applies; there is no parameter semantics to add and the description does not need to compensate. Nothing in the description misrepresents the empty parameter set.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Stop) and resource (realtime playback) and ties it to the sibling sc_play that initiates it, which lets an agent pair the two without ambiguity. It does not distinguish itself from the other siblings (sc_check, sc_render), but those are clearly different operations, so this is close to fully 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?
Usage is implied rather than stated: by naming sc_play as the initiator, it suggests this tool is only applicable after sc_play has started playback. There is no explicit when/when-not guidance, no statement about calling it when nothing is playing, and no named alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0sc_checksc_playsc_rendersc_stopScored across 4 tools
Each tool targets a clearly distinct action: sc_check verifies installation, sc_render produces offline WAV output, sc_play performs realtime playback, and sc_stop halts playback. There is no overlap, and sc_play/sc_stop form an unambiguous complementary pair.
All four tools follow a strict sc_<verb> pattern (check, render, play, stop) with snake_case and consistent prefixes. The naming is fully predictable and readable.
Four tools cleanly cover the server's narrow purpose of executing/rendering SuperCollider code. Each tool earns its place with no redundancy or filler.
The core lifecycle (verify, offline render, realtime play, stop) is well covered. Minor gaps exist, such as querying current playback/session state or listing prior renders, but agents can work around these via the returned paths and stats.
Remote MCP server for audio stem separation, denoise, and reverb.
Generate full songs with vocals, instrumentals and sound effects from text. One server for Suno, Google Lyria, Mureka, MiniMax, ACE-Step, YuE and ElevenLabs. Your agent can quote the credit cost before generating, start a song, wait for it to finish and return download links. Sign in with OAuth; optional daily credit caps; retries never charge twice.
Audio for your agent: transcribe, speak, translate, summarise, plus sound effects and music.
AI-manageable audio CDN: upload, transcode, normalize, stream & deliver audio, plus grounded docs.
