Skip to main content
Glama

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

Generate songs

acemusic_create_song

Generate two songs, one of two ways: send prompt (a free-text idea, optionally with up to 3 reference songIds and 3 images) and ACE Music writes the style, lyrics and title; or send style and/or lyrics (your own words, or instrumental) with a mode: generate, cover (1 songId), remix or edit (ACE-Step, 1 songId), mashup (2-3 songIds). Use prompt for a quick idea, style + lyrics for control; never prompt with lyrics. A job: waits up to ~50 s, then returns the jobid for acemusic_get_job; the result is two songs with songIds, model asked and modelUsed, a permanent public mp3 link (audioUrl) and a direct playUrl for players, valid until playUrlExpires (about an hour). POST /music.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "acemusic_create_song"
  }
}

Input Schema

NameRequiredDescriptionDefault
bpmNoace-step-1.5-xl generate: tempo 30-200.
endNoedit: the end of the part to rewrite, in seconds (at least 1 s after start).
keyNoace-step-1.5-xl generate, cover or remix: the key, e.g. "A minor".
modeNoYour-own-texts way: generate | cover | remix | edit | mashup (default generate).
emailNoThe ACE Music account email. Optional: by default a healthy account with a free slot is picked (or the account the referenced songs live on).
modelNoThe model: acemusic-v1 | acemusic-v1.1 | ace-step-1.5-xl. Default acemusic-v1 (4 credits a request); ace-step-1.5-xl is free (0 credits); acemusic-v1.1 reads references and covers (requests that need reading switch to it, reported as modelUsed).
startNoedit: the start of the part to rewrite, in seconds.
styleNoThe style: genre, instruments, mood, tempo, vocals. Required for mode generate; up to 1000 characters (512 on ace-step-1.5-xl).
titleNoThe songs' title, up to 80 characters.
imagesNoThe idea way only: up to 3 image ids from acemusic_upload_file (user:<id>-<email>-media:cx_…) that the songs are about.
lyricsNoYour lyrics, [Verse] / [Chorus] tags allowed; up to 5000 characters (2000 on ace-step-1.5-xl).
promptNoThe idea way: the song idea, up to 2000 characters (optional when references or images are given). Do not combine with style, lyrics, title, mode or the options below.
durationNoLength in seconds: 30-600 on acemusic-v1, 10-240 on ace-step-1.5-xl (mode generate). Default: automatic.
negativeNoacemusic-v1 or ace-step-1.5-xl generate: styles to avoid, up to 200 characters.
thinkingNoace-step-1.5-xl generate: planning strength 0-100 (creative when low, steady when high).
referencesNosongIds: with prompt, up to 3 to guide the songs; with a mode, 1 for cover / remix / edit, 2-3 for mashup, none for generate.
instrumentalNotrue: no vocals (send no lyrics).
coverStrengthNoace-step-1.5-xl cover / remix: how much of the original stays, 0-100 (default 20).
remixStrengthNoace-step-1.5-xl cover / remix: how far it moves away, 0-100 (default 0).
timeSignatureNoace-step-1.5-xl generate: the meter.
audioInfluenceNoPaid models with a reference: how closely the source is followed, 0-100 (default 60).
referenceAudioNoace-step-1.5-xl only: a songId whose sound guides the result.
styleInfluenceNoPaid models: how strictly the style is followed, 0-100 (default 80).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the annotations (which only say this is a non-read-only, non-idempotent, open-world write), the description discloses that the call blocks up to ~50 s, then hands back a jobid to poll with acemusic_get_job rather than finished audio. It also describes the result shape (two songs, songIds, model asked vs. modelUsed), the permanence of audioUrl versus the ~1 hour playUrlExpires window, and the cost/model trade-off.

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?

It is front-loaded with the two generation paths and the operational facts, and almost every clause carries information. The trade-off is density: a single long run-on paragraph packing modes, exclusivity rules, timing, and return fields, which is harder to parse than a short bulleted structure would be.

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 23-parameter, non-idempotent, open-world generation tool with no output schema, the description supplies the missing pieces an agent needs: the async job protocol and follow-up call, the approximate wait, and what the returned artifacts are plus their expiry. Nothing critical to invoking or chaining the tool is left implicit.

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?

With 100% schema description coverage the schema already documents all 23 parameters, so this dimension starts at 3. The description raises it by adding cross-parameter constraints the schema cannot express: prompt must never be combined with style, lyrics, title, mode or the option fields, and reference counts vary by mode. It does not, however, explain the influence/strength knobs beyond what the schema already says.

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 gives a specific verb and resource ('Generate two songs') and then breaks the operation into two clearly named paths (prompt-based vs. style/lyrics with a mode). It clearly distinguishes the follow-up step ('returns the jobid for acemusic_get_job'), but it never distinguishes itself from sibling text tools like acemusic_write_lyrics or acemusic_improve_style, which an agent composing lyrics might reasonably consider first.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states explicit selection rules: 'Use prompt for a quick idea, style + lyrics for control; never prompt with lyrics.' It also maps each mode to its reference requirement (cover/remix/edit = 1 songId, mashup = 2-3, generate = none), so the agent knows exactly which combination of inputs is legal.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources