Sonic Pi MCP
Controlador MCP de Sonic Pi
Un servidor de Protocolo de Contexto de Modelo (MCP) que permite a los asistentes de IA interactuar con Sonic Pi mediante mensajes OSC. Esto permite que herramientas de IA como Claude y Cursor creen música y controlen Sonic Pi mediante programación.
Características
Reproduce notas individuales con parámetros de sintetizador personalizables
Ejecutar código arbitrario de Sonic Pi
Funciona con cualquier cliente compatible con MCP (Claude Desktop, Cursor, etc.)
Related MCP server: StreamerSongList MCP Server
Prerrequisitos
Node.js (v18 o superior)
Sonic Pi (v4.0 o superior)
Un cliente compatible con MCP (Cursor, Claude Desktop, etc.)
Configuración de Sonic Pi
Antes de usar el servidor MCP, debe agregar el siguiente código al búfer de Sonic Pi. Este código gestiona los mensajes OSC enviados por el servidor:
# 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
Asegúrese de que este código se esté ejecutando en Sonic Pi antes de usar el servidor MCP.
Integración con clientes
Cursor
Agregar a ~/.cursor/mcpServers.json :
{
"mcpServers": {
"sonic_pi_mcp": {
"name": "Sonic Pi MCP",
"command": "npx",
"args": ["-y", "sonic-pi-mcp", "start"],
"transport": {
"type": "stdio"
}
}
}
}Escritorio de Claude
Agregar a la configuración MCP de Claude:
{
"mcpServers": {
"sonic_pi_mcp": {
"command": "npx",
"args": ["-y", "sonic-pi-mcp", "start"]
}
}
}Herramientas disponibles
nota de reproducción
Reproduce una sola nota con parámetros personalizables.
Parámetros:
note(obligatoria): número de nota MIDI (0-127)synth(opcional): sintetizador a utilizar (por ejemplo, ":saw", ":beep", ":prophet")sustain(opcional): Duración de la nota en segundos (predeterminado: 1)cutoff(opcional): frecuencia de corte del filtro (predeterminado: 100)
Ejemplo:
// Play middle C with saw wave synth
{
"name": "play_note",
"parameters": {
"note": 60,
"synth": ":saw",
"sustain": 0.5,
"cutoff": 80
}
}código de ejecución
Ejecuta código arbitrario de Sonic Pi.
Parámetros:
code(obligatorio): Código de Sonic Pi a ejecutar
Ejemplo:
{
"name": "run_code",
"parameters": {
"code": "use_synth :prophet\nplay_pattern_timed [60, 64, 67], [0.5]"
}
}Ejemplo de uso
A continuación se muestran algunos ejemplos de interacciones utilizando las herramientas MCP:
Melodía sencilla
// Play a C major arpeggio
{
"code": `
use_synth :piano
play_pattern_timed [60, 64, 67, 72], [0.25], release: 0.1
`
}Patrón complejo
// 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
`
}Solución de problemas
Sin sonido
Asegúrese de que Sonic Pi esté funcionando
Compruebe que el código del controlador OSC se esté ejecutando en Sonic Pi
Verifique que Sonic Pi esté escuchando en el puerto 4560 (predeterminado)
Errores de conexión
Comprobar si se está ejecutando otra instancia del servidor
Reiniciar Sonic Pi
Asegúrese de que ninguna otra aplicación esté utilizando el puerto 4560
Errores de ejecución de código
Consulte la ventana de registro de Sonic Pi para ver si hay mensajes de error
Verifique la sintaxis de su código Sonic Pi
Asegúrese de que todos los sintetizadores y muestras necesarios estén disponibles
Desarrollo
# 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-inspectorPruebas con MCP Inspector
Abra su navegador y navegue a http://localhost:3000
En la interfaz de usuario del Inspector de MCP, configure la conexión:
Comando:
nodeArgumentos:
dist/server.mjsDirectorio de trabajo:
/path/to/your/sonic-pi-mcp(use la ruta de su proyecto actual)Tipo de transporte: stdio
Pruebe la herramienta
play_note:
{
"name": "play_note",
"parameters": {
"note": 60,
"synth": ":beep",
"sustain": 0.5
}
}Pruebe la herramienta
run_code:
{
"name": "run_code",
"parameters": {
"code": "use_synth :prophet\nplay_pattern_timed scale(:c4, :major), [0.25]"
}
}Verifique la ventana de registro de Sonic Pi para ver si hay mensajes de error o salida
Solución de problemas de desarrollo
Errores de compilación
Ejecute
npm run buildy verifique si hay errores de TypeScriptAsegúrese de que todas las dependencias estén instaladas correctamente
Verifique
tsconfig.jsonpara verificar la configuración correcta
Problemas de conexión del inspector MCP
Verifique que el servidor esté ejecutándose (
npm run dev)Compruebe que la ruta del directorio de trabajo sea correcta
Asegúrese de que no haya otras instancias del servidor en ejecución
Problemas de comunicación de la OSC
Confirme que Sonic Pi se esté ejecutando y que el código del controlador OSC esté activo
Verifique los registros del servidor para detectar errores de conexión
Verifique que el puerto 4560 esté disponible y no esté bloqueado
Contribuyendo
Bifurcar el repositorio
Crea tu rama de funciones (
git checkout -b feature/amazing-feature)Confirme sus cambios (
git commit -m 'Add some amazing feature')Empujar a la rama (
git push origin feature/amazing-feature)Abrir una solicitud de extracción
Licencia
Este proyecto está licenciado bajo la licencia MIT: consulte el archivo de LICENCIA para obtener más detalles.
Available Tools
2 toolsplay_noteD
| 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 |
TDQS
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.
run_codeD
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Sonic Pi code to execute |
TDQS
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.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
- First observed
play_note - First observed
run_code
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.
Maintenance
Related MCP Connectors
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
Related MCP Servers
- AlicenseCqualityCmaintenanceA Model Context Protocol server that enables real-time interaction with Ableton Live, allowing AI assistants to control song creation, track management, clip operations, and audio recording workflows.2369 npm94MIT
- AlicenseAqualityFmaintenanceA Model Context Protocol server that enables AI assistants like Claude to manage song requests, monitor queues, and interact with streaming platforms' song request systems.612 npm2MIT
- AlicenseAqualityDmaintenanceMCP server that connects Claude Code to Sonic Pi for AI-assisted beat making, enabling live code execution and pattern management.21MIT
- FlicenseNot gradedqualityDmaintenanceEnables AI-powered music generation and control of Sonic Pi through natural language requests using OSC.-