Skip to main content
Glama

createAudioTransform

Remix an existing audio sample (a sound effect, ambiance, or music clip) into a variation guided by a text prompt, for example turning a track into an 80s synthwave or metal version. Both the sample and the prompt are required; the sample is uploaded as a URL or base64 audio and must be at most 15MB or the call returns HTTP 400, and duration must be one of the allowed values (0 means match the source, otherwise multiples of 10 up to 180 seconds). The job result is a single audio result containing a URL. The optional modification_strength (0 to 1, default 0.6) controls how far the result departs from the original. Credits are held when the job is accepted and refunded if it fails or is cancelled. Use this to transform existing audio you already have; use createSoundEffect, createAmbiance, or createMusic to generate audio from scratch. Pass an optional request_id to tag the result so you can locate it later via listGenerations (type audio). Async generation job: returns {id, status} - poll getApiJob (job and credit contract: see the server instructions).

Credits: This endpoint consumes 3 credits per call.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
requestBodyYesPayload for remixing an audio sample (sound effect, ambiance or music) into a variation guided by a text prompt

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / requestBody / properties / request_id / description
      Previous value: -"Optional client-provided identifier, unique per request. Re-sending the same request_id returns the existing job instead of generating again. Also usable with the results endpoint."New value: +"Optional client-provided identifier, unique per request. Re-sending the same request_id returns the existing job instead of generating again. Also usable as the request_id filter of listGenerations."
  2. Changed6 schema fields changed
    • removedInput schema / properties / requestBody / properties / augment_prompt / default
      Removed value: -true
    • changedInput schema / properties / requestBody / properties / augment_prompt / description
      Previous value: -"Augment the prompt behind the scenes. Disable to have more control."New value: +"Augment the prompt behind the scenes. Disable to have more control. Default: true."
    • removedInput schema / properties / requestBody / properties / duration / default
      Removed value: -0
    • changedInput schema / properties / requestBody / properties / duration / description
      Previous value: -"Duration in seconds. Use 0 for automatic duration matching the source sample. Accepted values: 0, 10, 20, 30, 40, 50, 60, 70, 80, 90, 100, 110, 120, 130, 140, 150, 160, 170, 180."New value: +"Duration in seconds. Use 0 for automatic duration matching the source sample. Accepted values: 0, 10, 20, 30, 40, 50, 60, 70, 80, 90, 100, 110, 120, 130, 140, 150, 160, 170, 180. Default: 0."
    • removedInput schema / properties / requestBody / properties / modification_strength / default
      Removed value: -0.6
    • changedInput schema / properties / requestBody / properties / modification_strength / description
      Previous value: -"Controls how strongly the source sample is modified. 0 keeps it close to the original, 1 transforms it fully."New value: +"Controls how strongly the source sample is modified. 0 keeps it close to the original, 1 transforms it fully. Default: 0.6."
  3. Changed2 schema fields changed
    • changedInput schema / properties / requestBody / properties / modification_strength / default
      Previous value: -0.5New value: +0.6
    • changedInput schema / properties / requestBody / properties / modification_strength / example
      Previous value: -0.5New value: +0.6
  4. Changed1 schema field changed
    • changedInput schema / properties / requestBody / properties / request_id / description
      Previous value: -"Optional client-provided identifier for this request. Use this to retrieve results later via the results endpoint."New value: +"Optional client-provided identifier, unique per request. Re-sending the same request_id returns the existing job instead of generating again. Also usable with the results endpoint."
  5. Added

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations, the description carries the full burden, and it does so thoroughly. It discloses async behavior, the {id, status} return shape, polling via getApiJob, the single audio result with a URL, credit hold/refund behavior, the 3-credit cost, and the HTTP 400 condition for oversized samples.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

The description is dense but every sentence earns its place: purpose, required inputs, size limit, duration rules, result format, strength parameter, credit behavior, sibling alternatives, request_id, and async polling. It is front-loaded with the core purpose and gives examples before practical constraints.

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?

Despite having no output schema and no annotations, the description covers all essential operational context: async job lifecycle, polling endpoint, result contents, credit semantics, size limit, valid durations, required inputs, and how to locate the result via listGenerations. Nothing critical is missing for an agent to invoke the tool 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 baseline is 3. The description adds some context beyond the schema, such as the HTTP 400 consequence for exceeding 15MB and the request_id link to listGenerations, but most parameter meaning is already present in the input schema.

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 specific verb and resource: 'Remix an existing audio sample ... into a variation guided by a text prompt', with concrete examples like '80s synthwave or metal version'. It clearly distinguishes this from generate-from-scratch siblings by saying 'use createSoundEffect, createAmbiance, or createMusic to generate audio from scratch'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit guidance is given: 'Use this to transform existing audio you already have; use createSoundEffect, createAmbiance, or createMusic to generate audio from scratch.' It also states the required inputs (sample and prompt), the 15MB limit, and the async polling flow via getApiJob, so an agent knows exactly when to choose this tool.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.