Decent Samplerドラム キット構成を生成するためのモデル コンテキスト プロトコル サーバー。
この TypeScript ベースの MCP サーバーは、WAV ファイルの分析や XML 生成など、DecentSampler ドラム キット プリセットを作成するための専用のツールとプロンプトを提供します。
**警告：**複雑なプリセットを作成すると、Claude Desktop の最大メッセージ長を超える可能性があります。この制限を回避するため、ツールの効率化に取り組んでいます。マイクやその他のバリエーションをあまり使用しないシンプルなプリセットを作成する場合は、xml ファイルは Claude が書き込める程度に小さくしてください。
Related MCP server: MCP Audio Inspector
これらのツールはどのように使用すればいいですか？ - 実際の例を使ったステップバイステップのワークフロー
ツールドキュメント- 利用可能な各ツールの詳細情報
入力スキーマ- TypeScript インターフェースとパラメータの説明
Node.js (v14以上)
npm (通常はNode.jsに付属)
Claude デスクトップ アプリ (Claude で使用)
依存関係をインストールします:
npm installサーバーを構築します。
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 インスペクターを使用します。
npm run inspectorこの MCP サーバーを使用してシンプルなプリセットを生成する場合は、常にsimple_preset_guidelinesプロンプトを参照する必要があります。
より複雑なプリセット（バス、エフェクトなどのセクションを含む）については、 advanced_preset_guidelinesプロンプトを参照してください。ただし、多数のサンプルを含む複雑なプリセットを作成すると、動作が不安定になり、Claude Desktopの最大メッセージ長を超える可能性があります。
どちらのプロンプトでも、samplesDirectory 引数を指定するよう求められます。これはドラムサンプルフォルダへの絶対パス（例："C:/Users/username/Documents/DrumSamples"）です。これにより、プロンプトはすべてのサンプルと設定でこのディレクトリを自動的に使用するため、システムの正しいパスを簡単に確認できるようになります。
Decent Sampler は、Decent Sampler 形式でサンプルを再生できる無料のサンプリング プラグインです。
このMCPサーバーの目的は、キッチン用品の音をスマートフォンに取り込む場合でも、スタジオでフルキットを録音する場合でも、独自のプリセットを簡単に設定できるようにすることです。独自のドラムキットを作成するには、サンプルも必要です。
まだサンプルの準備ができていない場合は、次のリソースを参考に開始してください。
99sounds.org
ドラムサンプルコレクション- さまざまなドラムキットとパーカッションサンプル
Dub & Reggae Sounds - レゲエドラムサウンドの専門コレクション
Archive.org: サンプルパックコレクション- コミュニティ投稿のドラムサンプルを人気順にまとめています。ビンテージドラムマシンやCMI Fairlightサンプルなど、クールなサンプルも収録されています。
サンプルパックネイション： Oberheim DMX/DX ドラムキット- クラシックなドラムマシンサウンド（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.
