ACE Music MCP Server by useapi.net (third-party)

Split a song into stems

acemusic_split_stems

Split a finished song into stems: vocals (vocal + instrumental, 5 credits) or all (every stem found: vocals, drums, bass, guitar, keys…, 60 credits); paid ACE Music plans only. A job: waits up to ~50 s, then returns the jobid for acemusic_get_job; the result is one mp3 link per track, signed and valid 24 hours (acemusic_get_job gives fresh ones). POST /music/stems.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "songId": "<songId>"
    },
    "name": "acemusic_split_stems"
  }
}

Input Schema

Name	Required	Description	Default
`mode`	No	vocals \| all (default vocals).
`songId`	Yes	A songId (user:<id>-<email>-song:so_…) from a finished job, acemusic_list_songs or acemusic_upload_file. It runs on the account that holds the song.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 15, 2026

TDQS

A4.6/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond the annotations: discloses the ~50 s wait, the asynchronous jobid handoff, per-track mp3 output, and that signed links expire after 24 hours. It also exposes the credit cost per mode, which is exactly the kind of consequence an agent needs before invoking a non-idempotent, credit-consuming write.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Dense but front-loaded: purpose first, then cost modes, then the async/return behavior, then the endpoint. The semicolon-chained clauses are information-rich but border on cramped, with no wasted sentences.

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?

With no output schema, the description carries the return contract itself — jobid, then one signed mp3 link per track valid 24 hours, with refresh via acemusic_get_job. Combined with the plan and credit constraints, an agent has everything needed to call it and interpret the result.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3; the description earns extra credit by attaching cost semantics to each mode (5 credits for vocals, 60 for all) and by explaining what constitutes a valid songId and whose account it runs on. The mode enum values are still not expanded beyond the schema's own list.

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?

Specific verb and resource ("Split a finished song into stems") plus the two operating modes with their credit costs. It is clearly distinct from siblings like acemusic_create_song or acemusic_improve_style, and even names the endpoint POST /music/stems.

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?

States the precondition (a finished song), the plan requirement (paid ACE Music plans only), and routes the agent forward to acemusic_get_job for results and fresh links. It does not explicitly say when not to use it (e.g. unfinished or uploaded-only songs), so it falls short of full when/when-not coverage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All ACE Music MCP Server by useapi.net (third-party) tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?