Gomo Sounds

Generate variations

generate_sounds

Generates sound variations for an event (spends credits: refused until the user approved the cost in the conversation, see approve_spending). Without prompt/duration/loop, uses the event's. LOOP OR ONE-SHOT, decided from what the sound is in the game: a LOOP is anything that lasts while something keeps happening and the game plays on repeat: ambience and weather, music, engines and machines, fire burning, flowing water, AND movement cycles: footsteps, walking, running, crawling, galloping, sustained wing flapping, rolling. Footsteps are a walk cycle with several steps (6-10 s), never a single step. A ONE-SHOT is one discrete action: hit, swing, click, cry, death, explosion, door, item, sting. DURATION: one-shots at least 2 s even for a tiny click, since shorter clips come out thin (hits, clicks and swings 2 s; cries, deaths, collapses and stings 3-5 s); movement loops 6-10 s; ambience, engine and fire loops 10-16 s. A music TRACK (Music folder) is not a sound effect: it is generated with generate_music and lasts up to the user's plan limit (generate_music duration_sec says it), usually 1-3 min for a theme and 30-60 s for a short loop. The server refuses one-shots under 2 s and loops under 6 s. COST = seconds rounded up × the account price per second (creditsPerSecond in list_games) × variations. The request can be in any language: the AI understands it and describes the sound for the generator (exact=true: translate only, literal). Returns the new variations (each with its editor link), the event page (url) and the game's studio (studioUrl). The game only plays chosen sounds: if the event has none yet, ALL the new variations become chosen and the game picks one at random (auto_choose=false turns this off; voice lines are never chosen automatically, generate them with generate_voice); an existing choice doesn't change. To switch or trim the list, use choose_sound.

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_sounds"
  }
}

Input Schema

Name	Required	Description
`loop`	No	true for anything continuous the game repeats (ambience, music, engines, fire, footsteps, running, flapping). Saved on the event.
`exact`	No	true = literal mode: only translates to English, without the AI filling out the description.
`prompt`	No	Description of the sound, preferably in English.
`channels`	No	Audio channels. auto (default): mono for everything the game positions (footsteps, hits, creatures, interface), stereo for Ambience backgrounds and for music in any folder. stereo: for a sound that does not come from a spot on the map (a sting, a screen whoosh). The choice is saved on the event.
`event_id`	Yes
`variations`	No	If omitted: 1 for a looping sound (ambience), 3 for everything else.
`auto_choose`	No
`duration_sec`	No	One-shot at least 2 s; movement loops 6-10 s; ambience 10-16 s. A music track is generate_music, not this.

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

Behavior3/5

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

Very strong disclosure beyond the near-empty annotations: it states that credits are spent and the call is refused without prior cost approval, that the server rejects one-shots under 2 s and loops under 6 s, and that existing event choices are never overwritten while an unchosen event adopts all new variations. The cost formula (seconds rounded up × creditsPerSecond from list_games × variations) and the note that voice lines are never auto-chosen are exactly the kind of operational context annotations cannot carry.

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?

Front-loaded with purpose, cost gate, then decisions, which is the right order. It is dense and occasionally run-on with heavy capitalization, and the duration guidance is partly duplicated between the prose table and the duration_sec description, but given the branching rules there is little that could be cut without losing decision-relevant 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?

Despite 8 parameters, a credit-spending mutation and server-side validation rules, nothing an agent needs to call this correctly is missing: sound-type classification, duration bounds per category, cost, refusal conditions, return shape and post-call choice behaviour are all covered. An output schema exists, so the return-value sentence is a bonus rather than a gap-filler.

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?

Adds real meaning beyond the 75%-covered schema: what happens when prompt/duration/loop are omitted, what variations defaults to per sound type, what exact=true does to translation, and default behaviour of auto_choose. It even explains why duration minimums exist (short clips come out thin), which no schema field says.

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?

Opens with a specific verb and resource ("Generates sound variations for an event") and immediately differentiates itself from siblings by naming generate_music, generate_voice and choose_sound in contrasting roles. An agent can place this tool without reading any other definition.

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 routing rules: use generate_music for music tracks, generate_voice for voice lines, choose_sound to switch or trim choices, approve_spending before credits are spent. The loop vs one-shot decision is given as a concrete decision procedure with enumerated examples on both sides, so the agent does not have to infer the rule.

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?