Provides audio editing capabilities through FFmpeg, including clip editing, mixing, loudness normalization, tempo/speed changes, and resampling of audio files.
Click on "Install 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., "@SoundMagic Synthesize the sentence 'Hello, welcome to SoundMagic' using the Vivian voice."
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.
Local audio tools for AI agents: speech, voice cloning, music, sound effects and audio editing through MCP. Models load on demand and GPU workers shut down after inactivity. Built and tested on Windows with an 8 GB NVIDIA GPU.
面向 Windows + NVIDIA GPU 的本地声音插件，已在 RTX 4060 Laptop 上验证。大模型通过 MCP 提交规范 JSON 任务；模型按需加载、单卡串行处理，结束后保温，空闲 300 秒自动结束推理进程和调度进程。
当前设备实测：RTX 4060 Laptop，8188 MiB 显存，约 32GB 系统内存。模型与虚拟环境位于本项目，输出保存在 outputs/<job_id>/。推理默认离线，下载和升级单独执行。
flowchart LR
A[你的自然语言要求] --> B[大模型 + 插件技能]
B --> C[MCP / 版本化 JSON]
C --> D[SQLite 持久任务队列]
D --> E[按需启动调度进程]
E --> F[单个 GPU 工作进程]
F --> G[音频 + 参数 + 耗时 + 哈希]
F --> H{空闲 5 分钟?}
H -->|有新任务| F
H -->|是| I[结束进程 释放显存和内存]MCP 接入层随调用方运行，保持轻量，不导入 PyTorch。未收到任务时不启动调度器和 GPU 工作进程；关闭调用方后接入层也退出。纯 CLI 调用完全退出后可以没有任何 SoundMagic 常驻进程。状态查询不延长保温时间。不同大模型客户端共用一条队列，GPU 同时只执行一个任务。
Related MCP server: m4x
能力 | 引擎 | 本机运行方式 |
中文及多语种 TTS | Qwen3-TTS 0.6B CustomVoice | BF16、SDPA、批量 1，速度优先 |
情绪控制与高质量 TTS | Qwen3-TTS 1.7B CustomVoice | 按任务切换，质量优先 |
用参考音色说新文本 | Qwen3-TTS 0.6B / 1.7B Base | 3–30 秒干净参考录音，最好附准确转录 |
根据描述设计新音色 | Qwen3-TTS 1.7B VoiceDesign | 指令描述声音特征 |
音效、短器乐 | TangoFlux | BF16，25 步，最长 30 秒 |
优先音效引擎（需单独授权与安装） | Stable Audio 3 Small SFX | FP16、8 步、分段解码；未安装时使用 TangoFlux |
歌词歌曲生成 | ACE-Step 1.5 Turbo | 批量 1，8 步，CPU/DiT 内存卸载；外部大模型提供描述与歌词 |
人声/伴奏分离 | HTDemucs | GPU，6 秒窗口 |
歌声或说话换音色 | Seed-VC | 两种独立模型配置，歌声保留基频；参考音色无需先训练 |
剪辑、混音、响度、变速、重采样 | FFmpeg | CPU 执行，省去加载大模型 |
选择依据与候选比较见 docs/model-selection.md。available 代表文件与运行环境已配置；validation 才标明实际生成验证状态。以 soundmagic capabilities 和 docs/validation.md 为准。
.\.bridge\Scripts\python.exe -m soundmagic.cli capabilities
.\.bridge\Scripts\python.exe -m soundmagic.cli submit examples\tts.json
.\.bridge\Scripts\python.exe -m soundmagic.cli wait <job_id> --seconds 30
.\.bridge\Scripts\python.exe -m soundmagic.cli status <job_id>
.\.bridge\Scripts\python.exe -m soundmagic.cli cancel <job_id>
.\.bridge\Scripts\python.exe -m soundmagic.cli release提交示例：
{
"schema_version": 1,
"operation": "tts",
"mode": "preset",
"quality": "fast",
"text": "你好，欢迎来到我的声音工作室。",
"language": "Chinese",
"speaker": "Vivian"
}MCP 工具：soundmagic_capabilities、soundmagic_submit、soundmagic_status、soundmagic_wait、soundmagic_cancel、soundmagic_release。任务返回 queued/running/succeeded/failed/cancelled。submit 的成功只表示已入队，需等待 succeeded 才有音频结果。wait 最长 50 秒，可重复调用。
克隆你的声音：把清晰录音放入 inputs/my-voice.wav，调整 examples/clone.json 中录音实际转录。示例所需素材及路径说明见 examples/README.md。歌曲换声由大模型依次调用 separate → convert_voice → mix，用上一步返回的绝对文件路径作为下一步输入。
输入限于 inputs、outputs 或明确配置的文件目录，不接受网络 URL。通过 config.local.json 扩展 input_roots 或调整 idle_timeout_seconds。输出路径由插件分配，原音频不被覆盖。内部请求不开放任意命令执行。
本项目的安装环境：.bridge 为 MCP/维护，.venv 为 Qwen，.envs/audio 为 TangoFlux/Seed-VC/Demucs，.envs/ace 为 ACE-Step，.envs/stable 为 Stable Audio。不同模型的 Transformers 版本冲突通过独立环境解决。
需要 Windows、Git、uv 和网络；脚本使用 Python 3.12，可由 uv 下载。GPU 推理需要兼容 CUDA 12.6 的 NVIDIA 驱动。验证设备为 8 GB 显存、32 GB RAM；完整模型约 40 GiB，另需环境、缓存和输出空间。
首次安装完整环境与无需额外账号授权的模型：
git clone https://github.com/JasondeWest/SoundMagic.git
cd SoundMagic
powershell -File scripts/setup-all.ps1 -DownloadModels
.\.bridge\Scripts\python.exe -m soundmagic.cli capabilities仅体验 MCP、队列及 FFmpeg 编辑，可运行 powershell -File scripts/setup.ps1，暂不下载 GPU 模型。语音最小安装可用 powershell -File scripts/setup.ps1 -TTS，再按下方命令下载 Qwen 模型。已有可用环境无需重复运行安装脚本。
requirements/*.lock.txt 固定五套环境依赖，sources.lock.json 固定四个上游源码提交；CUDA 轮子固定 SHA256。完整安装脚本当前使用清华 PyPI 镜像，部分 PyTorch 轮子使用南京大学镜像。不要把这些环境合并。脚本会保留并拒绝覆盖已修改或版本不同的上游源码；全新机器恢复脚本尚未在第二台设备重跑。
Stable Audio 是可选引擎。需要它时，运行 powershell -File scripts/login-huggingface.ps1，在官方模型页面自行完成账号与条款授权，再运行以下命令。授权与模型文件不会随本仓库分发；登录凭据由 Hugging Face CLI 保存在本项目忽略的缓存目录。
.\.bridge\Scripts\python.exe scripts\install_stable.py sfx --stage-only
.\.bridge\Scripts\python.exe scripts\activate_staged.py stable-sfx下载模型：
.\.bridge\Scripts\python.exe scripts\install_model.py qwen-0.6b-preset
.\.bridge\Scripts\python.exe scripts\install_model.py qwen-0.6b-clone
.\.bridge\Scripts\python.exe scripts\install_audio_models.py ace-step --stage-only
.\.bridge\Scripts\python.exe scripts\activate_staged.py ace-step项目中的插件清单和技能在 plugins/soundmagic。安装脚本会调用 scripts/configure_plugin.py，按当前绝对路径生成插件 .mcp.json 和项目根目录 codex-mcp.toml。这两份机器配置不纳入 Git，移动项目后需重新生成，并更新客户端配置或已安装的插件副本。
Codex 的 MCP 配置片段见生成的 codex-mcp.toml。使用个人插件时，以生成配置后的 plugins/soundmagic 为插件源。通用 MCP 客户端启动 .bridge/Scripts/python.exe -m soundmagic.mcp_server，并设置 SOUNDMAGIC_ROOT 为本项目绝对路径及 PYTHONPATH 为本项目 src 目录。仓库本身不会自动在客户端中安装插件。
模型下载解析并固定上游提交版本。Qwen 下载记录逐文件 SHA256；高级模型固定仓库提交，Demucs 校验官方哈希。--stage-only 先暂存；结束现有任务并执行 release，确认 status 为 stopped，再激活。旧模型文件保留，注册表历史在 models/history，可用 scripts/rollback_models.py <snapshot.json> 恢复。
代码更新在独立目录或版本控制分支完成，先跑测试与短音频实测，再更新插件缓存版本。运行环境依赖由 lock 文件恢复；注册表回滚仅回滚模型选择，不自动回滚 Python 依赖。
断电/崩溃后，下次启动把被中断的 running 任务标为 failed，保留排队任务。重试失败任务应使用新 ID；不确定提交是否成功时用相同 idempotency_key 查询/重提。同一 ID 不能用于不同内容。超时和取消会结束整个工作进程；Windows Job Object 也会在调度器异常退出时清理工作进程及其子进程。
默认单任务超时 30 分钟、队列上限 32。日志在 runtime/daemon.log 与 runtime/worker.log；任务请求记录在本机 SQLite 中，可能包含文本、歌词和参考音频路径。
.\.bridge\Scripts\python.exe -m pytest -q
.\.bridge\Scripts\python.exe scripts\smoke_mcp.py
.\.bridge\Scripts\python.exe scripts\benchmark.py examples\tts.json --warm测试覆盖真实 FFmpeg 输出、进程唤醒、复用、闲置退出、并发排队、幂等提交、失败恢复和路径约束。GPU 实测单独记录，不用单元测试结果冒充模型质量或速度结果。相同随机种子保留生成条件，但不同 CUDA 操作/版本不保证逐字节一致。
SoundMagic 自有代码采用 MIT License。第三方源码、依赖、模型权重和音频素材仍按各自许可使用，详见 THIRD_PARTY_NOTICES.md。本仓库不包含模型、虚拟环境、账号凭据、个人录音、生成音频或任务数据库。
欢迎提交 Issue 和 Pull Request。修改后请运行上述工程测试；涉及模型后端时，附上具体模型版本、设备、参数和实际生成验证结果。报告问题前请去除日志中的私人文本、歌词、音频路径和账号信息。
Cancel one queued/running job. Running cancellation terminates its GPU worker.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes |
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.
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.
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.
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.
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.
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.
List installed models, validation status, input paths and complete request schema; does not wake the GPU.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
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.
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.
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.
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.
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.
Release GPU memory and stop the scheduler after queued/running jobs finish.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
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.
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.
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.
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.
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.
Read a job or worker state. Does not wake the GPU or extend the warm timeout.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | No |
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.
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.
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.
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.
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.
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.
Queue local audio creation/editing and wake an idle worker. Returns a job ID immediately.
| Name | Required | Description | Default |
|---|---|---|---|
| request | Yes | ||
| idempotency_key | No |
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.
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.
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.
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.
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.
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.
Wait up to 50 seconds for completion, failure or cancellation. Repeat for long jobs.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | ||
| timeout_seconds | No |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0soundmagic_cancelsoundmagic_capabilitiessoundmagic_releasesoundmagic_statussoundmagic_submitsoundmagic_waitEach 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.
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.
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.
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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
OCR, transcription, file extraction, and image generation for AI agents via MCP.
AI image, video, voice and music generation over MCP, routed to Veo 3.1, Seedance 2.0 and more.
Generate game-ready 3D models, textures, and audio from natural language, over MCP.
The Listenetic MCP server is a remote, cloud-hosted server that enables AI assistants like ChatGPT and Claude to convert articles, documents, websites, and videos into high-quality AI-generated audio. It provides multi-format support for text and binary files, natural-sounding text-to-audio conversion using AI, and specialized processing for SSML, markup, markdown, and various media formats through three core tools: listentic_supported_mimetypes, listentic_add_content_text, and listentic_add_content_binary.
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
