Skip to main content
Glama
enesjakozh
abhishekjairath

Sonic Pi MCP

by abhishekjairath
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Local

Sonic Pi MCP

Model Context Protocol (MCP) server for Sonic Pi. Describe music in natural language in your LLM client; the model generates Sonic Pi code and this server sends it over OSC. Use the included queue runner in Sonic Pi for crossfades between segments.

Features

  • queue_segment — send the next full musical segment (named live_loops, use_bpm, etc.).

  • run_code — same as queue_segment (compatibility).

  • stop_all — hard stop via OSC (/stop-all-jobs), like Sonic Pi’s Stop.

  • play_note — quick test note.

  • Resource — DJ session craft, vocabulary, and tool usage (read from the MCP client).

  • Prompt next_performance_segment — help frame the next block for longer sets.

  • Env — OSC_HOST, OSC_PORT, OSC_CODE_PATH, OSC_STOP_ALL_PATH.

Related MCP server: StreamerSongList MCP Server

Prerequisites

  • Sonic Pi v4.x

  • Node.js 18+ (npx / node)

  • An MCP-capable client (Cursor, Claude Desktop, VS Code with MCP, etc.)

Optional: Bun for local development (bun run dev).

One-time Sonic Pi setup (queue runner)

  1. Open Sonic Pi.

  2. Copy sonic-pi-queue.rb into a buffer.

  3. Press Run and leave it running.

The buffer listens on the default OSC port and crossfades between segments sent by the MCP.

Install the MCP server

npx -y sonic-pi-mcp

Point your client at this command over stdio (see below).

Cursor

Use ~/.cursor/mcp.json and/or .cursor/mcp.json in a project:

{
  "mcpServers": {
    "sonic_pi_mcp": {
      "command": "npx",
      "args": ["-y", "sonic-pi-mcp"]
    }
  }
}

Local clone (after npm install or bun install and bun run build):

{
  "mcpServers": {
    "sonic_pi_mcp": {
      "command": "node",
      "args": ["/absolute/path/to/sonic-pi-mcp/bin/cli.mjs"]
    }
  }
}

Bun without building — some clients ignore cwd; use an absolute path to src/server.ts, or use the launcher:

{
  "mcpServers": {
    "sonic_pi_mcp": {
      "command": "/absolute/path/to/sonic-pi-mcp/bin/mcp-dev.sh",
      "args": []
    }
  }
}

Run chmod +x bin/mcp-dev.sh once. The script changes into the repo and runs bun run src/server.ts.

Claude Desktop

~/Library/Application Support/Claude/claude_desktop_config.json (paths differ on Windows):

{
  "mcpServers": {
    "sonic_pi_mcp": {
      "command": "npx",
      "args": ["-y", "sonic-pi-mcp"]
    }
  }
}

For a local clone, prefer bin/mcp-dev.sh (see above) if you see Module not found "src/server.ts" or spawn bunx ENOENT. Remove and re-add the MCP in the app if an old definition is cached.

VS Code

Configure your MCP extension to run npx with -y and sonic-pi-mcp, stdio transport, per the extension’s docs.

Environment variables

Variable

Default

Meaning

OSC_HOST

127.0.0.1

Sonic Pi host

OSC_PORT

4560

Sonic Pi OSC port

OSC_CODE_PATH

/run-code

OSC path for code (must match your Sonic Pi buffer)

OSC_STOP_ALL_PATH

/stop-all-jobs

Hard stop path

Allow incoming OSC in Sonic Pi if you connect from another machine; set OSC_HOST accordingly.

Development

git clone https://github.com/abhishekjairath/sonic-pi-mcp.git
cd sonic-pi-mcp
bun install   # or npm install
bun run build
bun run dev

OSC smoke test (Sonic Pi + runner running):

bun run test

MCP Inspector

npx @modelcontextprotocol/inspector

Use node with argument bin/cli.mjs and this directory as the working directory (after bun run build).

Troubleshooting

  • No sound — Sonic Pi open? Queue buffer running? Port 4560 reachable?

  • Nothing happens — OSC enabled in Sonic Pi; OSC_HOST / OSC_PORT match.

  • Layers pile up — Use queue_segment with named live_loops; use stop_all only for a full reset.

  • Module not found "src/server.ts" (Claude) — Use bin/mcp-dev.sh as command with empty args, or absolute paths; don’t rely on cwd alone.

  • resources/list / prompts/list → Method not found — You’re on an older build that only exposed tools. Reinstall/restart the MCP from this repo or npm so resources and prompts are registered.

  • Ruby errors in Sonic Pi log — The generated code failed to parse or run; fix the snippet (brackets, samples, syntax) and send again. The queue runner prints a code snippet on failure.

License

MIT — see LICENSE.

Available Tools

2 tools
play_noteD
ParametersJSON Schema
NameRequiredDescriptionDefault
noteYesMIDI note number (0-127)
synthNoSynth to use (e.g. :saw, :beep, :prophet)
sustainNoNote duration in seconds
cutoffNoFilter cutoff frequency

TDQS

D1/5.0
Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

run_codeD
ParametersJSON Schema
NameRequiredDescriptionDefault
codeYesSonic Pi code to execute

TDQS

D1/5.0
Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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. Dates show when Glama detected each change.

  1. 2 tool updates
    • First observedplay_note
    • First observedrun_code
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

D1.8/5.0
Disambiguation5/5

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.

Naming Consistency5/5

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.

Tool Count2/5

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.

Completeness2/5

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.

Maintenance

ActivityInactive
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

Appeared in Searches

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/abhishekjairath/sonic-pi-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server