Sonic Pi MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| OSC_HOST | No | Sonic Pi host | 127.0.0.1 |
| OSC_PORT | No | Sonic Pi OSC port | 4560 |
| OSC_CODE_PATH | No | OSC path for code (must match your Sonic Pi buffer) | /run-code |
| OSC_STOP_ALL_PATH | No | Hard stop path | /stop-all-jobs |
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
Server capabilities have not been inspected yet.
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| play_noteD | – |
| run_codeD | – |
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 2 tools
The two tools have clearly distinct purposes: play_note handles individual note playback, while run_code executes code, likely for more complex Sonic Pi scripts. There is no overlap or ambiguity between these functions.
Both tools follow a consistent verb_noun pattern (play_note, run_code) with clear, descriptive names that align well with their inferred functions. No deviations or mixed conventions are present.
With only two tools, this server feels too thin for a Sonic Pi integration, which typically involves managing sounds, loops, effects, and code execution. The scope is significantly under-covered, limiting agent capabilities.
The tool surface is severely incomplete for Sonic Pi's domain, lacking essential operations like stopping playback, adjusting parameters, managing samples, or handling live coding workflows. Agents will face dead ends in typical music programming tasks.