Skip to main content
Glama
AceDataCloud

SunoMCP

by AceDataCloud
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
Python
Hybrid

suno_cover_music

Create a cover or remix of an existing song in a new genre, style, or mood while preserving the original melody and lyrics. Specify a target style or prompt to transform the audio.

Instructions

Create a cover or remix version of an existing song in a different style.

This generates a new version of a song with a different arrangement, genre,
or mood while keeping the core melody and lyrics.

Use this when:
- You want to hear a song in a different genre
- You want an acoustic/unplugged version of an electronic song
- You want to remix a song with a different vibe

Returns:
    Task ID and the cover audio information.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modelNoModel version to use for the cover.chirp-v5-5
styleNoTarget music style for the cover. Examples: 'jazz, smooth, saxophone', 'acoustic folk, gentle guitar', 'electronic dance, high energy'
promptNoDescription of how you want the cover to sound. Examples: 'acoustic unplugged version', 'jazz lounge style', '80s synthwave remix'
audio_idYesID of the audio to create a cover of. This is the 'id' field from a previous generation.
audio_weightNoAdvanced parameter for cover operations. Controls how much the original audio influences the cover generation.
callback_urlNoWebhook callback URL for asynchronous notifications. When provided, the API will call this URL when the cover is complete.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.1.18
    • changedInput schema / properties / model / enum
      Previous value: -[
-  "chirp-v3-0",
-  "chirp-v3-5",
-  "chirp-v4",
-  "chirp-v4-5",
-  "chirp-v4-5-plus",
-  "chirp-v5",
-  "chirp-v5-5"
-]New value: +[
+  "chirp-v6",
+  "chirp-v6-wild",
+  "chirp-v6-mini",
+  "chirp-v3-0",
+  "chirp-v3-5",
+  "chirp-v4",
+  "chirp-v4-5",
+  "chirp-v4-5-plus",
+  "chirp-v5",
+  "chirp-v5-5"
+]
  2. Addedv0.1.5
  3. Removedv0.1.3
  4. Changed1 schema field changedv0.1.1
    • addedInput schema / properties / audio_weight
      Added value: +{
+  "anyOf": [
+    {
+      "type": "number"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Advanced parameter for cover operations. Controls how much the original audio influences the cover generation.",
+  "title": "Audio Weight"
+}
  5. First observedv0.1.0

TDQS

A4/5.0
Behavior3/5

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

With no annotations provided, the description must carry the behavioral burden, and it does state that a new version is generated and that a Task ID plus cover audio is returned, implying an asynchronous, non-destructive operation. But it never explicitly says the original audio is untouched, that the result is delivered via a task that must be polled, or that generation is async. The gaps are notable but not misleading.

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

Conciseness5/5

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

The description is compact and front-loaded: the purpose is stated in the first sentence, followed by scannable use-case bullets and a short returns section. No filler or redundant schema repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 6-parameter tool with a full schema and an output schema, the description covers the core selection context and return shape. It is missing only an explicit workflow note about task polling/callback behavior, but 'Returns Task ID' hints at it and the callback_url parameter covers the alternative.

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

Parameters3/5

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

Schema description coverage is 100%, with each parameter (audio_id, style, prompt, model, audio_weight, callback_url) already documented. The tool description adds no parameter-level detail beyond the schema, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence states a specific operation: creating a cover/remix of an existing song in a different style, and further clarifies it keeps core melody and lyrics. This is specific enough to distinguish from the generation, mashup, and remaster siblings even without naming them. The 'existing song' and 'different style' framing makes the resource and action concrete.

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

Usage Guidelines4/5

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

The 'Use this when' section lists three concrete scenarios (different genre, acoustic version, different vibe) that tell an agent when to select this tool. However, it provides no exclusions or explicit alternatives, so it stops short of a full when/when-not guide.

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

Install Server

Other Tools