Click on "Install 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., "@Csound MCP Server Create a punchy house kick with high drive"
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.
The Csound MCP server exposes Csound audio engine functionality to AI agents via the Model Context Protocol (MCP).
Stateless Architecture: Lightweight execution using standard Csound.
Subtractive Synthesis: Exposes a synthesize_sawtooth_lead_bass tool that provides LLM-friendly 0-255 mapped ADSR parameters to shape a sawtooth oscillator run through a lowpass filter.
Drum Synthesis: Exposes a synthesize_kick_drum tool specialized for crafting Sub Basses, punchy House kicks, and distorted Hardstyle kicks using intuitive parameters like punch and drive.
Semantic Guardrails: The tool parameters are heavily documented with acoustic definitions (e.g., matching "fast attack" to integer ranges), and MCP Resources (lore://sound_design, lore://drum_design) are provided to teach agents how to synthesize classic instruments.
Error Handling: Gracefully captures and returns stdout and stderr content to the agent if csound compilation or execution fails.
Related MCP server: SuperCollider MCP Server
The package is built with Python and depends on mcp. You can run the server directly using uv:
uv run musmcpTo configure this server in an MCP client (such as Claude Desktop or Cursor), add it to your configuration (adjust the root path to your workspace directory):
{
"mcpServers": {
"musmcp": {
"command": "uv",
"args": [
"--directory",
"/path/to/your/workspace/musmcp",
"run",
"musmcp"
]
}
}
}Before using the synthesis tools, an agent can read the provided lore://sound_design and lore://drum_design MCP resources to understand how to map acoustic concepts to the 0-255 integers.
synthesize_sawtooth_lead_bassThe synthesize_sawtooth_lead_bass tool is specifically designed to be easy for LLM agents to use. It abstracts complex Csound envelopes into simple 0-255 integers.
Here is how an agent should map desired sounds to the tool's parameters:
1. A Plucky/Percussive Bass (Fast attack, fast decay, no sustain)
{
"pitch": 55.0,
"duration": 1.5,
"cutoff_hz": 400.0,
"attack": 5,
"decay": 80,
"sustain": 0,
"release": 50,
"output_filename": "bass_pluck.wav"
}2. A Warm Pad (Slow attack, high sustain, long release)
{
"pitch": 220.0,
"duration": 4.0,
"cutoff_hz": 1200.0,
"attack": 150,
"decay": 100,
"sustain": 200,
"release": 200,
"output_filename": "warm_pad.wav"
}3. An Aggressive Lead (Fast attack, high sustain, bright filter)
{
"pitch": 880.0,
"duration": 2.0,
"cutoff_hz": 4500.0,
"attack": 10,
"decay": 50,
"sustain": 255,
"release": 20,
"output_filename": "aggr_lead.wav"
}synthesize_kick_drumA dedicated tool for creating everything from soft acoustic thumps to booming 808s and distorted hard kicks.
1. 808 Sub Kick (Booming, no hard click)
{
"fundamental_hz": 45.0,
"punch": 20,
"decay": 220,
"drive": 10,
"output_filename": "808_sub.wav"
}2. Hardstyle / Industrial Kick (Heavily distorted with massive click)
{
"fundamental_hz": 50.0,
"punch": 200,
"decay": 150,
"drive": 220,
"output_filename": "hard_kick.wav"
}Generate a classic analog-style kick drum using a Sine oscillator with a pitch envelope.
Args: fundamental_hz: The resting sub-bass frequency in Hz (e.g., 40.0 - 80.0 Hz). punch: The speed and intensity of the initial transient click (0-255). - 0-50: Soft, acoustic-style thump. - 100-150: Punchy EDM/House kick. - 200-255: Hard, laser-like transient (Psytrance/Hardstyle). decay: The length of the amplitude decay (0-255). - 10-50: Short, tight clicky kick. - 100-150: Standard club kick. - 200-255: Long, booming 808 sub. drive: Amount of saturation/distortion to apply (0-255). - 0-20: Clean sine wave, smooth sub. - 100-150: Warm, saturated analog feel. - 200-255: Heavily distorted, gabber/hardcore kick. output_filename: Optional name for the output file.
Returns: The absolute path to the generated .wav file.
| Name | Required | Description | Default |
|---|---|---|---|
| decay | Yes | ||
| drive | Yes | ||
| punch | Yes | ||
| fundamental_hz | Yes | ||
| output_filename | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the synthesis method (Sine oscillator + pitch envelope), describes the return value (absolute path to .wav file), and explains parameter effects (punch, decay, drive behaviors). It could add details about execution time, file format specifics beyond .wav, or side effects, but covers the essential behavioral contract well.
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 well-structured with clear Args/Returns sections and organized parameter blocks with range examples. Each parameter entry is dense with useful information. It's longer than minimal but every line serves a purpose - no filler. The range formatting is slightly verbose but aids comprehension.
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?
Despite an output schema being present, the description still explains the return value (path to generated .wav). All 5 parameters are semantically documented with practical guidance. The tool is moderate complexity (sound synthesis with musical nuance) and the description covers the musical intent, technical mechanism, and expected output fully. No significant gaps remain.
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?
With 0% schema description coverage, the description must fully compensate, and it does impressively. Each parameter (fundamental_hz, punch, decay, drive) gets detailed semantic ranges with concrete value brackets and musical interpretations. The output_filename is self-explanatory. This exceeds the baseline compensation required for low coverage.
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 'Generate a classic analog-style kick drum using a Sine oscillator with a pitch envelope' - a specific verb+resource+method. It distinguishes from the sibling synthesize_sawtooth_lead_bass by specifying Sine oscillator and kick drum specifically, making the purpose unique and clear.
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 provides concrete parameter ranges with musical context (0-50 soft acoustic, 100-150 punchy EDM/House kick, etc.), giving clear guidance on how to craft different sounds. However, it doesn't explicitly state when to choose this tool over the sibling sawtooth lead bass tool, though the distinct purposes make this somewhat implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a tone using a subtractive sawtooth oscillator and lowpass filter. Perfect for designing classic synthesizer Basses, Leads, and Plucks.
Args: pitch: The fundamental frequency in Hz (e.g., 55.0 for Bass, 440.0 for Lead). duration: The total length of the note in seconds. cutoff_hz: Filter brightness. - 100-400: Dark, muffled (Bass, Deep Pads) - 800-1500: Warm, midrange (Warm Pads, Keys) - 2000-5000: Bright, piercing (Leads, Plucks) attack: Time to reach max volume (0-255). - 0-10: Instant hit (Plucks, Kicks, Percussive Bass) - 50-100: Medium swell (Soft Leads, Strings) - 150-255: Very slow fade in (Ambient Pads, Drones) decay: Time to drop from max volume to sustain level (0-255). - 10-50: Fast drop (Punchy Bass) - 80-150: Natural decay (Keys, Guitars) sustain: Level held after decay phase (0-255). - 0: Note dies out entirely (Plucks, Percussion) - 255: Note holds at maximum volume (Organs, Synths) release: Fade out time after the note ends (0-255). - 10-30: Stops immediately (Staccato Bass, Tight Leads) - 150-255: Long ringing tail (Cinematic Pads, Reverbs) output_filename: Optional name for the output file (e.g. 'warm_pad.wav').
Returns: The absolute path to making the generated .wav file.
| Name | Required | Description | Default |
|---|---|---|---|
| decay | Yes | ||
| pitch | Yes | ||
| attack | Yes | ||
| release | Yes | ||
| sustain | Yes | ||
| duration | Yes | ||
| cutoff_hz | Yes | ||
| output_filename | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With NO annotations provided, the description carries the full behavioral disclosure burden. It does this well by documenting the return value (absolute path to .wav file) and providing rich per-parameter behavioral context (attack hits, decays, releases). However, it could add detail about preconditions, edge cases, or failure behavior that would further improve transparency.
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 well-structured with a clear intro, per-parameter sections, and a returns line. It's substantial in length but every sentence earns its place by providing actionable range mappings. A minor deduction for the Args-style structure using Python docstring conventions which is slightly verbose but remains scannable.
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 complex 8-parameter synthesis tool with zero schema coverage, descriptions and no annotations, this is remarkably complete. It provides usage examples, parameter ranges, and return value documentation. An output schema exists but the description still clarifies the logical return ('absolute path'). Could be slightly more complete with failure/validation behavior but is strong overall.
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 0%, so the description must fully compensate for the 8 undocumented parameters. It does this exceptionally well, providing range-based guidance for pitch, cutoff_hz, attack, decay, sustain, and release with concrete examples mapping to sound types (e.g., '0-10: Instant hit (Plucks, Kicks)'). This significantly exceeds what the raw schema would convey.
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 it generates a tone using a subtractive sawtooth oscillator and lowpass filter, explicitly naming the purpose ('synthesizer Basses, Leads, and Plucks'). The verb 'Generate' + specific resource (sawtooth oscillator + lowpass filter) is precise, and the name itself differentiates from sibling (synthesize_kick_drum) by specifying the waveform type.
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 provides instrument categories (Basses, Leads, Plucks) but does not explicitly state when to use this tool vs. the sibling synthesize_kick_drum. It implies usage through sound-character descriptions in parameter ranges but never names the alternative. No explicit when-not-to-use or exclusion guidance is given.
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. Dates show when Glama detected each change.
v0.1.0synthesize_kick_drumsynthesize_sawtooth_lead_bassThe two tools target completely distinct synthesis domains: one generates pitched sawtooth-based notes with full ADSR control, the other generates percussion via a pitch-enveloped sine. There is no ambiguity or overlap between them.
Both tools follow the same synthesize_verb_noun pattern, which is consistent. The noun modifiers differ in specificity (sawtooth_lead_bass vs kick_drum), but the overall convention is uniform.
With only 2 tools, the server feels very thin for what appears to be a Csound synthesis toolkit. A synthesis server would naturally expect more generators (e.g., pads, plucks, snare, hi-hats, noise, additive/PM synthesis), making 2 tools under-scoped.
The server covers two synthesis archetypes but leaves major gaps—no percussion beyond kick (no snare, hi-hat, clap), no pad/ambient generator, no general-purpose note/synth tool, and no ability to layer or render composed arrangements. An agent needing common synthesis tasks will hit dead ends.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
AI music and podcast platform for autonomous agents. SoundCloud for AI bots.
AI music, video, image, and voice tools callable by agents with USDC payments via x402 on Base.
Turn any LLM multimodal; generate images, voices, videos, 3D models, music, and more.
Generate game-ready 3D models, textures, and audio from natural language, over MCP.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/erno-szabados/musmcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
