Un servidor de protocolo de contexto de modelo para generar configuraciones de kit de batería de Sampler Decent .
Este servidor MCP basado en TypeScript proporciona herramientas especializadas y avisos para crear ajustes preestablecidos del kit de batería DecentSampler, incluido el análisis de archivos WAV y la generación de XML.
Advertencia: La creación de presets complejos puede exceder la longitud máxima de mensaje de Claude Desktop. Seguimos trabajando para optimizar esta herramienta y solucionar esta limitación. Si creas presets sencillos sin muchos micrófonos ni otras variaciones, el archivo XML debe ser lo suficientemente pequeño como para que Claude pueda escribirlo.
Related MCP server: MCP Audio Inspector
¿Cómo uso estas herramientas? - Flujos de trabajo paso a paso con ejemplos reales
Documentación de herramientas : información detallada sobre cada herramienta disponible
Esquemas de entrada : interfaces de TypeScript y descripciones de parámetros
Node.js (v14 o superior)
npm (normalmente viene con Node.js)
Aplicación de escritorio de Claude (para usar con Claude)
Instalar dependencias:
npm installConstruir el servidor:
npm run buildAñade a tu configuración de Claude Desktop:
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": {}
}
}
}Para desarrollo con reconstrucción automática:
npm run watchPara la depuración, utilice el Inspector MCP:
npm run inspectorAl utilizar este servidor MCP para generar ajustes preestablecidos simples, siempre debe hacer referencia al mensaje simple_preset_guidelines .
Para presets más complejos (incluyendo secciones como buses, efectos, etc.), consulte el aviso advanced_preset_guidelines . Tenga en cuenta que crear presets complejos con un gran número de muestras puede ser inestable y podría exceder la longitud máxima de mensaje de Claude Desktop.
Ambos mensajes le pedirán que proporcione un argumento samplesDirectory; este debe ser la ruta absoluta a su carpeta de samples de batería (p. ej., "C:/Usuarios/nombreusuario/Documentos/MuestrasDeBatería"). El mensaje usará automáticamente este directorio en todos los ejemplos y configuraciones, lo que facilita el seguimiento de las rutas correctas para su sistema.
Decent Sampler es un complemento de muestreo GRATUITO que te permite reproducir muestras en el formato Decent Sampler.
El objetivo de este servidor MCP es facilitar la configuración de tus propios presets, ya sea que uses tus utensilios de cocina en tu teléfono o grabes una batería completa en un estudio. Para crear tus propios kits de batería, también necesitarás samples.
Si aún no tienes muestras listas para usar, aquí hay algunos recursos para comenzar:
99sounds.org
Colección de muestras de batería : varios kits de batería y muestras de percusión
Sonidos de Dub y Reggae : Colección especializada de sonidos de batería de reggae
Archive.org: Colección de Sample Packs - Samples de batería aportados por la comunidad, ordenados por popularidad. Incluye material genial, como cajas de ritmos clásicas y samples de CMI Fairlight.
Sample Pack Nation: Kits de batería Oberheim DMX/DX : sonidos clásicos de caja de ritmos (menos de 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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
analyze_wav_samplesconfigure_drum_controlsconfigure_mic_routingconfigure_round_robingenerate_drum_groupsScored across 5 tools
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.
Edit DAW sessions; convert Logic/Ableton/FL/PT/REAPER/Cubase/Dorico; stems, transcribe, generate
Discover free, licensed loops and analyze authorized audio for BPM, musical key and waveform data. Start with free discovery and see estimated costs before paid analysis.
Screenplay, film and story toolkit over MCP: PDF formatting, stats, diagnosis, video prompts.
Create RF signal projects from prompts, inspect graphs, and export IQ data.
