The Decent-Sampler Drums MCP Server is a TypeScript-based tool for creating and managing Decent Sampler drum kit configurations with the following capabilities:
WAV File Analysis: Validate and analyze samples for metadata, compatibility issues, and technical specifications
Global Drum Controls: Configure pitch and envelope settings with MIDI CC mappings
Multi-Mic Routing: Set up volume controls and routing for multiple mic positions with dedicated outputs
Round Robin Playback: Implement sequential, random, or true random sample playback modes
Velocity Layer Handling: Create dynamic control through velocity layers
Muting Groups: Configure realistic drum behavior (e.g., closed/open hi-hats)
XML Generation: Produce the necessary XML structure for both simple and advanced Decent Sampler presets
Error Handling: Provide detailed diagnostic messages for configuration issues
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., "@Decent-Sampler Drums MCP Server analyze the WAV files in my drum samples folder and create a basic kit preset"
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.
A Model Context Protocol server for generating Decent Sampler drum kit configurations.
This TypeScript-based MCP server provides specialized tools and prompts for creating DecentSampler drum kit presets, including WAV file analysis and XML generation.
Warning: Creating complex presets may end up exceeding Claude Desktop's maximum message length. We are still working on streamlining this tool to work around this limitation. If you are creating simple presets without a lot of mics or other variations, the xml file should be small enough for Claude to write to a file.
Related MCP server: MIDI Analyzer MCP Server
How do I use these tools? - Step-by-step workflows with real examples
Tools Documentation - Detailed information about each available tool
Input Schemas - TypeScript interfaces and parameter descriptions
Node.js (v14 or higher)
npm (usually comes with Node.js)
Claude Desktop app (for use with Claude)
Install dependencies:
npm installBuild the server:
npm run buildAdd to your Claude Desktop config:
Windows: %APPDATA%/Claude/claude_desktop_config.json
MacOS: ~/Library/Application Support/Claude/claude_desktop_config.json
{
"mcpServers": {
"decent-sampler-drums": {
"command": "npx",
"args": [
"-y",
"@dandeliongold/mcp-decent-sampler-drums"
],
"env": {}
}
}
}For development with auto-rebuild:
npm run watchFor debugging, use the MCP Inspector:
npm run inspectorWhen using this MCP server to generate simple presets, you should always reference the simple_preset_guidelines prompt.
For more complex presets (including sections such as buses, effects, etc.), reference the advanced_preset_guidelines prompt. Note that creating complex presets with a large number of samples can still be unstable and may exceed Claude Desktop's maximum message length.
Both prompts will ask you to provide a samplesDirectory argument - this should be the absolute path to your drum samples folder (e.g., "C:/Users/username/Documents/DrumSamples"). The prompt will then automatically use this directory in all examples and configurations, making it easier to follow along with the correct paths for your system.
Decent Sampler is a FREE sampling plugin that allows you to play samples in the Decent Sampler format.
The goal of this MCP server is to make it easier to set up your own presets, whether you're playing your kitchen utensils into your phone, or recording a full kit in a studio. To create your own drum kits, you'll also need samples.
If you don't already have samples ready to go, here are some resources to get started:
99sounds.org
Drum Samples Collection - Various drum kits and percussion samples
Dub & Reggae Sounds - Specialized collection of reggae drum sounds
Archive.org: Sample Pack Collection - Community-contributed drum samples, sorted by popularity. Includes some cool stuff like vintage drum machines and CMI Fairlight samples.
Sample Pack Nation: Oberheim DMX/DX Drumkits - Classic drum machine sounds (Under 10 USD/EUR)
Analyze WAV files to detect common issues in drum kit samples.
This tool checks for:
Non-standard WAV headers that may cause playback issues
Metadata inconsistencies that could affect multi-mic setups
Sample rate and bit depth compatibility
Channel configuration issues
File size and format validation
Error Handling:
Reports detailed header format issues
Identifies metadata inconsistencies between related samples
Flags potential playback compatibility problems
Returns specific error messages for each issue type
Success Response: Returns detailed analysis including:
WAV header information
Sample metadata
Potential compatibility issues
Recommendations for fixes
IMPORTANT: Always use absolute paths (e.g., 'C:/Users/username/Documents/Samples/kick.wav') rather than relative paths.
| Name | Required | Description | Default |
|---|---|---|---|
| paths | Yes | Array of absolute paths to WAV files to analyze (e.g., ['C:/Users/username/Documents/Samples/kick.wav']) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes what the tool does: checks for specific issues (e.g., non-standard headers, metadata inconsistencies), handles errors with detailed reports, and returns success responses with analysis details. It also specifies the requirement for absolute paths, adding operational context. However, it lacks information on potential side effects, rate limits, or authentication needs, which are minor gaps.
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 sections (e.g., 'This tool checks for:', 'Error Handling:', 'Success Response:', 'IMPORTANT:'), making it easy to scan. It is appropriately sized for the tool's complexity, but some redundancy exists (e.g., repeating path guidance in the description and schema), and the bullet points could be more concise without losing 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?
Given the tool's moderate complexity (analyzing WAV files for issues), no annotations, and no output schema, the description is largely complete. It covers purpose, checks, error handling, success response, and path requirements. However, it does not detail the format of the analysis output (e.g., structure of returned data), which is a minor gap since there's no output schema to compensate.
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?
The input schema has 100% description coverage, clearly documenting the 'paths' parameter as an array of absolute paths. The description reinforces this with an 'IMPORTANT' note about using absolute paths and provides an example, but does not add significant meaning beyond what the schema already states. This meets the baseline score of 3 for high schema 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 the tool's purpose: 'Analyze WAV files to detect common issues in drum kit samples.' It specifies the verb ('analyze'), resource ('WAV files'), and scope ('drum kit samples'), distinguishing it from sibling tools like configure_drum_controls or generate_drum_groups, which focus on configuration and generation rather than 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 provides clear context for when to use this tool: for analyzing WAV files to detect issues in drum kit samples. It includes an 'IMPORTANT' note about using absolute paths, which adds practical guidance. However, it does not explicitly state when not to use it or name alternatives among sibling tools, such as whether to use this for general audio files vs. drum-specific samples.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Configure global pitch and envelope controls for each drum type.
This tool will:
Add per-drum pitch controls with customizable ranges
Configure ADSR envelope settings for natural decay control
Generate proper XML structure for global drum controls
Error Handling:
Validates pitch range values (min/max must be valid numbers)
Ensures envelope times are positive values
Verifies curve values are within -100 to 100 range
Returns detailed error messages for invalid configurations
Success Response: Returns XML structure containing:
Global controls for each drum type
MIDI CC mappings for real-time control
Properly formatted parameter bindings
| Name | Required | Description | Default |
|---|---|---|---|
| drumControls | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does an excellent job disclosing behavioral traits. It clearly explains the tool generates XML structure, details comprehensive error handling with specific validation rules, and describes the success response format including MIDI CC mappings and parameter bindings.
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 sections (purpose, what the tool will do, error handling, success response) and appropriately sized. Every sentence adds value, though the bullet points could be slightly more concise. The information is front-loaded with the core purpose first.
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 configuration tool with no annotations and no output schema, the description provides substantial context about behavior, error handling, and response format. It covers what the tool does, how it validates inputs, and what it returns, though it could benefit from more parameter semantics and usage guidance.
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 compensate but only partially succeeds. While it mentions 'pitch controls with customizable ranges' and 'ADSR envelope settings', it doesn't explain the drumControls object structure or provide semantic context for the nested parameters. The description adds some value but doesn't fully compensate for the schema's lack of 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 specific action ('configure global pitch and envelope controls') and resource ('for each drum type'), distinguishing it from sibling tools like analyze_wav_samples or generate_drum_groups. The first sentence provides a complete purpose statement with verb, resource, and scope.
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 no guidance on when to use this tool versus alternatives. There's no mention of prerequisites, when this configuration should be applied, or how it relates to sibling tools like configure_mic_routing or configure_round_robin. The agent receives no usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Configure multi-mic routing with MIDI controls for drum samples.
This tool will:
Set up individual volume controls for each mic position (close, OH L/R, room L/R)
Route each mic to its own auxiliary output for DAW mixing
Configure MIDI CC mappings for mic volumes
Generate proper XML structure for DecentSampler
Error Handling:
Validates mic position assignments
Checks for duplicate MIDI CC assignments
Ensures valid output routing targets
Verifies bus indices are unique and valid
Returns specific errors for routing conflicts
Success Response: Returns XML structure containing:
Configured mic bus routing
Volume control mappings
MIDI CC assignments
Complete routing matrix for all samples
| Name | Required | Description | Default |
|---|---|---|---|
| micBuses | Yes | ||
| drumPieces | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: error handling (validations for mic positions, MIDI CC duplicates, routing conflicts) and success response (XML structure with routing, mappings, assignments). However, it lacks details on side effects, performance, or authentication needs, which would be beneficial for a configuration tool.
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 sections (purpose, error handling, success response) and uses bullet points for readability. It is appropriately sized but could be slightly more concise by integrating some bullet points into flowing text without losing 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?
Given the complexity (2 parameters with nested objects, no output schema, no annotations), the description is mostly complete. It covers purpose, behaviors, and parameter semantics effectively. However, it lacks output details beyond XML content, and with no annotations, additional context like side effects or rate limits would improve completeness.
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 compensate fully. It does so by explaining the purpose and structure of parameters: 'micBuses' for volume controls and routing, 'drumPieces' for samples with mic configurations. The description adds meaning beyond the bare schema, clarifying how parameters relate to the tool's functionality.
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's purpose: 'Configure multi-mic routing with MIDI controls for drum samples.' It specifies the exact actions (setting up volume controls, routing to auxiliary outputs, configuring MIDI mappings, generating XML) and distinguishes itself from sibling tools like 'configure_drum_controls' or 'generate_drum_groups' by focusing on mic routing specifically.
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 no guidance on when to use this tool versus alternatives like 'configure_drum_controls' or 'generate_drum_groups'. It lists what the tool does but does not specify scenarios, prerequisites, or exclusions, leaving the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Configure round robin sample playback for a set of samples.
This tool will:
Validate sequence positions
Verify sample files exist
Generate proper XML structure for round robin playback
Error Handling:
Checks if sample files exist at specified paths
Validates sequence positions are unique and sequential
Ensures mode is one of: round_robin, random, true_random, always
Returns specific error messages for missing files or invalid sequences
Success Response: Returns XML structure with:
Configured playback mode
Sample sequence assignments
Proper group organization for round robin playback
| Name | Required | Description | Default |
|---|---|---|---|
| directory | Yes | Absolute path to the directory containing samples | |
| mode | Yes | Round robin playback mode | |
| length | Yes | Number of round robin variations | |
| samples | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes what the tool does: validation steps (checking file existence, sequence positions), error handling specifics, and success response content. However, it doesn't mention potential side effects, performance characteristics, or authentication requirements, leaving some behavioral aspects uncovered.
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 and appropriately sized. It uses clear sections (Error Handling, Success Response) with bullet points for readability. Every sentence adds value: the opening statement defines purpose, bullet points explain validation steps, and response details clarify outcomes. No redundant information is present.
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 complexity (4 parameters, validation logic, no output schema), the description provides substantial context. It covers what the tool does, validation rules, error cases, and success response format. However, without annotations or output schema, it could benefit from more detail on side effects or performance considerations, though it's largely complete for practical use.
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?
The description adds meaningful context beyond the input schema. While the schema has 75% description coverage, the tool description clarifies parameter relationships: directory is the base for sample paths, mode must be one of four specific values, length defines sequence bounds, and samples require path and seqPosition. It explains that seqPosition must be unique and sequential (1 to length), which isn't fully captured in the schema 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 tool's purpose: 'Configure round robin sample playback for a set of samples.' It specifies the exact action (configure), resource (round robin sample playback), and scope (set of samples). This distinguishes it from sibling tools like analyze_wav_samples or generate_drum_groups, which have different functions.
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 no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools or explain scenarios where configure_round_robin is appropriate compared to other configuration tools like configure_drum_controls or configure_mic_routing. Usage context is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate DecentSampler XML for drum kits.
This tool supports two configuration types:
BasicDrumKitConfig:
For simple presets with minimal features
No UI controls, effects, or routing
Only supports basic sample mapping and optional velocity layers
Recommended for straightforward drum kits
AdvancedDrumKitConfig:
For complex setups combining multiple features
Supports UI controls, effects, and routing
Integrates with other tools (configure_drum_controls, configure_mic_routing, etc.)
Use when you need advanced features like round robin or multi-mic setups
Best Practices:
IMPORTANT: Always use absolute paths (e.g., 'C:/Users/username/Documents/Samples/kick.wav')
Group all samples for a drum piece into a single group
When using multiple mic positions, include them all in the same group
Use velocity layers within a group to control dynamics
Error Handling:
Validates all sample paths exist
Checks for valid MIDI note numbers
Ensures velocity layers don't overlap
Verifies muting group configurations
Returns specific errors for any invalid settings
Example Configurations:
Basic Configuration (simple drum kit): { "globalSettings": { "velocityLayers": [ { "low": 1, "high": 42, "name": "soft" }, { "low": 43, "high": 85, "name": "medium" }, { "low": 86, "high": 127, "name": "hard" } ] }, "drumPieces": [{ "name": "Kick", "rootNote": 36, "samples": [ {"path": "C:/Samples/Kick_Soft.wav"}, {"path": "C:/Samples/Kick_Medium.wav"}, {"path": "C:/Samples/Kick_Hard.wav"} ] }] }
Advanced Configuration (multi-mic kit with controls): { "globalSettings": { "velocityLayers": [ { "low": 1, "high": 127, "name": "full" } ], "drumControls": { "kick": { "pitch": { "default": 0, "min": -12, "max": 12 }, "envelope": { "attack": 0.001, "decay": 0.5, "sustain": 0, "release": 0.1 } } }, "micBuses": [ { "name": "Close Mic", "outputTarget": "MAIN_OUTPUT", "volume": { "default": 0, "midiCC": 20 } } ] }, "drumPieces": [{ "name": "Kick", "rootNote": 36, "samples": [ { "path": "C:/Samples/Kick_Close.wav", "micConfig": { "position": "close", "busIndex": 0 } } ], "muting": { "tags": ["kick"], "silencedByTags": [] } }] }
Success Response: Returns complete XML structure with:
Organized sample groups
Velocity layer mappings
Muting group configurations
All sample references and settings
Advanced features when using AdvancedDrumKitConfig
| Name | Required | Description | Default |
|---|---|---|---|
| globalSettings | Yes | ||
| drumPieces | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does an excellent job disclosing behavioral traits: it explains error handling (validates paths, MIDI notes, velocity layers), best practices (absolute paths, grouping samples), and success response details. It doesn't mention performance characteristics like rate limits or authentication needs, but covers most operational behavior thoroughly.
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 sections (configuration types, best practices, error handling, examples, success response) and every sentence adds value. While comprehensive, it's appropriately sized for a complex tool with 0% schema coverage. The front-loaded purpose statement is clear, though some details could be more condensed.
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 complexity (2 nested parameters, 0% schema coverage, no output schema, no annotations), the description provides complete context: it explains what the tool does, how to use it, what inputs mean, what errors to expect, and what the output contains. The examples and success response details compensate for the lack of output schema.
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 and 2 complex nested parameters, the description compensates fully by explaining both configuration types in detail, providing comprehensive examples, and clarifying the meaning of key fields like velocityLayers, drumPieces, samples, muting, and advanced features. It adds substantial meaning beyond the bare schema structure.
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 specific action ('Generate DecentSampler <groups> XML for drum kits') with the exact output format and target resource. It distinguishes from sibling tools by focusing on XML generation rather than analysis or configuration tasks like 'analyze_wav_samples' or 'configure_drum_controls'.
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 explicit guidance on when to use each configuration type (BasicDrumKitConfig vs AdvancedDrumKitConfig), including specific scenarios and recommendations. It mentions integration with sibling tools ('configure_drum_controls, configure_mic_routing, etc.') and clearly states when to use advanced features versus basic ones.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose with no overlap: analyze_wav_samples checks file quality, configure_drum_controls sets pitch/envelope, configure_mic_routing handles mic outputs, configure_round_robin manages playback sequences, and generate_drum_groups creates XML structures. The descriptions specify unique functions, eliminating confusion.
Tools follow a consistent verb_noun pattern (e.g., analyze_wav_samples, configure_drum_controls) with clear, descriptive names. The minor deviation is 'generate_drum_groups' using 'generate' instead of 'configure', but overall naming is predictable and readable.
With 5 tools, the set is well-scoped for creating and configuring drum kits in DecentSampler. Each tool addresses a specific aspect (analysis, controls, routing, playback, XML generation), providing comprehensive coverage without bloat or redundancy.
The toolset fully covers the drum kit creation lifecycle: from analyzing sample files (analyze_wav_samples) to configuring controls (configure_drum_controls), routing (configure_mic_routing), playback (configure_round_robin), and generating the final XML (generate_drum_groups). There are no obvious gaps; agents can handle end-to-end workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Convert projects between Logic, Ableton, FL Studio and REAPER; generate, separate, transcribe
Create RF signal projects from prompts, inspect graphs, and export IQ data.
Create, co-edit, analyze, publish, and export collaborative step-sequencer sessions through MCP.
Audio features + harmonic set-building for tracks by name/ISRC. Spotify audio-features replacement.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/dandeliongold/mcp-decent-sampler-drums'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
