sclang-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| SCLANG_PATH | No | Path to the sclang binary | /Applications/SuperCollider.app/... on macOS, else sclang on PATH |
| SCLANG_MCP_OUTPUT_DIR | No | Where WAV files are written (relative to the client's working directory) | ./renders |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| sc_checkB | Check that SuperCollider's sclang is installed and where renders are written. |
| sc_renderA | 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. |
| sc_playA | Play SuperCollider code in realtime on the default audio output. Boots the server, runs the code (the server is |
| sc_stopB | Stop realtime playback started by sc_play. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored 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.