Space Dust MCP

by jwang47

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
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.
Naming Consistency5/5
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.
Tool Count5/5
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.
Completeness4/5
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.
Average 4.1/5 across 10 of 10 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 5 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![Space_Dust_Synthesizer_MCP MCP server](https://glama.ai/mcp/servers/jwang47/Space_Dust_Synthesizer_MCP/badges/card.svg)](https://glama.ai/mcp/servers/jwang47/Space_Dust_Synthesizer_MCP)

Score Badge

Copy to your README.md:

[![Space_Dust_Synthesizer_MCP MCP server](https://glama.ai/mcp/servers/jwang47/Space_Dust_Synthesizer_MCP/badges/score.svg)](https://glama.ai/mcp/servers/jwang47/Space_Dust_Synthesizer_MCP)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/jwang47/Space_Dust_Synthesizer_MCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server