Gomo Sounds

Regenerate a section, extend or make a similar track

derive_music

Makes a NEW version of a track from an existing version (spends credits: refused until the user approved the cost, see approve_spending). origin=repaint regenerates only the section [start, end] seconds (at least 3 s) and keeps the rest; origin=extend adds seconds of new music after the end, in the same mood (the final length must fit the user's plan); origin=cover makes a similar track from this one (closeness: close, medium or loose). note says what should change and is added to the end of the source prompt as written, so write it in English tags. Lyrics, tempo and key come from the source version. Charges the generated seconds (the section, the tail; cover charges the whole track) at the version's quality level. Same response as generate_music.

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": {
      "version_id": "<version_id>",
      "origin": "<origin>"
    },
    "name": "derive_music"
  }
}

Input Schema

Name	Required	Description
`end`	No	repaint: end of the section, in seconds (at least 3 s after start).
`note`	No	What should change, added to the source prompt as is (English tags).
`wait`	No	false = only queues it and returns the jobId for job_status (see generate_music).
`start`	No	repaint: start of the section, in seconds.
`origin`	Yes
`quality`	No	Quality level; omitted: the track's current level.
`seconds`	No	extend: how many seconds to add (3 to 90; more, in steps). The final length must fit the plan: up to 4 min for this account.
`closeness`	No	cover: how close to the source (default medium).
`version_id`	Yes	The source version (a generationId of a track from generate_music, get_entity or find_sounds).
`auto_choose`	No

Output Schema

Name	Required	Description	Default
`url`	Yes
`created`	Yes
`credits`	Yes
`refunded`	Yes
`studioUrl`	Yes
`generationIds`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 11, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations carry only a title, so the description bears the full burden and delivers: it spends credits, is refused until the user approves the cost, charges the generated seconds at the version's quality level, and constrains inputs (sections at least 3 s, final length must fit the account's 4-minute plan). It also discloses inheritance behavior (lyrics, tempo, key come from the source version) that no structured field states.

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?

It is front-loaded with the core action and then walks the modes in order, which matches how an agent will read it. It is a dense single paragraph with mild redundancy, repeating the credit/charging idea at the start and near the end.

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 10-parameter, three-mode derivation tool with an output schema, everything an agent needs is present: mode semantics, cost and approval gating, length constraints, inheritance, and a pointer that the response matches generate_music. No return-value documentation is needed because an output schema exists.

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

Parameters4/5

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

Schema coverage is 80%, so baseline is 3, and the description adds real meaning: how `note` is appended verbatim to the source prompt and must be English tags, that `start`/`end` apply only to repaint, and that `seconds` increases can go beyond 90 in steps. The only parameter left unexplained in both places is `auto_choose`.

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 ('Makes a NEW version of a track from an existing version') and then enumerates the three distinct modes (repaint, extend, cover) with their precise semantics. An agent can distinguish this from generate_music without opening either schema.

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?

Each origin value is paired with the condition that selects it: repaint for a bounded section, extend for added tail music, cover for a similar track. It also routes the agent to approve_spending when credits are refused and to job_status when wait=false, so the cross-tool flow is explicit.

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

All Gomo Sounds tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?