Skip to main content
Glama

suno_cover_music

Create a cover or remix of an existing song in a different genre, style, or mood while preserving its core melody and lyrics.

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.

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": {
      "audio_id": "<audio_id>"
    },
    "name": "suno_cover_music"
  }
}

Input 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.
persona_idNoPersona ID for a specified-voice cover. For private voices from suno_create_voice, first upload the source with the same persona_id in suno_upload_audio, then use suno_upload_cover with its returned audio_id. Keep all steps on the same service channel; vocal_gender is not required and cannot replace the voice ID.
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

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.1.24
    • addedInput schema / properties / persona_id
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Persona ID for a specified-voice cover. For private voices from suno_create_voice, first upload the source with the same persona_id in suno_upload_audio, then use suno_upload_cover with its returned audio_id. Keep all steps on the same service channel; vocal_gender is not required and cannot replace the voice ID.",
      +  "title": "Persona Id"
      +}
  2. 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"
      +]
  3. Addedv0.1.5
  4. Removedv0.1.3
  5. 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"
      +}
  6. First observedv0.1.0

TDQS

A3.6/5.0
Behavior3/5

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

With no annotations provided, the description carries most of the behavioral burden. It usefully states that the tool generates a new version while keeping core melody and lyrics, and that it returns a Task ID and cover audio information. However, it does not clarify asynchronous task handling, whether the original audio is left unchanged, permission requirements, or how the task ID should be used afterward.

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?

The description is front-loaded with purpose and structured with a useful 'Use this when' list. It is reasonably concise, though the first two sentences overlap by both explaining the different-style cover concept.

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?

Given full schema coverage and an existing output schema, the description provides enough context to understand the tool's intent, common use cases, and return shape. The main remaining gap is sibling differentiation, especially versus remaster, mashup, upload_cover, and other generation/editing tools.

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%, so all seven parameters, including audio_id, style, prompt, persona_id, and callback_url, are already well documented in the schema. The description does not add parameter-specific meaning beyond the schema and mainly describes the overall cover/remix concept.

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 states a specific verb and resource: create a cover or remix version of an existing song in a different style. It also clarifies that the new version changes arrangement, genre, or mood while keeping core melody and lyrics. It does not explicitly differentiate from similar siblings such as suno_remaster_music, suno_mashup_music, or suno_upload_cover.

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?

It includes a clear 'Use this when' section with three concrete scenarios: hearing a song in a different genre, making an acoustic version, or remixing with a different vibe. This gives strong positive guidance, though it does not state when not to use it or name alternative sibling tools.

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