SoundMagic

by JasondeWest

Overview Schema Source 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: capabilities describes the environment, submit creates a job, status checks state, wait blocks for completion, cancel aborts, and release tears down resources. There is no overlap that would cause an agent to misselect.
Naming Consistency4/5
All tools follow the soundmagic_ prefix and use lowercase snake_case, creating a highly predictable pattern. The action words are mostly verbs (submit, wait, cancel, release) but two are nouns (capabilities, status), a minor deviation from a strictly verb-based scheme.
Tool Count5/5
Six tools is well-scoped for a local audio job manager: discovery, submission, monitoring, waiting, cancellation, and resource release. Each tool earns its place and no redundant utilities are present.
Completeness5/5
The tool set covers the full lifecycle of a job: check what is possible, submit work, observe progress, wait for a terminal state, cancel if needed, and release the GPU afterwards. No obvious dead ends or missing operations for the stated domain.
Average 4/5 across 6 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit 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

Behavior3/5
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 does disclose the key asynchronous contract: jobs are queued, an idle worker is woken, and a job ID returns immediately. However, it omits error behavior, idempotency_key semantics, worker-busy behavior, and what subsequent steps (polling, waiting, cancelling) require.
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?
Two tight sentences with zero filler. The primary purpose and the defining async behavior are front-loaded, and every clause adds information. This is appropriately concise for the top-level description of a submit tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a complex nested request schema with seven operation types, and no annotations or output schema. The description does not mention the range of operations (TTS, music, mix, edit, etc.), how audio inputs are referenced, or how the returned job ID relates to sibling tools like wait/status/cancel. An agent would need to infer or inspect deeply before calling correctly.
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 description coverage is 0%, and the description adds no parameter-level meaning. It does not explain that 'request' is a discriminated union keyed on 'operation', nor does it mention the optional 'idempotency_key'. The schema itself is the only source of parameter semantics, and the description does not compensate for the lack of described fields.
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 states a specific verb ('Queue') and resource ('local audio creation/editing'), plus the immediate return behavior ('Returns a job ID immediately'). It clearly distinguishes this tool from siblings like soundmagic_status, soundmagic_wait, and soundmagic_cancel, which are about lifecycle management rather than submission.
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 the use case—submitting asynchronous audio generation/edit jobs—but gives no explicit guidance on when to prefer this over sibling tools, nor any exclusions or alternatives. An agent can infer the basic role, but there is no stated 'use status for polling' or 'use cancel to stop' routing.
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?
Annotations already mark this as read-only; the description adds that it blocks up to 50 seconds and should be repeated for long jobs. It doesn't disclose what happens on timeout or whether it returns a status, leaving some behavioral ambiguity.
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?
Two short sentences with no filler; the core behavior is front-loaded and the repeat guidance is a useful addition.
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 wait tool, the description covers the main flow, but the absence of an output schema and lack of timeout-result behavior leaves an agent uncertain about what the call returns or what happens when the timeout is reached.
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 description coverage is 0%, and the description never mentions job_id or timeout_seconds by name. 'Wait up to 50 seconds' loosely hints at a timeout but doesn't explain the parameter's role or the default of 30.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Wait') and the target condition ('completion, failure or cancellation'), making the tool's purpose clear. It doesn't explicitly differentiate from sibling soundmagic_status, but the blocking wait behavior is evident.
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?
'Repeat for long jobs' gives clear guidance on how to handle long-running jobs. It doesn't mention alternatives like soundmagic_status or when not to use it, so it stops short of a full when/when-not specification.
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 full disclosure burden. It usefully reveals the key side effect: cancelling a running job terminates its GPU worker. This adds meaningful behavioral context beyond the simple 'cancel' label, though it omits details like idempotency or error 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 exceptionally concise: two short sentences, with the core action stated first and the critical side effect second. No wasted words or redundant details.
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 single-parameter cancellation tool, the description is largely complete: it names the target, states the action, and discloses the main consequence. It could add how the job_id is obtained or what happens to a queued job, but these are not critical gaps given the tool's simplicity.
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 description coverage is 0%, and the description never mentions job_id, its format, or how to obtain it. While the schema labels the parameter 'Job Id', the description adds no semantic value beyond what the parameter name already implies.
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 states a specific verb ('Cancel') and resource ('one queued/running job'), making the tool's purpose immediately clear. It distinguishes itself from sibling tools like submit, status, wait, and release by indicating this tool targets existing jobs for cancellation.
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 clearly conveys when to use the tool: when a particular queued or running job needs to be cancelled. It does not explicitly mention exclusions or alternative tools, but the context is clear enough for an agent to select it over the listed siblings.
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. It discloses two concrete effects ('Release GPU memory' and 'stop the scheduler') and a timing guarantee. However, it does not mention whether the call blocks until jobs finish, whether it is idempotent, or what happens if invoked while jobs are still running.
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?
A single, well-structured sentence with no filler. The primary action ('Release GPU memory') is front-loaded, followed by the secondary action and the timing condition. Every word earns its place.
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 parameterless cleanup tool, the description covers the action, the resource affected, and the lifecycle timing. It omits details like blocking behavior, idempotency, and return values, but the low complexity means these are not critical gaps.
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 input schema has zero parameters, so no parameter documentation is needed. The baseline for a parameterless tool is 4, and the description does not need to compensate for missing parameter details.
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 states a specific verb and resource ('Release GPU memory') and a precise condition ('after queued/running jobs finish'). It clearly distinguishes itself from siblings such as soundmagic_cancel by implying a graceful, post-completion shutdown rather than an immediate cancellation.
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?
It provides clear context for when to invoke the tool: after queued/running work completes. It does not explicitly name alternatives or state when not to use it, but the lifecycle timing is evident and sufficient for this zero-parameter cleanup operation.
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?
The readOnlyHint annotation already signals safety, and the description adds beyond that by stating the tool 'does not wake the GPU,' which conveys operational behavior and cost implications. It also specifies what information is returned, though it does not describe the exact output format.
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?
A single, front-loaded sentence states the purpose and the key behavioral trait with no filler. Every part of the description earns its place.
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 zero-parameter, read-only capabilities tool, the description is fully sufficient: it tells the agent what data will be listed and that the call is lightweight. No critical operational detail is missing.
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 has zero parameters and 100% schema description coverage, so there is nothing for the description to add about parameters. The baseline of 4 applies because no parameter information is needed.
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 a specific verb ('List') and names the exact resources it exposes: installed models, validation status, input paths, and complete request schema. This clearly distinguishes the tool from action-oriented siblings like soundmagic_submit and soundmagic_cancel.
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 this is the tool to inspect capabilities before submitting work, especially with the note that it does not wake the GPU. However, it never explicitly says when to prefer this over soundmagic_status or when it should be called, leaving the usage context implicit rather than prescriptive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description reveals an important behavioral detail: it neither wakes the GPU nor extends the warm timeout. This is exactly the kind of non-obvious side-effect disclosure that helps an agent reason about safe invocation.
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?
Two short sentences deliver the core purpose and the most critical behavioral nuance with no filler. The content is front-loaded and every word earns its place.
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, optional-parameter read tool, the description is largely complete: it states what is read and important non-effects. It does not specify return values or the exact meaning of null, but the tool's simplicity and the annotation coverage keep this from being a major gap.
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 description coverage is 0%, and the description does not explain the job_id parameter, including what null means or how it distinguishes job state from worker state. The phrase 'job or worker state' hints at the parameter's role, but this is too ambiguous for a tool with no other parameter documentation.
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 a specific verb ('Read') with a clear resource ('a job or worker state'), which immediately distinguishes it from mutating siblings like submit, cancel, and release. The scope is concrete and unambiguous.
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 useful context for when to use this tool: it is safe to check state without affecting the GPU or warm timeout. It does not explicitly name alternatives or state when not to use it, but the read-only framing and non-effect warning give clear practical guidance.
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

SoundMagic MCP server — quality and maintenance score on Glama

Copy to your README.md:

[![SoundMagic MCP server — quality and maintenance score on Glama](https://glama.ai/mcp/servers/JasondeWest/SoundMagic/badges/card.svg)](https://glama.ai/mcp/servers/JasondeWest/SoundMagic)

Score Badge

Copy to your README.md:

[![SoundMagic MCP server — quality and maintenance score on Glama](https://glama.ai/mcp/servers/JasondeWest/SoundMagic/badges/score.svg)](https://glama.ai/mcp/servers/JasondeWest/SoundMagic)

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/JasondeWest/SoundMagic'

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