Skip to main content
Glama
AceDataCloud

SunoMCP

by AceDataCloud
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
Python
Hybrid

suno_upload_cover

Turn your uploaded audio into an AI cover in a new style. Provide the audio ID to re-interpret your own music with a chosen model and optional style.

Instructions

Create an AI cover of an uploaded audio (your own music).

Similar to suno_cover_music but works with audio you uploaded via
suno_upload_audio. Re-arranges your music in a different style.

Use this when:
- You uploaded your own music and want a cover in a different style
- You want to hear your song re-interpreted by AI

Returns:
    Task ID and the cover audio information.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modelNoModel version to use.chirp-v5-5
styleNoTarget music style for the cover.
audio_idYesID of the uploaded audio to create a cover of. Must be an audio uploaded via suno_upload_audio.
audio_weightNoAdvanced parameter for cover operations. Controls how much the original audio influences the cover generation.
callback_urlNoWebhook callback URL for asynchronous notifications.

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

A3.9/5.0
Behavior3/5

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

No annotations are present, so the description carries the burden, and it does disclose an important async signal: the operation returns a task ID. However, it doesn't mention polling, credit consumption, or side effects beyond generation. For a generation tool this is 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.

Conciseness4/5

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

The description is well-structured with a clear opening sentence, a explicit sibling differentiation, a 'use when' guidance section, and a return-value note. It is slightly more verbose than necessary but every sentence carries information.

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 the output schema handles return valuesaren't in this context (no output schema provided here), but the description itself discloses the asynchronous task-return behavior and the required input relationship to suno_upload_audio. Missing credit/irreversibility warnings, but this is reasonably complete for a generation tool with a readOnlyHint provided at the annotation level.

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?

Input schema coverage is near-complete, with descriptions for audio_id, callback_url, and style. The description adds only the workflow meaning ('this is for audio uploaded via suno_upload_audio'), which the schema already implies. Baseline 3 is appropriate since the description doesn't materially compensate for schema gaps.

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 description opens with a clear verb+resource pair: 'creates a cover of a song' based on uploaded audio.#### It immediately differentiates the tool from its sibling suno_cover_music by noting that this variant operates on uploaded audio via suno_upload_audio. This gives an agent enough to select the correct tool without opening schemas.

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 description explicitly names the sibling tool suno_cover_music and explains the distinguishing condition ('works with audio uploaded via suno_upload_audio'). It also provides a 'use this when' section with concrete scenarios (cover a song a user uploaded). It stops short of an explicit when-not-to-use list, which would push it to a 5.

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