Skip to main content
Glama

createMusic

Produce a piece of music from a text description, such as "epic orchestral battle theme" or "calm piano melody", with optional lyrics. The job result is a single audio result containing a URL. The description field is required; duration must be one of the allowed values (0 means auto, otherwise multiples of 10 up to 180 seconds) and out-of-range values return HTTP 400. Credits are held when the job is accepted and refunded if it fails or is cancelled. Use this for songs and musical scores; use createSoundEffect for short sound effects, createAmbiance for looping background soundscapes, and createAudioTransform to remix an existing audio sample. 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 generating music from a text description

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. Changed4 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 based on the description. 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 based on the description. Accepted values: 0, 10, 20, 30, 40, 50, 60, 70, 80, 90, 100, 110, 120, 130, 140, 150, 160, 170, 180. Default: 0."
  3. 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."
  4. Changed1 schema field changed
    • addedInput schema / properties / requestBody / properties / duration
      Added value: +{
      +  "default": 0,
      +  "description": "Duration in seconds. Use 0 for automatic duration based on the description. Accepted values: 0, 10, 20, 30, 40, 50, 60, 70, 80, 90, 100, 110, 120, 130, 140, 150, 160, 170, 180.",
      +  "example": 0,
      +  "type": "integer"
      +}
  5. Changed1 schema field changed
    • addedInput schema / properties / requestBody / properties / request_id
      Added value: +{
      +  "description": "Optional client-provided identifier for this request. Use this to retrieve results later via the results endpoint.",
      +  "type": "string"
      +}
  6. Added

TDQS

A5/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 behavioral burden and does so thoroughly: async job with {id, status}, single audio URL result, credits held and refunded on failure/cancellation, 3 credits per call, HTTP 400 for out-of-range duration, and idempotent request_id behavior are all disclosed.

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. It front-loads the core purposecars, then covers routing, parameters, credits, and async behavior without fluff. The structured flow makes even the long detail easy to absorb.

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?

Given there is no output schema and no annotations, the description is remarkably complete: it explains the result shape, how to poll, what errors occur, the credit contract, how to tag and locate jobs, and which sibling tools to use instead. Nothing essential for correct invocation is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema coverage is 100%, the description adds significant meaning beyond the schema: the required description field, accepted duration behavior with 0 as auto, credit consequences, error behavior, and request_id tagging for later retrieval via listGenerations. This goes well beyond the baseline.

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: "Produce a piece of music from a text description." It names concrete examples and explicitly says "Use this for songs and musical scores," clearly separating it from createSoundEffect, createAmbiance, and createAudioTransform.

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?

It provides explicit routing guidance: "Use this for songs and musical scores; use createSoundEffect for short sound effects..." It also explains when to use request_id with listGenerations and how to poll with getApiJob, covering both selection and operational context.

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.