Skip to main content
Glama
AceDataCloud

ProducerMCP

by AceDataCloud
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

producer_variation_music

Create a modified version of an existing song by adjusting arrangement, melody, or style. Use it to explore alternate interpretations or produce multiple takes while keeping the song's structure.

Instructions

Create a variation of an existing song with modifications.

Generates a new version of the song with subtle changes to the arrangement,
melody, or style while keeping the overall structure similar.

Use this when:
- You like a song but want a slightly different version
- You want to explore different interpretations of the same idea
- You need multiple takes of a similar song

Returns:
    Task ID and the variation audio information.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
asyncNoWhether to process the request asynchronously.
modelNoModel version to use for the variation.FUZZ-2.0
promptNoDescription of the desired variation. Examples: 'more upbeat tempo', 'darker mood', 'add more bass'
audio_idYesID of the audio to create a variation of.
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
    • removedInput schema / properties / style
      Removed value: -{
-  "default": "",
-  "description": "Music style for the variation. Examples: 'faster tempo, more energy', 'softer, more intimate', 'heavier, more distortion'",
-  "title": "Style",
-  "type": "string"
-}
  2. Changed1 schema field changedv0.1.16
    • addedInput schema / properties / async
      Added value: +{
+  "anyOf": [
+    {
+      "type": "boolean"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Whether to process the request asynchronously.",
+  "title": "Async"
+}
  3. Addedv0.1.13
  4. Removedv0.1.12
  5. First observedv0.1.0

TDQS

A3.8/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 burden. It clearly states that a new version is generated and that the return includes a Task ID and variation audio information. However, it does not disclose async/callback behavior, whether the original audio is left untouched, or any side effects beyond generating a new version.

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 clear sections for the main action, use cases, and return value. Some redundancy exists between the opening sentence and the second paragraph, as both describe generating a new version with modifications, which prevents a perfect score.

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

Completeness3/5

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

The description covers what the tool does and when to use it, and the output schema covers return values. However, it does not clarify how async processing works, when to set callback_url, or whether the original song is preserved, which are relevant for correctly invoking this tool in different scenarios.

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. The description adds some context by mentioning arrangement, melody, and style, which aligns with the prompt parameter's purpose, but it does not meaningfully explain audio_id, model, async, or callback_url beyond what the schema provides.

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 states a specific verb and resource: 'Create a variation of an existing song with modifications.' It further clarifies the nature of the output as a new version with subtle changes to arrangement, melody, or style while keeping structure similar, which distinguishes it clearly from sibling tools like generate, cover, extend, or replace_section.

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 gives concrete scenarios for when the tool is appropriate, such as wanting a slightly different version or exploring interpretations. However, it does not explicitly say when not to use it or name alternative sibling tools that might be better suited for related tasks.

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