AIアシスタントがOSCメッセージを介してSonic Piと対話できるようにするModel Context Protocol（MCP）サーバー。これにより、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が動作していることを確認する
Sonic PiでOSCハンドラーコードが実行されていることを確認します。
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