The Space Dust MCP server lets you explore, create, modify, and manage Space Dust synthesizer presets entirely through natural language — translating musician descriptions like "darker," "punchier," or "more bite" into precise parameter changes without touching the plugin's knobs or XML files.
List Presets: Browse all presets in your Space Dust preset folder.
Read a Preset: Inspect a preset's settings grouped by section, showing only what differs from defaults (or all parameters if requested).
Read Current Sound: See what the plugin is playing right now, so you can say "this sound" or "what I'm hearing" without naming a preset.
Adjust Current Sound: Change the live sound with immediate effect — the plugin picks up changes within a second.
Create a Preset: Generate a new preset from scratch (Init) or based on an existing one; refuses to overwrite existing presets.
Adjust a Preset: Modify a saved preset in place, with an automatic undo snapshot taken before every change and an optional note describing what was requested.
Undo: Restore a preset to its state before the last change.
Preset History: View up to 30 previously saved versions of a preset.
Compare Presets: See every parameter that differs between two presets side by side.
List Parameters: Search and browse all synth parameters, their ranges, and defaults by section or name.
Control a Space Dust synth plugin by shaping presets through natural language — listing presets, reading and adjusting the current sound, creating and modifying presets, undoing changes, and comparing presets, with all edits written to the plugin's preset folder.
Click on "Deploy 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., "@Space Dust MCP make the current sound warmer and punchier"
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.
Lets someone shape Space Dust presets by describing the sound they want, instead of by turning knobs or editing files. They say "make the bass darker and give it more bite"; Claude reads the preset, changes the right parameters, and tells them what it did.
Space Dust is a subtractive synthesiser plugin (VST3 / AU / standalone, built with JUCE). This is a companion, not part of the plugin — install the synth first.
Works with the Space Dust you already have installed. Presets are plain XML files, so nothing here needs the plugin's source code or a rebuild.
Requires Space Dust and uv.
git clone https://github.com/jwang47/Space_Dust_Synthesizer_MCP.git
uv tool install ./Space_Dust_Synthesizer_MCPThen add it to Claude Code:
claude mcp add space-dust -- spacedust-mcpFor the Claude desktop app, add it under Settings → Developer → Edit Config:
{
"mcpServers": {
"space-dust": { "command": "spacedust-mcp" }
}
}Restart Claude afterwards. Nothing leaves the machine — the server only reads and writes files in the user's own preset folder.
Related MCP server: MCP Synth Controller
"What have I got in Space Dust?" — lists their presets
"What's going on in Dub Mew Bass?" — reads a preset back in plain language
"Make me a bass like that one but darker and punchier" — creates a new preset
"Too muddy, back off the low end" — adjusts what they're currently playing
"Actually, undo that" — restores the previous version
"What's different between these two?" — compares presets
Changes to the preset the plugin currently has loaded are picked up on their own within a second, so the user can keep playing while iterating. A newly created preset still has to be selected once from the preset menu.
Live adjustment needs a plugin build that includes PresetHotReload — it publishes the
current sound to current.sdpreset in the plugin's app-data folder and watches the loaded
preset for external edits. That folder is ~/Library/Application Support/Space Dust on
macOS and %APPDATA%\Space Dust on Windows, matching PresetManager::appDataFolder().
Against older builds every other tool still works; the user just re-selects the preset to
hear a change.
Tool | Purpose |
| What the plugin is playing right now, no preset name needed |
| Change that sound; the plugin applies it within a second |
| Presets in the user's preset folder |
| A preset's settings, grouped by section, defaults omitted |
| Search parameters, their ranges and defaults |
| New preset from Init or from an existing one |
| Change an existing preset in place, saving an undo point |
| Restore the version before the last change |
| List saved earlier versions |
| Every setting that differs between two presets |
The server's instructions teach Claude the synth's signal flow and how to translate musician language ("wobblier", "more space", "punchier") into parameter moves, so the user never has to learn a parameter name.
These exist because the model, not the user, is choosing the values:
Unknown parameter ids are rejected with close matches, never silently ignored.
Out-of-range numbers are clamped to the plugin's real range and reported.
Switch and menu parameters only accept their actual values (on/off, Low Pass).
Preset names can't contain path separators, so writes stay in the preset folder.
create_preset refuses to overwrite an existing preset.
Every adjust_preset snapshots the previous version first — up to 30 per preset, in
~/Library/Application Support/Space Dust/history/.
Presets are always written with all 206 parameters. APVTS::replaceState leaves
omitted parameters at their current value, so a partial preset would inherit whatever
the plugin happened to have loaded.
Parameter ranges, defaults and choice names live in data/schema.json, generated by
parsing createParameterLayout() in the
plugin source.
Regenerate it whenever the plugin's parameter list changes:
uv run python -m spacedust_mcp.source_parser /path/to/Source/PluginProcessor.cppThe default path assumes the two repos sit side by side; SPACE_DUST_SOURCE overrides it.
End users never run this — they get the generated file in the package. Longer term the plugin should export this itself at build time, so the two can't drift.
uv run pytestChange the sound the user is playing right now, and hear it within a second.
Use this for "make this darker", "less muddy", "more bite" — anything about the sound in front of them rather than a preset by name. Writes to the preset Space Dust currently has loaded; the plugin picks the change up on its own, so the user doesn't have to touch the preset menu.
Needs a preset to be selected in the plugin. If they're on an unsaved sound, ask them to save it as a preset first.
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | ||
| changes | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It discloses that the tool writes to the currently loaded preset ('Space Dust'), that the plugin picks up changes automatically, and that it requires a preset to be selected. This covers the key behavioral traits, though it doesn't mention error cases or undo behavior.
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 concise and front-loaded: it states the core action first, gives quick examples, then mentions the side-effect and prerequisite. Every sentence earns its place, with no filler.
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?
It covers use-case, side-effect, immediacy, and prerequisite. An output schema exists, so return values are delegated. The only notable omission is parameter structure, already penalized separately, making the overall context fairly complete.
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 coverage is 0% and the description never explains the structure of the `changes` object. The examples ('make this darker') imply intent, but an agent cannot determine what keys or values to put in the `changes` map, leaving a critical gap for correct invocation.
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 opens with a specific verb and resource: 'Change the sound the user is playing right now.' It clearly distinguishes this from adjusting a preset by name via examples like 'rather than a preset by name,' which differentiates it from sibling adjust_preset.
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?
It explicitly tells when to use this tool: for sonic descriptions like 'make this darker' or 'more bite' rather than preset names. It also states the prerequisite that a preset must be selected and instructs asking the user to save unsaved sounds first, providing clear context and exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Change settings in an existing preset, in place.
changes maps parameter ids to values written the way the plugin shows them —
{"filterCutoff": "180", "softClipperDrive": "0.6"}.
The previous version is saved first, so undo_preset can always take it back. Use
note to record what the user asked for ("darker, more low end").
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | ||
| preset | Yes | ||
| changes | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well. It discloses that changes are written 'in place', that 'the previous version is saved first' to enable undo, and that the 'note' field records user intent. This goes beyond a simple mutation statement.
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 concise and front-loaded, with a clear first sentence followed by two supporting details. Every sentence adds value without redundancy, making it easy to scan.
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?
The description covers purpose, mutation behavior, undo safety, and parameter semantics for the key fields. Output schema exists, so return values don't need elaboration. Minor omissions like error conditions or prerequisites are acceptable given the overall quality.
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. It thoroughly explains the 'changes' parameter with a concrete example and the format 'the way the plugin shows them'. It also explains the 'note' parameter. The 'preset' parameter is left implicit but is self-explanatory from context.
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 opens with 'Change settings in an existing preset, in place,' which clearly specifies the verb (change), resource (preset), and scope (existing, in place). This distinguishes it from siblings like create_preset (new preset) and adjust_current_sound (current sound).
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 establishes clear context: it modifies an existing preset and even references undo_preset for reverting. However, it does not explicitly contrast with alternatives like adjust_current_sound, so usage guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show every setting that differs between two presets.
| Name | Required | Description | Default |
|---|---|---|---|
| first | Yes | ||
| second | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. 'Show' implies a read-only action, but it does not explicitly state that it makes no changes, nor does it describe return format, ordering, or any limitations. The description is not misleading but adds minimal behavioral context.
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 a single, front-loaded sentence with no wasted words. It efficiently conveys the tool's core purpose.
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?
An output schema exists, so the description need not explain return values. The tool's function is simple, and the description captures it well. However, without more detail on parameters or usage, it is not fully complete, but given the output schema and simple nature, it is adequate.
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. It clarifies that the two parameters are 'presets', adding semantic meaning beyond the bare string names 'first' and 'second'. However, it does not specify whether these are preset IDs, names, or how they are selected, leaving room for ambiguity.
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 'Show every setting that differs between two presets' uses a specific verb ('show') and resource ('every setting that differs between two presets'). It clearly distinguishes from sibling tools like list_presets (lists all presets), read_preset (reads one preset), and adjust_preset (modifies).
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 implies usage when comparing two presets, but does not explicitly state when to use it vs. alternatives, nor does it mention exclusions or prerequisites. It relies on the tool name and context to convey its niche.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new preset and save it to the user's preset folder.
changes maps parameter ids to values written the way the plugin shows them —
{"filterCutoff": "260", "osc1Waveform": "Saw", "subOscOn": "on"}.
based_on is the preset to start from; "Init" starts from the synth's default state.
Starting from an existing preset the user likes is usually the better move.
Refuses to overwrite an existing preset — pick another name, or use adjust_preset.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| note | No | ||
| changes | Yes | ||
| based_on | No | Init |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it reveals the save location, the changes mapping format with an example, the based_on default and semantics, and the overwrite refusal. It does not cover potential errors for invalid parameter values or permissions, but the core behavioral traits are transparent.
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 front-loaded with the main purpose and each paragraph adds necessary detail—the changes example, based_on guidance, and overwrite warning. No filler or redundancy.
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 tool with 4 parameters, nested objects, and no annotations, the description is remarkably complete. It explains the two complex parameters, the failure mode, and the alternative action. An output schema exists, so return values need not be described.
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?
Despite schema coverage being 0%, the description adds substantial meaning for 'changes' (format and example) and 'based_on' (default and guidance). 'name' and 'note' are left to the schema, but they are simple and self-explanatory.
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 'Create a new preset and save it to the user's preset folder,' specifying a concrete verb and resource. It distinguishes itself from sibling tools by explicitly noting it refuses to overwrite and pointing to adjust_preset as the alternative for that action.
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 gives explicit when-to-use guidance: 'Starting from an existing preset the user likes is usually the better move.' It also provides a clear when-not-to-use and an alternative: 'Refuses to overwrite an existing preset — pick another name, or use adjust_preset.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up Space Dust parameters, their ranges and defaults.
Pass a word to filter — a section name like "filter" or "reverb", or part of a parameter name. With no query this returns every parameter, grouped by section.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It reveals the default behavior (returns all parameters grouped by section) and the filtering mechanism, which is important for an agent. It doesn't mention edge cases like empty results, but for a read-only lookup tool this is sufficient.
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 two sentences, front-loaded with the core purpose and followed by usage details. Every sentence earns its place with no wasted words. It is highly scannable and informative.
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 simple listing tool with one optional query parameter, the description provides essential context: the tool returns parameters, ranges, defaults, and groups results by section. Since an output schema exists, the lack of detailed return format explanation is acceptable, and the description is complete for the tool's complexity.
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 single parameter 'query' has zero schema description coverage, but the description fully compensates by explaining that it filters by section name or parameter name and provides examples. This goes beyond the schema, which only states the type and default, giving agents a clear understanding of what to pass.
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 "looks up" Space Dust parameters, including ranges and defaults. This specific verb+resource phrasing distinguishes it from sibling tools like list_presets and read_current_sound, which handle different concepts (presets and current sound).
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 guidance on how to filter with a word (e.g., section name or parameter name) and explains the default behavior when no query is given. It implies the tool is for parameter lookups but does not explicitly contrast it with alternatives, making it just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the presets installed in the user's Space Dust preset folder.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. However, it only says 'List' which implies a read-only operation but does not mention return format, potential errors, sorting, or any side effects. This is a minimal disclosure that leaves the agent without important context.
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 a single, concise sentence that front-loads the action and resource. Every word earns its place, with no unnecessary elaboration.
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?
The tool is simple with no parameters and an output schema exists, which reduces the need for the description to explain return values. However, given the sibling tools, adding a hint about how this differs from preset_history or compare_presets would enhance 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?
The tool accepts zero parameters, so the schema provides full coverage. The baseline for 0 params is 4, and there is nothing the description needs to add about parameter meanings.
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 action ('List') and the resource ('presets installed in the user's Space Dust preset folder'). It effectively distinguishes itself from sibling tools like read_preset (which targets a specific preset) and list_parameters (which likely lists parameters rather than presets).
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 is no mention of scenarios where listing presets is appropriate, nor any exclusions or references to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the saved earlier versions of a preset, newest last.
| Name | Required | Description | Default |
|---|---|---|---|
| preset | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description must disclose behavior. It mentions the ordering ('newest last') and implies a read-only operation. However, it does not clarify whether the current version is included, what fields are returned, or any access requirements. The addition is minimal but not misleading.
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 a single concise sentence that is front-loaded with the main action and resource. There is no redundancy or irrelevant information, making it efficient and easy to parse.
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 simple tool with one parameter and an output schema, the description covers the core purpose. However, it lacks essential parameter semantics and usage context. The output schema may handle return values, but the 'preset' parameter remains underspecified, leaving a gap in 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?
The single parameter 'preset' has zero schema description coverage, and the description does not explain what format the value should take (e.g., ID, name) or how to obtain valid presets. The description mentions 'a preset' but offers no additional semantic detail beyond the parameter name itself.
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 action (List), the resource (saved earlier versions of a preset), and an ordering detail (newest last). It distinguishes this tool from siblings like list_presets (lists all presets) and read_preset (reads a specific preset) by focusing on version history.
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 or any exclusions. It only states what the tool does, leaving the agent to infer that it's for viewing version history, but no explicit context or alternative comparisons are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show what Space Dust is playing right now, without the user naming a preset.
Use this whenever they say "this sound", "what I'm hearing", "the current patch".
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The description clearly states it is a read operation ('Show'). It does not disclose any edge cases (e.g., what happens when nothing is playing) or side effects, but for a simple read-only tool with zero parameters, this is adequate.
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 two sentences, front-loaded with the primary purpose and followed by concrete usage examples. Every word earns its place, and there is no filler.
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 simple read-only tool with no parameters and an output schema present, the description fully covers what the agent needs: what it does, when to use it, and how it differs from similar tools. No gaps are apparent.
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?
There are zero parameters, so the baseline is 4. The description does not need to explain parameters, and the schema has no properties to cover. The description adds no parameter semantics, but it is not required.
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 uses the specific verb 'Show' and clearly identifies the resource as the currently playing sound in Space Dust. It explicitly distinguishes itself from named-preset operations by saying 'without the user naming a preset,' which differentiates it from sibling tools like read_preset.
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 trigger phrases ('this sound', 'what I'm hearing', 'the current patch') and states 'Use this whenever they say...' This gives clear when-to-use guidance. However, it does not explicitly name an alternative for when a preset is named, so it's slightly less complete than an explicit recommendation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show how a preset is set up, grouped by section.
Only settings that differ from the synth's defaults are listed, which is what makes
the sound what it is. Set include_defaults to see every parameter.
| Name | Required | Description | Default |
|---|---|---|---|
| preset | Yes | ||
| include_defaults | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It clearly discloses that by default only non-default settings are shown, and instructs how to include all parameters via include_defaults. This transparently sets expectations about the output's scope. The read-only nature is implicit in 'Show,' but no explicit side-effect or error behavior is mentioned.
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 three sentences, with no filler. The first sentence gives the purpose, the second explains the default behavior, and the third gives parameter guidance. It is front-loaded with the primary action and resource, making it easy for an AI agent to quickly grasp the tool's core function.
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 simple read-only tool with an output schema, the description covers the essential aspects: what it does, how the output is filtered, and how to override that. It does not mention edge cases like missing presets or explicitly compare with read_current_sound, but the core functionality is well-defined for the complexity level.
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. It explains include_defaults thoroughly ('Set include_defaults to see every parameter'), adding meaning beyond the boolean's default. The preset parameter is obvious from context (the tool is read_preset), though the description does not specify the expected format or source; still, combined with the first sentence, it is sufficient.
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 starts with 'Show how a preset is set up, grouped by section,' which clearly states the action (show/read) and resource (a specific preset) with a distinct formatting detail (grouping by section). This differentiates it from sibling tools like list_presets (which lists presets, not details) and read_current_sound (which shows current sound, not a preset).
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 implies usage when you need to understand a preset's unique configuration: 'Only settings that differ from the synth's defaults are listed, which is what makes the sound what it is.' It provides clear context but does not explicitly mention when not to use it or name alternative tools, though that is reasonably inferred from the siblings list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Take a preset back to how it was before the last change.
| Name | Required | Description | Default |
|---|---|---|---|
| preset | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the intended effect but does not disclose behavioral traits such as whether the undo is permanent, whether it affects only the specified preset, what happens if there is no previous state, or whether it creates a history entry. These gaps are significant for a mutation 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 a single concise sentence, front-loaded with the action and no filler. It earns its place, though it could be expanded with key behavioral details without becoming overly long.
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?
The tool is simple (one parameter) and an output schema exists, so the description need not detail return values. However, the description lacks context about what 'last change' means, whether the undo is scoped to the passed preset, and what happens if undo is not possible. For a simple tool this is borderline adequate but leaves notable gaps.
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 one required parameter, 'preset', with no description. The tool description only repeats the word 'preset' without explaining the expected format (e.g., preset name, ID, or path) or how it relates to the undo operation. Since schema coverage is 0% and the description does not compensate, parameter semantics are underspecified.
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 action ('take a preset back') and the resource ('preset'), with the specific scope of reverting to the state before the last change. This distinguishes it from siblings like adjust_preset (which changes a preset) and preset_history (which views history).
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 gives no explicit guidance on when to use this tool versus alternatives such as adjust_preset or preset_history. It implies a use case (undoing a change) but does not state prerequisites, limitations, or scenarios where another tool would be more appropriate.
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.
v0.1.0adjust_current_soundadjust_presetcompare_presetscreate_presetlist_parameterslist_presetspreset_historyread_current_soundread_presetundo_presetScored across 10 tools
Each tool has a clearly distinct purpose: listing vs reading presets, adjusting named presets vs the current sound, and separate tools for undo, history, and comparison. The descriptions explicitly disambiguate potentially similar pairs like adjust_preset and adjust_current_sound.
All tool names follow a consistent verb_noun snake_case pattern (e.g., list_presets, read_preset, adjust_current_sound). Verbs are semantically appropriate (list, read, create, adjust, undo, compare), and no mixed naming conventions are present.
At 10 tools, the set is well-scoped for a synth preset management server. Each tool covers a distinct capability without redundancy, and the count feels neither sparse nor bloated.
The core lifecycle of preset management is covered: list, read, create, adjust, undo, history, and compare. However, a delete operation is missing, and saving the current sound as a new preset would require a workaround, leaving minor gaps.
GibsonAI MCP server: manage your databases with natural language
Turn PRDs and product ideas into structured specs so coding agents build your intent, not theirs.
A personal RAG database you build from chat, so AI creates work that sounds like you.
Generate game-ready 3D models, textures, and audio from natural language, over MCP.
