Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Cardinal MCP Server Create a basic synth patch for me"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP (Model Context Protocol) server for Cardinal/VCV Rack patch manipulation with AI.
World's first AI integration for modular synthesizer patching!
Analyze patches - Understand what a patch does
Create patches - Generate patches from templates
Add modules - Insert new modules into patches
Connect modules - Wire up modules with cables
Suggest modules - Get recommendations based on your goal
Modify parameters - Adjust knobs and settings
Related MCP server: synthlab-mcp
# Clone this repository
git clone https://github.com/YOUR_USERNAME/cardinal-mcp-server.git
cd cardinal-mcp-server
# Install dependencies
npm install
# Build
npm run buildAdd to your Claude Code settings (~/.claude/settings.json):
{
"mcpServers": {
"cardinal": {
"command": "node",
"args": ["/path/to/cardinal-mcp-server/dist/index.js"]
}
}
}Then restart Claude Code.
Analyze a .vcv patch file and explain what it does.
"Analyze the patch at /path/to/my-patch.vcv"Create a new patch from a template.
Templates:
basic-synth - Simple VCO → ADSR → VCA → Output
ambient-pad - VCO → VCF (with LFO) → ADSR → VCA → Output
empty - Blank patch
"Create an ambient pad patch at ~/Desktop/my-ambient.vcv"Get module suggestions for what you want to create.
"Suggest modules for a bass sound"
"Suggest modules for an ambient pad"
"Suggest modules for drum sounds"Add a module to an existing patch.
"Add a Fundamental:VCF filter to my patch"Connect two modules with a cable.
"Connect module 2 output 0 to module 3 input 1"List available modules in the database.
"List all oscillator modules"
"List all filter modules"Change a parameter value on a module.
"Set the attack (param 0) on module 3 to 0.5"You: Create a basic synth patch for me
Claude: I'll create a basic-synth patch with VCO → ADSR → VCA → Audio Out...
You: Make the attack longer
Claude: I'll modify the ADSR attack parameter...
You: Add a filter between the VCO and VCA
Claude: Adding a Fundamental:VCF and reconnecting the signal flow...
Currently includes definitions for:
Oscillators: Fundamental VCO, Bogaudio VCO
Filters: Fundamental VCF
Envelopes: Fundamental ADSR
VCAs: Fundamental VCA-1
Modulation: Fundamental LFO
Sequencers: Fundamental SEQ-3
Effects: Valley Plateau
Utilities: Fundamental Mixer
I/O: Cardinal HostMIDI, HostAudio2
More modules can be added to the MODULE_DATABASE in the source code.
PRs welcome! To add more modules:
Add entries to MODULE_DATABASE with description, category, inputs, and outputs
Optionally add new patch templates to PATCH_TEMPLATES
MIT
Cardinal - The free and open-source virtual modular synthesizer
VCV Rack - The original virtual Eurorack
MCP Protocol - Model Context Protocol specification
Add a module to an existing patch
| Name | Required | Description | Default |
|---|---|---|---|
| model | Yes | Module model name (e.g., 'VCO', 'VCF') | |
| plugin | Yes | Plugin name (e.g., 'Fundamental', 'Bogaudio') | |
| filepath | Yes | Path to the .vcv patch file | |
| position_x | No | X position in rack units (optional) | |
| position_y | No | Y position (row, usually 0) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description lacks disclosure of behavioral traits such as what happens if the module already exists, if the filepath is invalid, or any side effects. This leaves the agent underinformed.
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?
A single concise sentence that communicates the core purpose without any wasted words.
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?
The tool has 5 parameters and no output schema, yet the description does not explain what the function returns, error conditions, or success indicators. It is incomplete for an agent to invoke correctly.
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?
Schema coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond the schema's parameter descriptions.
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?
The description clearly states the verb 'Add' and resource 'module to an existing patch', distinguishing it from siblings like 'create_patch' or 'connect_modules'.
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?
The description implies usage for adding a module to an existing patch but offers no explicit guidance on when to use this tool versus alternatives like 'modify_parameter' or 'list_modules'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze a Cardinal/VCV Rack patch file (.vcv) and explain what it does
| Name | Required | Description | Default |
|---|---|---|---|
| filepath | Yes | Path to the .vcv patch file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool analyzes and explains, but does not disclose whether it is read-only, what side effects exist, or the nature of the output.
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?
The description is a single sentence with 14 words, front-loaded with the action verb 'Analyze'. No unnecessary words.
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?
For a simple tool with one parameter and no output schema, the description is clear but lacks details about what the analysis output contains, which is important for an agent to know what to expect.
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?
Schema coverage is 100% with the filepath parameter described. The description adds context by naming Cardinal/VCV Rack and the .vcv extension, adding value beyond the schema.
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?
The description clearly states the tool analyzes a specific file type (.vcv) and explains what it does. It distinguishes from sibling tools like add_module or create_patch which are for making changes, not analysis.
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?
The description implies usage when understanding a patch is needed, but does not explicitly state when to use this tool versus alternatives or provide any usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Connect two modules with a cable
| Name | Required | Description | Default |
|---|---|---|---|
| color | No | Cable color (hex, e.g., '#ff5252') | |
| filepath | Yes | Path to the .vcv patch file | |
| to_input | Yes | Input port index | |
| from_output | Yes | Output port index | |
| to_module_id | Yes | Destination module ID | |
| from_module_id | Yes | Source module ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It lacks information on side effects (e.g., modifying the patch file), whether connections are validated, or if the tool is destructive. Minimal transparency beyond the action.
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?
The description is a single sentence that is concise and front-loaded. It efficiently states the purpose, though it could benefit from slightly more content without becoming verbose.
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?
Given 6 parameters, no output schema, and no annotations, the description is incomplete. It does not explain the return value or side effects (e.g., modifying a file). More context is needed for a tool that likely mutates the patch.
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?
Schema description coverage is 100%, so the input schema already documents all parameters. The description adds no additional meaning beyond what is in the schema. Baseline score of 3 is appropriate.
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?
The description 'Connect two modules with a cable' clearly states the verb (connect) and the resource (two modules with a cable). It distinguishes from sibling tools like add_module or modify_parameter, which have different purposes.
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?
The description does not provide explicit guidelines on when to use this tool versus alternatives. Usage is implied (when you need to connect modules), but no context on prerequisites or excluded cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new Cardinal/VCV Rack patch from a template or description
| Name | Required | Description | Default |
|---|---|---|---|
| template | Yes | Template name: 'basic-synth', 'ambient-pad', or 'empty' | |
| output_path | Yes | Where to save the patch file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It fails to disclose overwrite behavior, error conditions, or side effects. Only states 'Create a new patch' without elaboration.
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?
Single sentence, reasonably concise. But includes an inaccurate clause ('or description') that reduces clarity.
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?
Lacks details about template behaviors, output_path requirements, and error handling. No output schema or additional context. Incomplete for a creation tool with no annotations.
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?
Schema coverage is 100%, providing baseline 3. However, the description adds no value and even misaligns by referencing 'description' which is not a parameter, potentially misleading an AI agent.
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?
The description clearly states the tool creates a new Cardinal/VCV Rack patch, distinguishing it from sibling tools that add modules, analyze, or connect modules. However, it mentions 'or description' while the schema only has a 'template' parameter, causing slight confusion.
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?
No guidance on when to use this tool versus alternatives. No mention of prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available modules in the database with their descriptions
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Filter by category (oscillator, filter, vca, envelope, modulation, utility, sequencer, effect, io) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. Indicates read-only listing, but lacks details on pagination, sorting, or default behavior. Adequate but not rich.
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?
Single sentence, no waste. Key verb 'List' is front-loaded.
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?
Simple tool with one optional parameter. Description explains what is returned (modules with descriptions), but lacks output structure details. Adequate but could be improved.
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?
Schema coverage is 100%, so baseline 3. Description does not add meaning beyond what the schema provides for the category parameter.
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?
Clear verb 'List' and resource 'available modules' with context 'in the database with their descriptions'. Distinct from sibling tools (add, analyze, connect, create, modify, suggest).
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?
No guidance on when to use this tool versus alternatives. Does not mention prerequisites or conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Modify a parameter on a module
| Name | Required | Description | Default |
|---|---|---|---|
| value | Yes | New value (0.0 to 1.0 for most params) | |
| filepath | Yes | Path to the .vcv patch file | |
| param_id | Yes | Parameter ID | |
| module_id | Yes | Module ID to modify |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description lacks details on side effects, permissions, or destructive potential of modifying a parameter.
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?
Single sentence, no fluff, but may be too terse for completeness. Appropriate for a simple tool.
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?
No output schema, 4 required params, yet description fails to cover return behavior, error cases, or file existence constraints.
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?
Schema coverage is 100%, so baseline 3; description adds no extra meaning beyond what schema already provides.
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?
Description clearly states verb (modify) and resource (parameter on module), distinguishing from sibling tools like add_module, list_modules, etc.
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?
No guidance on when to use this tool versus alternatives; no exclusions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Suggest modules based on what you want to achieve
| Name | Required | Description | Default |
|---|---|---|---|
| goal | Yes | What you want to create (e.g., 'bass sound', 'ambient pad', 'drum pattern') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It implies a suggestion action but does not detail output format, whether it returns a list, or any constraints. The description is adequate but lacks depth for a tool with no annotations.
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?
The description is a single, front-loaded sentence with no unnecessary words. It is concise and to the point.
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?
Given the tool's simplicity (one parameter, no output schema), the description is adequate but incomplete. It does not clarify what 'suggest' entails (e.g., returns module names, IDs, or descriptions) or how many suggestions are provided.
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?
Schema coverage is 100% with the 'goal' parameter having a description. The tool description adds 'based on what you want to achieve', which echoes the schema description. No additional meaning or usage context is provided beyond the schema.
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?
The description 'Suggest modules based on what you want to achieve' clearly states the tool's purpose: to suggest modules given a goal. It distinguishes from siblings like 'add_module' (adds a module) and 'list_modules' (lists all modules) by focusing on suggestion from a goal.
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?
No guidance on when to use this tool vs alternatives. The description does not specify when not to use it or how it differs from similar tools like 'list_modules' or 'analyze_patch'. Sibling tools exist but no differentiation is provided.
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.
v1.0.0add_moduleanalyze_patchconnect_modulescreate_patchlist_modulesmodify_parametersuggest_modulesScored across 7 tools
Each tool targets a distinct operation: adding modules, analyzing patches, connecting modules, creating patches, listing modules, modifying parameters, and suggesting modules. There is no functional overlap.
All tool names follow a consistent verb_noun pattern (e.g., add_module, create_patch), using lowercase with underscores. No deviations.
7 tools is appropriate for a patch management server, covering creation, modification, analysis, and browsing without being overloaded or sparse.
The set covers create, read, update, and browse operations. Missing explicit delete or disconnect functionality might be a minor gap, but core workflows are well-supported.
Parametric 3D CAD for AI agents: build print-ready parts, check them, export STL, 3MF or STEP.
Manage ElevenLabs voice agents and generate speech, music, sound effects, images, and video.
Create RF signal projects from prompts, inspect graphs, and export IQ data.
Connect AI assistants to GitHub - manage repos, issues, PRs, and workflows through natural language.
