Decent Sampler 드럼 키트 구성을 생성하기 위한 모델 컨텍스트 프로토콜 서버입니다.
TypeScript 기반 MCP 서버는 WAV 파일 분석 및 XML 생성을 포함하여 DecentSampler 드럼 키트 프리셋을 만드는 데 필요한 특수 도구와 프롬프트를 제공합니다.
경고: 복잡한 프리셋을 만들면 Claude Desktop의 최대 메시지 길이를 초과할 수 있습니다. 이 제한을 해결하기 위해 도구를 간소화하는 작업을 계속 진행하고 있습니다. 마이크나 기타 변형이 많지 않은 간단한 프리셋을 만드는 경우, Claude가 파일에 쓸 수 있을 만큼 XML 파일의 크기가 작아야 합니다.
Related MCP server: MCP Audio Inspector
이 도구들을 어떻게 사용하나요? - 실제 사례를 통한 단계별 워크플로
도구 설명서 - 사용 가능한 각 도구에 대한 자세한 정보
입력 스키마 - TypeScript 인터페이스 및 매개변수 설명
Node.js(v14 이상)
npm(일반적으로 Node.js와 함께 제공됨)
Claude 데스크톱 앱(Claude와 함께 사용)
종속성 설치:
지엑스피1
서버를 빌드하세요:
npm run buildClaude 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": {}
}
}
}자동 재빌드를 사용한 개발의 경우:
npm run watch디버깅을 위해 MCP Inspector를 사용하세요.
npm run inspector이 MCP 서버를 사용하여 간단한 사전 설정을 생성하는 경우 항상 simple_preset_guidelines 프롬프트를 참조해야 합니다.
버스, 효과 등의 섹션을 포함한 더 복잡한 프리셋의 경우, advanced_preset_guidelines 프롬프트를 참조하세요. 샘플 수가 많은 복잡한 프리셋을 만들면 불안정할 수 있으며 Claude Desktop의 최대 메시지 길이를 초과할 수 있습니다.
두 프롬프트 모두 samplesDirectory 인수를 입력하도록 요청합니다. 이 인수는 드럼 샘플 폴더의 절대 경로여야 합니다(예: "C:/Users/username/Documents/DrumSamples"). 그러면 프롬프트가 모든 예제와 구성에서 이 디렉터리를 자동으로 사용하므로 시스템에 맞는 올바른 경로를 쉽게 따라갈 수 있습니다.
Decent Sampler는 Decent Sampler 포맷의 샘플을 재생할 수 있는 무료 샘플링 플러그인입니다.
이 MCP 서버의 목표는 주방용품 소리를 휴대폰으로 재생하든, 스튜디오에서 전체 드럼 키트를 녹음하든, 나만의 프리셋을 더 쉽게 설정할 수 있도록 하는 것입니다. 나만의 드럼 키트를 만들려면 샘플도 필요합니다.
아직 사용할 샘플이 없다면 시작하는 데 도움이 되는 몇 가지 리소스를 소개합니다.
99사운드.org
드럼 샘플 컬렉션 - 다양한 드럼 키트와 타악기 샘플
더브 & 레게 사운드 - 레게 드럼 사운드의 전문 컬렉션
Archive.org: 샘플 팩 컬렉션 - 커뮤니티에서 기여한 드럼 샘플을 인기순으로 정리했습니다. 빈티지 드럼 머신과 CMI Fairlight 샘플 등 멋진 샘플들이 포함되어 있습니다.
샘플 팩 네이션: 오버하임 DMX/DX 드럼 키트 - 클래식 드럼 머신 사운드 (10달러/유로 미만)
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.
