StemSplit is an AI-powered server for separating audio into stems, removing background noise from voice recordings, and managing jobs — powered by HTDemucs + DeepFilterNet — usable via MCP-compatible clients (Claude Desktop, Cursor, Cline, etc.) or programmatic calls.
Stem Separation
Separate local audio files (MP3, WAV, FLAC, M4A, OGG, AAC) or direct URLs into up to 6 stems: vocals, instrumental, drums, bass, piano, guitar, and other
Extract vocals and instrumental from YouTube videos (up to 60 min) or public SoundCloud tracks (up to 15 min)
Configure output type (VOCALS, INSTRUMENTAL, BOTH, FOUR_STEMS, SIX_STEMS), quality (FAST, BALANCED, BEST), and format (MP3, WAV, FLAC)
Optionally denoise extracted vocals in the same job (denoiseVocals: true)
Create karaoke versions (instrumentals) or acapellas (vocals)
Voice Cleaning & Noise Removal
Remove background noise (hum, hiss, HVAC, wind, echo, ambient sound) using DeepFilterNet
Ideal for cleaning podcasts, interviews, voiceovers, and dialogue before transcription or video production
Job Management
Submit jobs and optionally wait for completion, downloading outputs locally
Check status and retrieve details for stem, YouTube, SoundCloud, or denoise jobs
List recent jobs of any type
Re-download stems from completed jobs with refreshed presigned URLs
Check remaining API credit balance (in seconds, minutes, and human-readable form)
Integration & Automation
Use natural language prompts or programmatic tool calls in agentic workflows
Supports batch processing for transcription pre-processing, AI training data generation, remixing, and mastering
Provides integration with Cloudflare R2 for storage and retrieval of audio stems via presigned URLs.
Allows processing SoundCloud track URLs to extract vocal and instrumental stems.
Allows processing YouTube video URLs to extract vocal and instrumental stems.
AI stem separation and voice cleaning as a Model Context Protocol (MCP) server. Remove vocals, build karaoke tracks, isolate dialogue, split any song into vocals, drums, bass, piano, guitar, and other stems — or remove background noise from voice recordings using DeepFilterNet — directly from Claude Desktop, Cursor, Cline, Windsurf, Zed, or any other MCP-compatible client. Works with local audio files (MP3, WAV, FLAC, M4A, OGG, AAC) and YouTube/SoundCloud URLs.
Powered by the StemSplit API (HTDemucs for stem separation, DeepFilterNet for noise removal). The server exchanges only file paths and JSON over MCP — audio bytes never pass through the LLM context. They flow directly between your machine, StemSplit's API, and Cloudflare R2.
Audio separation basics
Remove vocals from a song — separate any MP3, WAV, or FLAC into vocals and instrumental
Build a karaoke version of any track — /karaoke slash command returns just the instrumental
Extract an acapella — pull a clean vocal track for remixes, mashups, or re-arrangement
Extract drums, bass, piano, or guitar — split audio into up to six individual stems
Process YouTube videos — paste a youtube.com or youtu.be URL and get separated stems back
Audio production & post-production
Clean vocals before processing — isolate vocals first, then pass to a de-esser, noise reducer, or pitch corrector without mix bleed affecting the result
Stem delivery for mastering — auto-generate per-stem exports from a final mix for a mastering engineer
Adaptive game audio — split a track so a game engine can fade individual layers (e.g. mute drums during quiet scenes)
DJ acapella/instrumental packs — batch-generate acapellas and instrumentals for live performance or DJ sets
Sample chopping — extract drums or bass for sample packs in hip-hop / electronic production
Voice cleaning & noise removal
Clean up a podcast or interview — remove hum, hiss, HVAC noise, or ambient room sound from any voice recording
Denoise vocals after stem separation — pass denoiseVocals: true to separate_stems and get a noise-free vocals stem in one shot
Clean dialogue for video production — strip wind, echo, or background noise before syncing to picture
Pre-process audio before transcription — clean first for dramatically higher ASR / Whisper accuracy
AI & developer pipelines
Vocals → transcription — isolate vocals first, then feed to Whisper or any ASR model for significantly cleaner speech-to-text
Lyrics generation — vocals → transcription → synced lyrics file, fully automated in a single MCP chain
Training data for AI music models — generate clean separated stems from raw mixed tracks for fine-tuning or dataset building
Content-ID / copyright checking — extract vocals to fingerprint and match against a vocal database
Per-stem audio visualizers — drive instrument-reactive visualizers in video or web apps by separating stems first
Content & media
Podcast / interview cleanup — strip music beds or background music from recorded dialogue
Sync licensing — instantly generate an instrumental version of a submitted track for a music supervisor
Music education apps — isolate individual instruments to build solo/mute practice tools or ear training exercises
Agentic workflows
Build audio agents in your IDE — orchestrate stem separation from Cursor or Claude Desktop using natural language
Batch process audio in MCP-driven pipelines — chain stem separation with transcription, translation, or any other MCP tool
Related MCP server: Claud-Ear
stemsplit-mcp runs as a local stdio MCP server, so it works in any client that supports the standard MCP transport:
Claude Desktop (Anthropic)
Cline (VS Code extension)
Windsurf (Codeium)
Any client following the Model Context Protocol specification
Stem separation
Tool | Use case |
| Upload a local audio file or pass a direct audio URL; get back local file paths to the separated stems |
| Submit a YouTube URL; get back local file paths to the vocals and instrumental stems |
| Submit a SoundCloud track URL; get back local file paths to the vocals and instrumental stems |
| Inspect existing stem jobs |
| Inspect existing YouTube jobs |
| Inspect existing SoundCloud jobs |
| Re-download outputs from a completed job (re-mints fresh 1-hour presigned URLs) |
Voice Cleaner (noise removal)
Tool | Use case |
| Submit an audio file or URL for noise removal; polls until complete and downloads the cleaned audio to disk |
| Check status or retrieve the download URL for a voice cleaner job |
| Browse voice cleaner job history or filter by status |
Account
Tool | Use case |
| Check remaining StemSplit credits |
Plus six ready-made prompts (slash commands): karaoke, isolate_dialogue, sampler_pack, youtube_instrumental, soundcloud_instrumental, clean_voice.
Add to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):
{
"mcpServers": {
"stemsplit": {
"command": "npx",
"args": ["-y", "stemsplit-mcp"],
"env": {
"STEMSPLIT_API_KEY": "sk_live_your_key_here"
}
}
}
}Restart Claude Desktop. Type /karaoke or just ask: "Separate the vocals from ~/Music/demo.mp3".
Add to ~/.cursor/mcp.json (or per-workspace <workspace>/.cursor/mcp.json):
{
"mcpServers": {
"stemsplit": {
"command": "npx",
"args": ["-y", "stemsplit-mcp"],
"env": {
"STEMSPLIT_API_KEY": "sk_live_your_key_here"
}
}
}
}Any MCP client that supports stdio-launched servers works. Use the same npx -y stemsplit-mcp command and pass STEMSPLIT_API_KEY via the client's env mechanism.
Sign up at stemsplit.io
Generate a key (format: sk_live_...)
Paste it into your MCP client config as shown above
Env var | Required | Default | Description |
| Yes | — | API key, must start with |
| No |
| Override for self-hosted or staging |
| No |
| Base directory where stems are saved. Each job gets a |
separate_stemsSubmit an audio file or direct URL for stem separation.
{
"source": "/Users/me/Music/song.mp3",
"outputType": "BOTH",
"quality": "BEST",
"outputFormat": "MP3",
"wait": true
}Field | Type | Default | Notes |
| string (required) | — | Local path (absolute or |
|
|
|
|
|
|
| |
|
|
| |
| boolean |
| Run the extracted vocals stem through Voice Cleaner (DeepFilterNet) after separation |
| string | derived | Display name for the job |
| boolean |
| If true, poll until done and download stems to disk |
| integer |
| Max wait when |
| integer |
| |
| string |
| Where to write stems |
Returns (wait=true):
{
"jobId": "job_abc123",
"status": "COMPLETED",
"creditsCharged": 180,
"outputDir": "/Users/me/Downloads/stemsplit/job_abc123",
"stems": {
"vocals": "/Users/me/Downloads/stemsplit/job_abc123/vocals.mp3",
"instrumental": "/Users/me/Downloads/stemsplit/job_abc123/instrumental.mp3"
}
}separate_youtubeSame shape, but takes youtubeUrl instead of source. Output is fixed to vocals + instrumental, MP3, BEST quality (this is the StemSplit API's contract for YouTube jobs).
clean_voiceSubmit an audio file or direct URL for noise removal using DeepFilterNet. Removes background hum, hiss, HVAC noise, wind, echo, and other ambient sounds. By default (wait=true), polls until complete and downloads the cleaned audio to disk.
{
"source": "/Users/me/recordings/podcast-ep12.mp3",
"outputFormat": "MP3",
"wait": true
}Field | Type | Default | Notes |
| string (required) | — | Local path (absolute or |
|
|
| |
| string | derived | Display name for the job |
| boolean |
| If true, poll until done and download the cleaned file to disk |
| integer |
| Max wait when |
| integer |
| |
| string |
| Where to write the cleaned file |
Returns (wait=true):
{
"jobId": "dnz_abc123",
"status": "COMPLETED",
"creditsCharged": 180,
"outputDir": "/Users/me/Downloads/stemsplit/dnz_abc123",
"cleanedAudioPath": "/Users/me/Downloads/stemsplit/dnz_abc123/podcast-ep12_denoised.mp3"
}get_job, list_jobs, get_youtube_job, list_youtube_jobs, get_denoise_job, list_denoise_jobs, get_balance, download_stemsThin wrappers over the corresponding StemSplit /api/v1 endpoints. download_stems re-fetches the job first to mint fresh 1-hour presigned URLs, so the expiry never matters. get_denoise_job returns outputs.audio.url when the job is COMPLETED.
Read-only context the LLM can pull on demand.
URI | Returns |
| Live credit balance |
| The 20 most recent stem jobs |
| Detail snapshot with fresh download URLs |
| YouTube job detail with fresh URLs |
| SoundCloud job detail with fresh URLs |
Prompt | Argument | Behavior |
|
| Run |
|
| Run |
|
| Run |
|
| Run |
|
| Run |
|
| Run |
Karaoke from a local file (Claude Desktop):
Make a karaoke version of
~/Music/demo.mp3.
Claude calls separate_stems with outputType="BOTH", polls for ~60s, and returns:
Done. Karaoke (instrumental) is at:
/Users/me/Downloads/stemsplit/job_abc123/instrumental.mp3Six-stem sampler pack (Cursor):
Split
./loops/break.wavinto all six stems for sampling.
Cursor calls separate_stems with outputType="SIX_STEMS", quality="BEST", outputDir="./loops/break-stems", and reports each file path so you can drop them into your DAW.
Instrumental from YouTube:
Get me the instrumental of
https://youtu.be/dQw4w9WgXcQ.
Claude calls separate_youtube, polls until COMPLETED, downloads vocals.mp3 and instrumental.mp3 to ~/Downloads/stemsplit/<jobId>/, and returns the instrumental path.
Clean vocals for transcription (Claude Desktop):
Transcribe the lyrics from
~/Music/interview-with-music.mp3— there's a music bed underneath, clean it up first.
Claude calls separate_stems with outputType="VOCALS" to strip the music bed, then passes vocals.mp3 to a transcription tool (e.g. Whisper via another MCP server). The result is a clean transcript with none of the background music interfering.
Batch acapella extraction (Cursor agent):
Extract acapellas from every MP3 in
./tracks/and save them to./acapellas/.
Cursor iterates the directory, calls separate_stems with outputType="VOCALS" and a custom outputDir per file, and returns a list of acapella paths ready for a remix session or AI training dataset.
Vocal isolation → stems for remix (Claude Desktop):
I want to remix
~/Music/original.wav. Give me the acapella and all the individual instrument stems separately.
Claude calls separate_stems twice — once with outputType="VOCALS" for the clean acapella, once with outputType="SIX_STEMS" for the full stem pack — and hands back all seven file paths organized by stem type.
Clean up a noisy podcast recording (Claude Desktop):
My recording at
~/Desktop/episode-23.mp3has a lot of HVAC noise. Can you clean it up?
Claude calls clean_voice with source="~/Desktop/episode-23.mp3", polls for ~10–20s, and returns:
Done. Cleaned audio saved to:
/Users/me/Downloads/stemsplit/dnz_abc123/episode-23_denoised.mp3Separate stems and denoise vocals in one call (Cursor):
Extract the vocals from
./stems/song.wavand clean them up for use in a transcription pipeline.
Cursor calls separate_stems with outputType="VOCALS" and denoiseVocals=true. StemSplit runs Demucs to extract the vocals, then immediately passes them through DeepFilterNet — delivering a single noise-free vocals file in one job.
Use clean_voice (or the /clean_voice slash command) to remove background noise from any audio file using StemSplit Voice Cleaner, powered by DeepFilterNet.
{
"source": "/Users/me/recordings/episode.mp3",
"outputFormat": "MP3"
}What it removes: background hum, HVAC/air conditioning noise, hiss, wind, echo, ambient room sound, and other non-speech noise. Ideal for podcasts, voiceovers, interview recordings, and dialogue.
Limits
Maximum duration: 60 minutes
Output: a single cleaned audio file (same duration as input)
Credits: 1 credit = 1 second of audio
Example (Claude Desktop)
Clean up the background noise in
~/Recordings/interview.wav.
Claude calls clean_voice, polls until COMPLETED (~10–30s depending on length), and returns:
Done. Cleaned audio saved to ~/Downloads/stemsplit/<jobId>/interview_denoised.wavUse separate_youtube (or the /youtube_instrumental slash command) to extract vocals and an instrumental from any YouTube video.
{
"youtubeUrl": "https://www.youtube.com/watch?v=dQw4w9WgXcQ"
}Accepted URL formats
Format | Example |
Standard watch URL |
|
Short URL |
|
Embed URL |
|
Mobile URL |
|
Bare video ID |
|
Limits
Maximum duration: 60 minutes
Output: vocals + instrumental, MP3, BEST quality (fixed)
Credits: 1 credit = 1 second of video
Example (Claude Desktop)
Get me the instrumental of
https://youtu.be/dQw4w9WgXcQ.
Claude calls separate_youtube, polls until COMPLETED (~60s for a 3-minute video), and returns:
Done. Files saved to ~/Downloads/stemsplit/<jobId>/
vocals.mp3
instrumental.mp3Use separate_soundcloud (or the /soundcloud_instrumental slash command) to extract vocals and an instrumental from any public SoundCloud track.
{
"soundcloudUrl": "https://soundcloud.com/artist/track-name"
}Accepted URL formats
Format | Example |
Standard track URL |
|
Mobile URL |
|
Short URL |
|
Limits
Maximum duration: 15 minutes
Must be a public track (private tracks and sets/playlists are not supported)
Output: vocals + instrumental, MP3, BEST quality (fixed)
Credits: 1 credit = 1 second of audio. When track duration is unknown at submission, 4 minutes (240 credits) is held and reconciled on completion.
Example (Claude Desktop)
Remove the vocals from
https://soundcloud.com/artist/my-track.
Claude calls separate_soundcloud, polls until COMPLETED, and returns:
Done. Files saved to ~/Downloads/stemsplit/<jobId>/
vocals.mp3
instrumental.mp3Example (Cursor agent)
Extract the acapella from every SoundCloud URL in
./tracks.txtand save each to./acapellas/.
Cursor reads the file, iterates the URLs, calls separate_soundcloud with outputDir set per track, and returns a list of all saved acapella paths.
Local files: mp3, wav, flac, m4a, ogg, webm, aac, wma
Direct URLs: any public https:// URL serving one of the formats above (the StemSplit API fetches it server-side)
YouTube: youtube.com/watch?v=..., youtu.be/..., youtube-nocookie.com/embed/..., or a bare 11-character video ID
SoundCloud: soundcloud.com/artist/track, m.soundcloud.com/artist/track, or on.soundcloud.com/shortcode (public tracks only, max 15 minutes)
Limits: 100 MB / 60 minutes per file. 1 credit = 1 second of audio. Credits are deducted at job submission.
Symptom | Fix |
| Set the env var in your MCP client config |
| Key must start with |
| The error includes a |
| Default per-key limit is 60 requests/minute. The error includes |
| Trim or compress the file. Limits are 100 MB and 60 minutes |
| Increase |
YouTube URL passed to | Use |
SoundCloud URL passed to | Use |
| Track is private, a playlist/set, or unavailable. Only public single tracks are supported |
Voice Cleaner job returns no | Job has not yet completed — call |
git clone https://github.com/StemSplit/stemsplit-mcp
cd stemsplit-mcp
npm install
npm run typecheck
npm run lint
npm test
npm run build
STEMSPLIT_API_KEY=sk_live_... npm run inspectnpm run inspect launches the MCP Inspector for interactive testing.
Add the install snippet above to claude_desktop_config.json, restart Claude, then ask:
Remove the vocals from
~/Music/song.mp3.
Claude calls the separate_stems tool, waits for the job to complete (~30–60s for a 3-minute track), and hands back the local path to the instrumental file. Or use the /karaoke slash command directly.
Yes. Use the separate_youtube tool or the /youtube_instrumental slash command. The StemSplit API handles the YouTube download server-side and returns vocals + instrumental stems. Output is fixed to vocals + instrumental, MP3, BEST quality.
Vocals, instrumental, drums, bass, other, piano, and guitar. Six-stem output (adding piano and guitar) requires quality=BEST and is only available for stem jobs (not YouTube jobs).
The web app is point-and-click. This MCP server lets you orchestrate stem separation through natural-language prompts to an LLM, or programmatic tool calls from any MCP client. Same backend (HTDemucs / Demucs on GPU), different interface. Use the web app for one-off jobs; use the MCP server when you want to chain stem separation with other tools (transcription, translation, agentic pipelines) inside an LLM-driven workflow.
No. The MCP server is a local stdio process that talks to the StemSplit cloud API over HTTPS. Audio bytes are uploaded directly to Cloudflare R2 via presigned PUT (your API key never crosses the network with the audio). Stem separation runs on StemSplit's GPU workers. If you want fully local separation, look at demucs or demucs-onnx.
StemSplit uses a pay-per-second model: 1 credit = 1 second of audio. Credits are deducted at job submission. New accounts include free credits. Check current pricing at stemsplit.io/pricing.
Input: MP3, WAV, FLAC, M4A, OGG, WebM, AAC, WMA (up to 100 MB / 60 minutes). Output: MP3, WAV, or FLAC.
By default, in ~/Downloads/stemsplit/<jobId>/ with one file per stem. Override per-call with outputDir or globally with the STEMSPLIT_DEFAULT_OUTPUT_DIR env var.
Yes. stemsplit-mcp follows the MCP spec exactly. Any client that speaks the stdio transport works. For programmatic Node.js / TypeScript clients, see @modelcontextprotocol/sdk.
Yes. Use the clean_voice tool (or the /clean_voice prompt). It runs DeepFilterNet on your audio and returns the cleaned file. You can also pass denoiseVocals: true to separate_stems to denoise the extracted vocals stem automatically as part of a stem separation job.
Pass wait: false to separate_stems, separate_youtube, or clean_voice. You'll get the jobId back immediately and can poll later with get_job / get_youtube_job / get_denoise_job. Or set a longer timeoutSeconds (up to 3600s).
Sign up at stemsplit.io and generate a key at stemsplit.io/app/settings/api. The key format is sk_live_....
MIT (c) 2026 StemSplit
StemSplit — hosted stem separation web app and API
StemSplit API docs — full REST reference + OpenAPI spec
n8n-nodes-stemsplit — n8n community node for stem separation workflows
stemsplit-python — Python SDK for the StemSplit API
stemsplit CLI — command-line tool (Go), available via Homebrew
demucs-onnx — ONNX export of HTDemucs for local inference
Model Context Protocol — the open protocol this server implements
stem separation MCP, vocal remover MCP, karaoke generator MCP, voice cleaner MCP, noise removal MCP, background noise remover, DeepFilterNet MCP, Claude Desktop audio, Cursor audio tools, instrumental extractor, acapella extractor, AI stem splitter, MCP audio server, remove vocals from MP3, isolate vocals, split audio into stems, YouTube vocal remover, SoundCloud vocal remover, SoundCloud stem separator, SoundCloud instrumental extractor, HTDemucs MCP, Demucs MCP, MCP server for stem separation, podcast noise removal, audio cleanup AI.
Download the output stems of a COMPLETED job to a local directory. Presigned URLs are re-fetched fresh on every call so the 1-hour expiry is never a problem.
| Name | Required | Description | Default |
|---|---|---|---|
| jobId | Yes | The job ID to download outputs for. | |
| kind | No | Whether this is a stem job (default) or a YouTube job. | stem |
| outputDir | No | Directory to write outputs into. Defaults to ~/Downloads/stemsplit/<jobId>/. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description adds that presigned URLs are re-fetched to avoid expiry, which is helpful. However, it doesn't disclose what happens if the job isn't complete or if there are permission requirements.
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 concise sentences: first states purpose, second adds behavioral detail. No unnecessary words 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?
Given no output schema, description doesn't explain return value (presumably success/confirmation). But for a download tool, that's acceptable. Covers job completion constraint and presigned URL behavior.
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 100%, so baseline is 3. Description doesn't add extra meaning beyond schema; the three parameters are sufficiently documented in schema.
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?
Clear verb+resource: 'Download the output stems' with context that job must be COMPLETED. Distinct from sibling tools like separate_stems (creation) and get_job (metadata).
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?
Implicitly states when to use: for completed jobs. Lacks explicit exclusions (e.g., 'do not use for incomplete jobs') and doesn't name alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the authenticated user's remaining StemSplit credit balance in seconds, minutes, and a human-readable string.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even without annotations, the description transparently discloses the output format (seconds, minutes, human-readable string) and implies authentication via 'authenticated user'. It lacks details on rate limits or error states, but the core behavior is clear.
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, well-structured sentence that immediately conveys the action and output. No unnecessary words, 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?
Given the tool's simplicity (no parameters, no output schema), the description provides all necessary information: what the tool does and the format of the returned data. It is complete for its context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters and 100% schema description coverage, the baseline is 4. The description adds no parameter info because none exists, but it correctly informs the user that no input is 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 clearly states the tool returns the authenticated user's remaining credit balance, specifying the resource and output formats (seconds, minutes, human-readable string). It distinguishes itself from siblings like download_stems or separate_stems, which handle different operations.
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?
Usage is implied by the tool's purpose—checking credit balance—but no explicit guidance on when to use versus alternatives or when not to use it is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the latest state of a stem job, including fresh 1-hour presigned download URLs when COMPLETED. Use for jobs created via separate_stems.
| Name | Required | Description | Default |
|---|---|---|---|
| jobId | Yes | The stem-job ID returned from separate_stems. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses that URLs are presigned for 1-hour and only when COMPLETED. Lacks details on potential side effects or polling but is adequate for a fetch operation.
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 sentences, no filler. First sentence states purpose, second provides usage context. Highly efficient.
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?
No output schema, so description should explain response structure. Mentions 'latest state' and 'presigned download URLs' but doesn't detail other possible fields or states. Adequate but could be more comprehensive.
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 100% with clear parameter description. Description adds no extra beyond schema. Baseline score of 3 applies.
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?
Clearly states 'Fetch the latest state of a stem job' with added detail on presigned URLs on completion. Distinguishes from siblings by specifying job created via separate_stems.
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?
Explicitly says to use for jobs from separate_stems, implying context. Does not explicitly exclude other job types but is clear enough given sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the latest state of a SoundCloud job, including fresh 1-hour presigned download URLs when COMPLETED.
| Name | Required | Description | Default |
|---|---|---|---|
| jobId | Yes | The SoundCloud job ID returned from separate_soundcloud. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It discloses that the tool includes fresh presigned URLs that expire in 1 hour when completed. The verb 'Fetch' implies read-only. However, it does not mention authentication, rate limits, or error handling.
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 sentence that conveys the core functionality efficiently. It starts with the verb and includes essential details without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 param, no output schema), the description provides sufficient information to understand its purpose and a key behavioral nuance. It lacks details about return structure for non-completed jobs, but overall 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 100%, so baseline is 3. The description does not add meaning beyond the schema for the parameter 'jobId' except for the behavioral context about URLs, which is not parameter-specific.
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?
Description clearly states the specific verb 'Fetch', resource 'latest state of a SoundCloud job', and adds a key detail about 'fresh 1-hour presigned download URLs when COMPLETED'. This differentiates it from sibling tools like get_youtube_job or get_job.
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?
Usage context is implied for fetching job status after submitting via separate_soundcloud, but there is no explicit guidance on when to use this tool vs alternatives like get_job or list_soundcloud_jobs. No when-not-to-use or alternative mentions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the latest state of a YouTube job, including fresh 1-hour presigned download URLs when COMPLETED.
| Name | Required | Description | Default |
|---|---|---|---|
| jobId | Yes | The YouTube job ID returned from separate_youtube. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It discloses that download URLs are fresh and expire in 1 hour, but does not clarify behavior for non-COMPLETED states, error handling for invalid jobId, or whether the operation is read-only. Partial transparency.
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 sentence that front-loads the primary purpose and adds a critical detail. No redundancy or waste; every word serves a 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?
Given the tool's simplicity (one parameter, no output schema), the description is complete. It tells the agent exactly what to expect: the job state and, conditionally, download URLs. No missing information for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter `jobId` has a clear description in the schema. The tool description adds value by specifying that the result includes fresh presigned URLs when COMPLETED, going beyond the schema to explain the output behavior.
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 ('Fetch the latest state') and the specific resource ('a YouTube job'), with a key differentiator ('fresh 1-hour presigned download URLs when COMPLETED'). It distinguishes from siblings like `get_soundcloud_job` and `list_youtube_jobs` by specifying YouTube and focusing on a single job.
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 use when you have a job ID, but provides no explicit guidance on when to use vs. alternatives (e.g., `list_youtube_jobs` for listing, `get_job` for generic jobs) or when not to use (e.g., job not yet completed). No exclusions or context for optimal usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the authenticated user's recent stem jobs, with optional status filter and pagination. Output URLs are NOT included here; use get_job for a specific job.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No | ||
| status | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses that output URLs are excluded, which is a key behavioral trait. However, it omits authentication requirements, default pagination, or ordering details.
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 concise sentences front-load the purpose and quickly add a critical caveat, containing no superfluous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema or annotations, the description covers the basics but does not specify response format, defaults, or limitations, leaving gaps for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description maps parameters to functionality (status filter, pagination with limit/offset) but lacks detailed semantics like enum meanings or default values, partially compensating for 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists the authenticated user's recent stem jobs with optional filtering and pagination, and distinguishes itself from sibling tools like get_job and source-specific list tools.
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 explicitly advises using get_job for output URLs, providing clear guidance on when not to use this tool. However, it does not contrast with list_soundcloud_jobs or list_youtube_jobs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the authenticated user's recent SoundCloud jobs, with optional status filter and pagination.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No | ||
| status | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'recent' and optional filter/pagination, but lacks details on authentication requirements, rate limits, or behavior when no jobs exist. The description is adequate but not comprehensive.
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 efficient sentence that front-loads the action and resource. It is concise, though slightly under-specified for fully self-contained understanding. 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?
Given the tool has 3 optional parameters, no required params, and no output schema, the description is incomplete. It does not explain return format, error handling, pagination behavior, or how to interpret results. More context is needed for successful invocation.
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 only generically mentions 'optional status filter and pagination' without explaining parameter semantics (e.g., meaning of each status enum, how limit/offset control pagination). Parameter names are self-explanatory but description adds minimal value.
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'), resource ('the authenticated user's recent SoundCloud jobs'), and includes optional filters and pagination. It distinguishes from sibling tools like 'get_soundcloud_job' (singular) and 'list_jobs' (likely broader scope).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing jobs with filters, but provides no explicit guidance on when to use this tool over siblings like 'list_jobs' or 'list_youtube_jobs'. No when-not-to-use or alternative recommendations are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the authenticated user's recent YouTube jobs, with optional status filter and pagination.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No | ||
| status | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It states the tool lists (read) the user's own jobs, but does not disclose details like sorting, default limits, or rate limits. The description is minimal and adds little beyond the action.
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 14-word sentence that is front-loaded and to the point. Every word contributes meaning, making it highly concise.
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 3 parameters and no output schema, the description covers the core functionality but lacks contextual details such as default pagination, order of results, and relationship to siblings like get_youtube_job. It is adequate but not comprehensive.
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 only vaguely mentions 'optional status filter and pagination.' It does not explain the semantics of each parameter (limit, offset, status) or their allowed values/enumerations, leaving the agent to infer.
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 lists the authenticated user's recent YouTube jobs, with optional filtering and pagination. It distinguishes itself from siblings like list_jobs and list_soundcloud_jobs by specifying the resource type (YouTube).
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 does not explicitly guide when to use this tool versus alternatives like list_jobs or get_youtube_job. The context is implied but no exclusions or alternative tool names are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit a SoundCloud track URL to StemSplit. The server fetches the track, separates it into vocals and instrumental (MP3, BEST quality), and returns local file paths once complete. Use this for any soundcloud.com URL.
| Name | Required | Description | Default |
|---|---|---|---|
| soundcloudUrl | Yes | A SoundCloud track URL — soundcloud.com/artist/track, m.soundcloud.com/artist/track, or on.soundcloud.com/shortcode. | |
| wait | No | If true (default), poll until completion and download outputs to disk. | |
| timeoutSeconds | No | ||
| pollIntervalSeconds | No | ||
| outputDir | No | Directory to write outputs into. Defaults to ~/Downloads/stemsplit/<jobId>/. Output is fixed to vocals + instrumental, MP3, BEST quality. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It explains that the server fetches, separates, and returns local file paths, and mentions quality and format. However, it does not disclose key behaviors: the 'wait' parameter's effect (whether the call is synchronous or asynchronous), rate limits, authentication needs, or error handling.
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 long with no redundant information. The first sentence delivers the core action and output, the second states usage scope. Every sentence is necessary and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, no output schema, and no annotations, the description covers the main flow (fetch, separate, return paths) and output format. However, it omits details about async behavior (when 'wait' is false), timeout/interval semantics, possible error states, and how this tool relates to sibling tools like 'separate_stems'.
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 already provides descriptions for all 5 parameters (e.g., URL formats, wait behavior, output directory defaults). The tool description adds no extra meaning beyond what the schema offers, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('submit', 'fetches', 'separates') and identifies the resource (SoundCloud track URL) and output (vocals and instrumental MP3 files). It clearly distinguishes from sibling tools like 'separate_youtube' by specifying SoundCloud-only URLs.
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 explicitly states 'Use this for any soundcloud.com URL', which is direct guidance. However, it lacks information on when not to use this tool or mention of alternative tools (e.g., 'separate_stems' for non-URL sources), and no prerequisites or context beyond URL handling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit an audio file or direct audio URL to StemSplit for stem separation. By default (wait=true), this polls until completion and downloads all output stems to disk, returning local file paths the LLM can hand off to other tools. For YouTube URLs, use separate_youtube instead.
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes | Local absolute path (e.g. /Users/me/song.mp3 or ~/Music/song.wav) or direct audio URL (https://...). Do NOT pass YouTube or SoundCloud URLs here — use separate_youtube for YouTube, separate_soundcloud for SoundCloud. | |
| outputType | No | Which stems to extract. VOCALS, INSTRUMENTAL, BOTH (default), FOUR_STEMS (vocals+drums+bass+other), SIX_STEMS (adds piano+guitar — requires quality=BEST). | BOTH |
| quality | No | Processing quality. FAST, BALANCED, or BEST (default). | BEST |
| outputFormat | No | Output file format. MP3 (default), WAV, or FLAC. | MP3 |
| fileName | No | Optional display name for the job (defaults to the source filename). | |
| wait | No | If true (default), block until the job completes and download stems to disk. If false, return job_id immediately and let the caller poll get_job. | |
| timeoutSeconds | No | Maximum time to wait for completion when wait=true. Default 600s (10 minutes). | |
| pollIntervalSeconds | No | How often to check job status when wait=true. Default 5s. | |
| outputDir | No | Directory to write stems into when wait=true. Defaults to ~/Downloads/stemsplit/<jobId>/. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must carry the burden. It explains the default polling behavior, downloading stems to disk, and returning local file paths. It mentions alternative wait=false behavior. However, it omits details like error handling, response format, or potential limitations (e.g., file size limits).
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?
Three concise sentences with no fluff. The first sentence states the core action, the second describes the default behavior and output, and the third provides a sibling differentiation. Information is front-loaded efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 parameters fully described in the schema and no output schema, the description covers the main workflow, default settings, and a key sibling distinction. It could mention the return type more explicitly (local paths) but overall sufficient for an agent to invoke the tool 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 coverage is 100%, so baseline is 3. The description adds value by explaining the default workflow (wait=true), the download behavior, and the alternative tool for YouTube. It complements the schema's detailed parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'submit an audio file or direct audio URL to StemSplit for stem separation' and specifies that it returns local file paths. It also distinguishes from sibling 'separate_youtube' by directing users to that tool for YouTube URLs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: use for audio files/URLs, not YouTube (referring to separate_youtube). However, it does not mention separate_soundcloud for SoundCloud URLs, though the schema does. The default behavior (wait=true) is explained.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit a YouTube URL to StemSplit. The server fetches the video, separates it into vocals and instrumental (MP3, BEST quality), and returns local file paths once complete. Use this for any youtube.com or youtu.be URL.
| Name | Required | Description | Default |
|---|---|---|---|
| youtubeUrl | Yes | A YouTube URL — youtube.com/watch?v=, youtu.be/, embed, or a bare 11-character video ID. | |
| wait | No | If true (default), poll until completion and download outputs to disk. | |
| timeoutSeconds | No | ||
| pollIntervalSeconds | No | ||
| outputDir | No | Directory to write outputs into. Defaults to ~/Downloads/stemsplit/<jobId>/. Output is fixed to vocals + instrumental, MP3, BEST quality. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It discloses the server fetches, separates, and returns file paths in MP3 BEST quality, but omits details like authentication, rate limits, or whether files are temporary. The polling behavior is implied via the wait parameter but not described.
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 sentences that are direct and succinct. Every word contributes essential information, and the key action is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters, no output schema, no annotations), the description covers the core functionality well: input format, output format, and quality. It lacks explanation of timeout, polling intervals, and output directory behavior, but these are detailed in the schema. Overall, it is adequate for an AI agent to understand the tool's purpose.
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 covers 60% of parameters with descriptions. The description adds value by explaining the overall process and output (vocals+instrumental MP3, local paths), which clarifies the context beyond raw parameter names. It does not detail each parameter individually but the schema already does that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action: submit a YouTube URL to separate vocals and instrumental MP3 files. It identifies the source (YouTube) and output (local file paths), distinguishing from siblings like separate_soundcloud.
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 explicitly states to use 'for any youtube.com or youtu.be URL', providing clear context. It does not mention when not to use or list alternatives, but the sibling name separate_soundcloud implies the differentiator.
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.2.1download_stemsget_balanceget_jobget_soundcloud_jobget_youtube_joblist_jobslist_soundcloud_jobslist_youtube_jobsseparate_soundcloudseparate_stemsseparate_youtubeEach tool targets a distinct resource and action: separate/get/list/download for files, SoundCloud, and YouTube, with no overlapping purposes. The descriptions clearly differentiate between job types and sources.
All tools follow a consistent verb_noun pattern with underscores (e.g., separate_stems, get_youtube_job, list_soundcloud_jobs). No mixing of conventions or vague verbs.
11 tools cover the core operations for a stem separation service: submission, status checking, downloading, and balance inquiry. The count is well-scoped without being excessive or insufficient.
The tool set covers the main workflow (submit, list, get, download) for three input types. A minor gap is the lack of cancel/delete for pending jobs, but the core use case is fully supported.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Generate AI music via the Lacuna Music API from MCP clients like Claude Desktop & Code.
Convert projects between Logic, Ableton, FL Studio and REAPER; generate, separate, transcribe
AI music studio: song generation with vocals, covers, stems, voice conversion, mastering, editing.
Use AI models for chat, image, and video generation from Claude Code and other MCP hosts.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/StemSplit/stemsplit-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
