模型上下文协议 (MCP) 服务器允许 AI 助手通过 OSC 消息与 Sonic Pi 进行交互。这使得 Claude 和 Cursor 等 AI 工具能够以编程方式创作音乐并控制 Sonic Pi。
使用可自定义的合成器参数演奏单个音符
执行任意 Sonic Pi 代码
可与任何 MCP 兼容客户端（Claude Desktop、Cursor 等）配合使用
Related MCP server: StreamerSongList MCP Server
在使用 MCP 服务器之前，您需要将以下代码添加到 Sonic Pi 缓冲区。此代码用于处理服务器发送的 OSC 消息：
# Required Sonic Pi configuration
# Add this to a buffer in Sonic Pi and run it
live_loop :code_runner do
use_real_time
code = sync "/osc*/run-code"
# Since we receive the code as a string, we can use eval to execute it
# The code comes as the first element of the message
begin
eval(code[0].to_s)
rescue Exception => e
puts "Error executing code: #{e.message}"
end
end
在使用 MCP 服务器之前，请确保此代码在 Sonic Pi 中运行。
添加到~/.cursor/mcpServers.json ：
{
"mcpServers": {
"sonic_pi_mcp": {
"name": "Sonic Pi MCP",
"command": "npx",
"args": ["-y", "sonic-pi-mcp", "start"],
"transport": {
"type": "stdio"
}
}
}
}添加到 Claude 的 MCP 配置：
{
"mcpServers": {
"sonic_pi_mcp": {
"command": "npx",
"args": ["-y", "sonic-pi-mcp", "start"]
}
}
}播放具有可自定义参数的单个音符。
参数：
note （必填）：MIDI 音符编号（0-127）
synth （可选）：要使用的合成器（例如“:saw”、“:beep”、“:prophet”）
sustain （可选）：音符持续时间（以秒为单位）（默认值：1）
cutoff （可选）：滤波器截止频率（默认值：100）
例子：
// Play middle C with saw wave synth
{
"name": "play_note",
"parameters": {
"note": 60,
"synth": ":saw",
"sustain": 0.5,
"cutoff": 80
}
}执行任意 Sonic Pi 代码。
参数：
code （必需）：要执行的 Sonic Pi 代码
例子：
{
"name": "run_code",
"parameters": {
"code": "use_synth :prophet\nplay_pattern_timed [60, 64, 67], [0.5]"
}
}以下是使用 MCP 工具的一些交互示例：
// Play a C major arpeggio
{
"code": `
use_synth :piano
play_pattern_timed [60, 64, 67, 72], [0.25], release: 0.1
`
}// Create a rhythmic pattern
{
"code": `
live_loop :rhythm do
use_synth :tb303
play choose(chord(:C3, :minor)), release: 0.2, cutoff: rrand(60, 120)
sleep 0.25
end
`
}无声音
确保 Sonic Pi 正在运行
检查 OSC 处理程序代码是否在 Sonic Pi 中运行
验证 Sonic Pi 是否正在监听端口 4560（默认）
连接错误
检查服务器的另一个实例是否正在运行
重启Sonic Pi
确保没有其他应用程序正在使用端口 4560
代码执行错误
检查 Sonic Pi 日志窗口中的错误消息
验证 Sonic Pi 代码的语法
确保所有必需的合成器和样本都可用
# Clone the repository
git clone https://github.com/abhishekjairath/sonic-pi-mcp.git
cd sonic-pi-mcp
# Install dependencies
npm install
# Build
npm run build
# Install MCP Inspector globally (for testing)
npm install -g @modelcontextprotocol/inspector
# Start Sonic Pi and run the OSC handler code (see Sonic Pi Configuration section)
# Start the server in one terminal
npm run dev
# In another terminal, start the MCP Inspector
mcp-inspector打开浏览器并导航至http://localhost:3000
在 MCP Inspector UI 中，配置连接：
命令： node
参数： dist/server.mjs
工作目录： /path/to/your/sonic-pi-mcp （使用您的实际项目路径）
传输类型：stdio
测试play_note工具：
{
"name": "play_note",
"parameters": {
"note": 60,
"synth": ":beep",
"sustain": 0.5
}
}测试run_code工具：
{
"name": "run_code",
"parameters": {
"code": "use_synth :prophet\nplay_pattern_timed scale(:c4, :major), [0.25]"
}
}检查 Sonic Pi 日志窗口是否有任何错误消息或输出
构建错误
运行npm run build并检查 TypeScript 错误
确保所有依赖项都正确安装
检查tsconfig.json是否配置正确
MCP 检查器连接问题
验证服务器正在运行（ npm run dev ）
检查工作目录路径是否正确
确保服务器没有其他实例正在运行
OSC 通信问题
确认 Sonic Pi 正在运行并且 OSC 处理程序代码处于活动状态
检查服务器日志是否存在连接错误
验证端口 4560 可用且未被阻止
分叉存储库
创建你的功能分支（ git checkout -b feature/amazing-feature ）
提交您的更改（ git commit -m 'Add some amazing feature' ）
推送到分支（ git push origin feature/amazing-feature ）
打开拉取请求
该项目根据 MIT 许可证获得许可 - 有关详细信息，请参阅LICENSE文件。
| Name | Required | Description | Default |
|---|---|---|---|
| note | Yes | MIDI note number (0-127) | |
| synth | No | Synth to use (e.g. :saw, :beep, :prophet) | |
| sustain | No | Note duration in seconds | |
| cutoff | No | Filter cutoff frequency |
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Sonic Pi code to execute |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
play_noterun_codeScored 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.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
MCP server for Producer/Riffusion AI music generation
Generate AI music via the Lacuna Music API from MCP clients like Claude Desktop & Code.
A Model Context Protocol server for Wix AI tools