ProducerMCP

producer_extend_music

Extend an existing song from any timestamp with new verses, a bridge, or an outro to make it longer. Provide optional lyrics and style prompt to control the added section.

Instructions

Extend an existing song from a specific timestamp with new content.

This allows you to continue a previously generated song, adding new sections
like additional verses, a bridge, or an outro.

Use this when:
- A generated song is too short and you want to add more
- You want to add a bridge or outro to an existing song
- You're building a longer song piece by piece

Returns:
    Task ID and the extended audio information.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`async`	No	Whether to process the request asynchronously.
`lyric`	No	Lyrics for the extended section. Use section markers like [Verse], [Chorus], [Bridge], [Outro]. The extension will continue from where the original song left off.
`model`	No	Model version to use for the extension.	FUZZ-2.0
`prompt`	No	Prompt for the extension. Leave empty to maintain the original style, or specify how to change the style mid-song.
`audio_id`	Yes	ID of the audio to extend. This is the 'id' field from a previous generation result.
`continue_at`	Yes	Timestamp in seconds where to start the extension. For example, 120.5 means continue from 2 minutes and 0.5 seconds into the song.
`callback_url`	No	Webhook callback URL for asynchronous notifications.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.1.18Aug 28, 2026

addedInput schema / properties / prompt

Added value: +{
+  "default": "",
+  "description": "Prompt for the extension. Leave empty to maintain the original style, or specify how to change the style mid-song.",
+  "title": "Prompt",
+  "type": "string"
+}

removedInput schema / properties / style

Removed value: -{
-  "default": "",
-  "description": "Music style for the extension. Leave empty to maintain the original style, or specify to change the style mid-song.",
-  "title": "Style",
-  "type": "string"
-}

Changed1 schema field changedv0.1.16Aug 11, 2026

addedInput schema / properties / async

Added value: +{
+  "anyOf": [
+    {
+      "type": "boolean"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Whether to process the request asynchronously.",
+  "title": "Async"
+}

Addedv0.1.13May 27, 2026
Removedv0.1.12May 20, 2026
First observedv0.1.0Apr 25, 2026

TDQS

A3.9/5.0

Behavior3/5

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

With no annotations, the description carries the behavioral disclosure burden. It does state that the tool returns a Task ID and extended audio information, which is useful, and it clarifies that the extension continues from a timestamp. However, it does not describe asynchronous behavior implications, whether the original audio is preserved, or what happens if no lyric/prompt is provided.

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-organized with a clear first sentence, a brief elaboration, bulleted use cases, and a returns line. It is concise and front-loaded, though the second paragraph somewhat repeats the first sentence's idea of continuing a previously generated song.

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 tool has 7 parameters, an output schema, and sibling tools like producer_replace_section, the description covers the core selection criteria and expected result well. It could be more complete by mentioning async/callback behavior or explicitly contrasting with replace_section, but the combination of description and rich schema is sufficient for an agent to invoke it correctly.

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 the schema already documents all parameters including continue_at, audio_id, lyric, prompt, and async. The description adds contextual framing around 'timestamp' and 'new content' but does not materially clarify parameter semantics beyond the existing schema descriptions.

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 uses a specific verb ('Extend') and resource ('an existing song from a specific timestamp'), clearly distinguishing this from generation, cover, variation, and replacement tools. It also gives concrete examples of what can be added, such as verses, a bridge, or an outro, making the purpose unmistakable.

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 provides clear, actionable conditions: too short a song, adding a bridge/outro, or building a longer song piece by piece. It does not explicitly name alternatives or state when not to use the tool, so it stops 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