Skip to main content
Glama

Gomo Sounds

New sound event

create_event

Adds an event to an entity OR to a folder. The event name is WHAT happens (Move, Attack, Die, Land, Click, Undo, Level complete), never 'Sound' or 'Som'. A folder event applies to all entities inside it (e.g. 'Select' once for all units); an entity can have its own with the same name, which wins. Game actions with no owner (Undo, Victory, Level complete) go as events of the Interface folder. Ambience (wind, rain, forest) goes in the Ambience folder ("Ambiente" in Portuguese games). Always say whether it is a loop. 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. Omit duration_sec and a loop is born at 12 s, a one-shot at 2 s. A TRACK in the Music folder follows the music limits instead (a longer prompt, duration up to the user's plan; see duration_sec; omitted: 1 min or the plan limit) and takes the same form as generate_music (genres, bpm, key_scale, time_signature...), saved on it so the site shows it before generating; the form is ignored for other sounds. Several tracks: create_tracks. Generate it with generate_music. On the site an event is a SOUND card (its variations are the versions): call it a sound when talking to the user.

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": {
      "name": "<name>",
      "prompt": "<prompt>",
      "loop": "<loop>"
    },
    "name": "create_event"
  }
}

Input Schema

NameRequiredDescriptionDefault
bpmNoCompose ("Andamento"): tempo in beats per minute (60 to 180 sound best).
loopYesRequired. true for anything continuous the game repeats: ambience, music, engines, fire, water and movement cycles (footsteps, running, flapping). false for one discrete action (hit, click, cry, death).
modeNodescribe = 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.
nameYes
voiceNoSung tracks: who sings (gender), how deep (timbre) and up to 2 singing styles, written at the end of the prompt. Omitted: the model picks.
genresNoMusical 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).
lyricsNoThe lyrics, one line per row, parts marked with [Verse], [Chorus], [Bridge]... Only with instrumental=false.
promptYesUp to 450 characters for a sound; up to 512 for a track in the Music folder.
qualityNodraft (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.
languageNoLanguage of the lyrics.
entity_idNo
folder_idNo
key_scaleNoCompose ("Tom"): the key, e.g. "A minor".
vocal_levelNoSung tracks: the voice behind the band (back), even (balanced, default, adds nothing) or up front (front); written at the end of the prompt.
duration_secNoSounds (up to 30 s): one-shot at least 2 s (hits 2 s, cries and deaths 3-5 s); movement loops like footsteps 6-10 s; ambience 10-16 s. Omitted: loop 12 s, one-shot 2 s. A track in the Music folder: Whole seconds, 10 to 240 (4 min). The user's plan may allow less: the server refuses a longer track. Omitted: 1 min (or the plan limit, if lower).
instrumentalNofalse = sung, with the lyrics below.
time_signatureNoCompose ("Compasso"): beats per bar (2, 3 = waltz, 4 = most music, 6 = compound like 6/8).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.4/5.0
Behavior3/5

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

Annotations supply only a title, so the description carries the full burden of disclosure, and it does add real behavioral context: server-side validation refusals (one-shots under 2 s, loops under 6 s), default durations when duration_sec is omitted, the cost formula, and that the music form is persisted on the track while ignored for other sounds. However, it never describes what the call returns (no output schema exists) or what permissions, entity, or folder state are required, which leaves a significant gap for a mutation tool with 17 parameters.

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

Conciseness2/5

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

The purpose is front-loaded, but the body is an unstructured wall of prose with heavy ALL-CAPS emphasis and clear repetition. The Music folder / generate_music / duration-limit material appears twice in near-identical form, and the duration guidance is restated in both the description and the schema. Several sentences do not earn their place in the tool definition itself.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex 17-parameter mutation tool with no output schema, the description covers the hard parts well: loop classification, duration expectations, cost, folder routing, and the music-track escape hatch. It is still incomplete on the mechanics that matter for invocation, namely whether entity_id or folder_id is required and mutually exclusive, and what the tool returns after creating the event.

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 coverage is 82%, so the schema already documents most parameters, and the baseline of 3 applies. The description adds genuine meaning for loop (the loop-versus-one-shot decision rule with concrete examples), duration_sec (per-type duration targets), and mode/genres/voice (ignored for non-music sounds), which goes beyond the schema. It says nothing about entity_id or folder_id, which the schema also leaves undescribed, and it references 'variations' as a cost multiplier despite no such parameter existing.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence gives a specific verb and resource: it adds an event to an entity or to a folder, and later clarifies that on the site an event is a SOUND card. It also distinguishes itself from generate_music and create_tracks for Music folder tracks. The core statement is clear, but it is buried under a large amount of naming and duration doctrine that an agent must wade through to reach it.

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

Usage Guidelines4/5

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

It gives explicit routing rules: game actions with no owner (Undo, Victory, Level complete) go to the Interface folder, ambience goes to the Ambience folder, Music folder tracks are generated with generate_music, and multiple tracks use create_tracks. What it lacks is a clean when-not statement and any statement about the entity_id versus folder_id choice or the prerequisites for calling it.

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.

Resources