Gomo Sounds

Generate a track

generate_music

Generates ONE version of a track for an event of the Music tab (spends credits: refused until the user approved the cost in the conversation, see approve_spending). Without prompt/duration/loop, uses the event's. The prompt goes to the music model exactly as written (nothing is rewritten or added behind it), so write it in English as comma-separated tags: genre, mood, instruments, tempo, production (e.g. "medieval folk, lute, warm, 90 bpm, intimate"). A genre, voice or vocal_level you pass is written into the prompt as words (genre first, voice last). Parts, bpm, key_scale and time_signature are optional structure. Instrumental by default; with lyrics, pass them with [Verse]/[Chorus] tags, or ask the user to write them on the site. The duration must fit the user's plan: duration_sec says this account's limit, never ask for more. A track takes minutes: the tool waits up to 10 minutes and, if still generating, tells you to check later; with wait=false it only queues and returns a jobId for job_status (use it for several tracks: queue them all, the account generates one at a time). Before the FIRST track, the user must accept the rights notice on the site (the tool says so). Returns the new version (with the music page url), like generate_sounds. The game only plays chosen versions: if the event has none yet, the new one becomes chosen (auto_choose=false turns this off).

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": {
      "event_id": "<event_id>"
    },
    "name": "generate_music"
  }
}

Input Schema

Name	Required	Description
`bpm`	No	Compose ("Andamento"): tempo in beats per minute (60 to 180 sound best).
`loop`	No	true = the end is blended into the start, for a track the game repeats. Saved on the event.
`mode`	No	describe = only the prompt; compose = you also set the tempo, key and meter. Omitted: compose when bpm, key_scale, time_signature, genres or sung lyrics are sent, otherwise the track keeps its current mode.
`wait`	No	true = waits for the track (up to 10 min). false = only puts it in the queue and answers at once with the jobId: for several tracks, queue them all with wait=false (the account generates one at a time, the rest wait their turn) and check them with job_status.
`voice`	No	Sung tracks: who sings (gender), how deep (timbre) and up to 2 singing styles, written at the end of the prompt. Omitted: the model picks.
`genres`	No	Musical style (the site's "Estilo musical"): ONE genre as a one-item list. Its words are written at the start of the prompt (empty = only your prompt).
`lyrics`	No	The lyrics, one line per row, parts marked with [Verse], [Chorus], [Bridge]... Only with instrumental=false.
`prompt`	No	How it sounds, sent to the model as is: English tags (genre, mood, instruments, tempo, production).
`quality`	No	draft (fast and cheap, to test the idea), good, high (the approved default), max (large model; may be unavailable). The price per minute follows the level.
`event_id`	Yes	An event in the Music tab (root folder of kind "music", its subfolders or entities).
`language`	No	Language of the lyrics.
`key_scale`	No	Compose ("Tom"): the key, e.g. "A minor".
`auto_choose`	No
`vocal_level`	No	Sung tracks: the voice behind the band (back), even (balanced, default, adds nothing) or up front (front); written at the end of the prompt.
`duration_sec`	No	Whole seconds, 10 to 240 (4 min). The user's plan may allow less: the server refuses a longer track.
`instrumental`	No	false = sung, with the lyrics below.
`time_signature`	No	Compose ("Compasso"): beats per bar (2, 3 = waltz, 4 = most music, 6 = compound like 6/8).

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.6/5.0

Behavior4/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 does well: it discloses credit spend, refusal without approval, the 10-minute wait ceiling with a fallback message, one-at-a-time account-level generation, the rights-notice prerequisite, and the auto-choose mutation plus its opt-out. It does not quantify cost per quality level or say what exactly is returned in the version object, which keeps it off a 5.

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 most consequential facts (one version, spends credits, approval gate) are front-loaded and there is little pure filler. It is dense and slightly long, with the duration limit repeated against the schema, but every sentence contributes operational information.

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 17-parameter, nested-object, credit-spending generation tool with an output schema, the description covers cost gating, latency, queueing, prerequisites and the chosen-version side effect. Nothing an agent needs to call it safely is missing, and return values are left to the output schema as expected.

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 94%, so the baseline is 3, but the description adds non-obvious semantics the schema cannot: the prompt is passed verbatim with no rewriting, genre words are prepended and voice/vocal_level appended, and the duration limit is account-bound. These injection rules materially change how an agent should compose a call.

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?

"Generates ONE version of a track for an event of the Music tab" gives a specific verb, resource, cardinality and target scope. It explicitly distinguishes itself from its closest sibling by noting the return shape is "like generate_sounds" and by routing queued jobs to job_status, so an agent can tell these apart without opening a 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?

It states the precondition (user must approve cost, see approve_spending), the first-use gate (accept the rights notice on the site), the batching strategy (queue several with wait=false, check job_status) and the default side effect (auto_choose becoming chosen when none exists). Explicit alternatives and when-not conditions are both present.

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?