Skip to main content
Glama
Sign In
SunoMCP

SunoMCP

by AceDataCloud
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

suno_replace_section

Regenerate a specific time range of a song while leaving the rest unchanged, useful for fixing or replacing a verse, chorus, or lyrics section.

Instructions

Replace a specific time range in a song with new generated content.

Re-generates a portion of a song between the specified start and end times,
keeping the rest of the song unchanged. Great for fixing sections you don't like.

Use this when:
- A specific section of a song needs improvement
- You want to change lyrics in the middle of a song
- You want to replace a verse or chorus with something different

Returns:
    Task ID plus two complete songs by default, or two unmerged clips in candidates mode.

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>",
      "replace_section_start": "<replace_section_start>",
      "replace_section_end": "<replace_section_end>"
    },
    "name": "suno_replace_section"
  }
}

Input Schema

NameRequiredDescriptionDefault
lyricNoNew lyrics for the replaced section. Use section markers like [Verse], [Chorus].
modelNoModel version to use.chirp-v5-5
styleNoMusic style for the replaced section.
audio_idYesID of the audio to replace a section in.
callback_urlNoWebhook callback URL for asynchronous notifications.
negative_tagsNoStyles or genres to exclude from the replacement; keep concise. No fixed API character limit.
replace_section_endYesRequired end time in seconds, greater than start and no later than source duration.
replace_section_startYesRequired start time in seconds, at least 0; fractions are preserved.
replace_section_result_modeNoResult shape: full_song returns two complete songs, one from each replacement candidate; candidates returns the two unmerged replacement clips.full_song

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.1.25
    • addedInput schema / properties / negative_tags
      Added value: +{
+  "default": "",
+  "description": "Styles or genres to exclude from the replacement; keep concise. No fixed API character limit.",
+  "title": "Negative Tags",
+  "type": "string"
+}
    • changedInput schema / properties / replace_section_end / description
      Previous value: -"End time in seconds of the section to replace."New value: +"Required end time in seconds, greater than start and no later than source duration."
    • changedInput schema / properties / replace_section_start / description
      Previous value: -"Start time in seconds of the section to replace."New value: +"Required start time in seconds, at least 0; fractions are preserved."
    • addedInput schema / properties / replace_section_start / minimum
      Added value: +0
  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. Changed1 schema field changedv0.1.14
    • addedInput schema / properties / replace_section_result_mode
      Added value: +{
+  "default": "full_song",
+  "description": "Result shape: full_song returns two complete songs, one from each replacement candidate; candidates returns the two unmerged replacement clips.",
+  "enum": [
+    "candidates",
+    "full_song"
+  ],
+  "title": "Replace Section Result Mode",
+  "type": "string"
+}
  4. Addedv0.1.5
  5. Removedv0.1.3
  6. First observedv0.1.0

TDQS

A4/5.0
Behavior4/5

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

With zero annotations, the description carries the load and does disclose the key behavior: the untouched remainder of the song is preserved and output is a Task ID plus either two full songs or two unmerged clips. It omits that the call is asynchronous and requires polling (suno_get_task presumably) and says nothing about cost/credit consumption, which matters for a generation tool.

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?

Front-loaded with the one-line definition, then progressively more detail; the bulleted use cases are skimmable. Slightly padded — the 'Great for fixing sections you don't like' line and the Returns block duplicate what the schema's result_mode description already conveys.

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 9-parameter, fully documented schema with an output schema present and no annotations, the description covers purpose, when-to-use, and what is preserved versus regenerated. Nothing an agent needs to select and invoke it correctly is missing.

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 coverage is 100%, so the schema already documents every parameter including start/end constraints and the result_mode enum. The description restates the result_mode outcome but adds no syntax or format guidance beyond the schema; baseline 3 applies when the schema does the heavy lifting.

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?

States a specific verb and resource with scope: 'Replace a specific time range in a song with new generated content,' reinforced by 'Re-generates a portion ... keeping the rest of the song unchanged.' It is not, however, differentiated from plausibly adjacent siblings like suno_overpainting or suno_extend_music, so an agent still has to infer boundaries.

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?

An explicit 'Use this when' list gives three concrete triggering scenarios (fixing a weak section, changing mid-song lyrics, swapping a verse/chorus). There are no stated exclusions or named alternative tools, which keeps it short of a 5.

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

Deploy Server

Other Tools