Gomo Sounds

New game

create_game

Creates a game in the account. It's the FIRST step: without a game there are no folders or entities. A new project ALWAYS gets a new game: never reuse an existing game because its name matches the project. If the account has a game with the same or a similar name, the call is refused with the list: ask the user whether to use that game or create a new one (suggest a different name when it is the same, so the user can tell them apart in the lists), and only call again with new_game_confirmed=true after they say so. It's born with the root folders Ambience, Sound effects, Interface, Voices and Music (named in the game's language; template adds ready-made folders by genre). sound_direction is the style that EVERY generation in the game follows (e.g. 'cartoon, dry, no reverb'); profile describes the game (genre, camera, world, tone). language sets the language of the born folders and events (the root folders and the starter events, and the template's folders); set it to the game's own language, which is usually the one the user is writing in. Omit it to follow the account's saved language. folders: the reviewed proposal from suggest_game_setup (each folder with its tab and events), created exactly like the site's "maximum refinement"; with from_ai=true the game gets no starter events (the proposal already covers the tabs). Engine godot: before touching the project, ask the user whether to bring the sounds with the plugin or only through the conversation (see the instructions). entities: the things of the game (player, enemies, items) with their events and scene path, created in the same call, so everything the user approved exists at once. kind: 'project' for anything that is not a game (a video, a podcast, an app, an ad...): the same screen and folders on the site, under Projects, with no engine and no plugin, and it never shows in Explore; omitted, a game. Returns the id, the game page (url: share it with the user), the entities and the folders created.

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>"
    },
    "name": "create_game"
  }
}

Input Schema

Name	Required	Description	Default
`kind`	No	project: not a game (video, podcast, app...). No engine, no plugin, no starter events.	game
`name`	Yes
`engine`	No		other
`folders`	No	The folders and events to create (the proposal from suggest_game_setup, as the user approved it). Replaces template.
`from_ai`	No	true when folders come from suggest_game_setup: no starter events on top (Wind, Rain, Click, Error).
`profile`	No
`entities`	No	The things of the game that make noise (player, enemies, items, projectiles), each with its own events, created in the same call. A folder the site assistant proposed for ONE thing (Player, Crab Enemy) goes here as an entity.
`language`	No
`template`	No		empty
`description`	No
`sound_direction`	No
`new_game_confirmed`	No	true only after the user said, in this conversation, to create a new game although the account has one with the same or a similar name.

Output Schema

Name	Required	Description	Default
`id`	Yes
`url`	Yes
`name`	Yes
`folders`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 11, 2026

TDQS

A4.9/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 does it well: the duplicate-name refusal behavior with the returned list, the confirmation gate, the folder tree the game is born with, from_ai suppressing starter events, on-disk/engine sync via external_id, and kind='project' never appearing in Explore. These are non-obvious side effects an agent could not infer from the schema.

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 critical constraint (never reuse a game, confirm before retrying) is front-loaded ahead of the details, which is the right ordering. It is dense and some sentences pack multiple rules together (engine/folders/from_ai), which taxes readability slightly, but nearly every clause carries 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 12-parameter creation tool with nested folders and entities, the description covers inputs, creation side effects, refusal paths, and return values (id, game page url to share, entities and folders created), the last of which is reinforced by the output schema. Nothing an agent needs to call it correctly 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?

Schema coverage is only 42% across 12 parameters, yet the description supplies the missing meaning: sound_direction as a style applied to every generation, profile as the game's descriptive context, language controlling born folders and starter events with the omit-to-follow-account rule, kind distinguishing projects, template adding genre folders, and entities created in the same call. This meaningfully exceeds what the schema documents.

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+resource ('Creates a game in the account') and immediately establishes scope: it is the FIRST step, without which folders and entities cannot exist. It also distinguishes itself from create_folder/create_entity by explaining the dependency, so an agent knows this must come first.

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?

Gives explicit when-to-use rules and hard exclusions: never reuse an existing game because the name matches, handle the duplicate-name refusal by asking the user, and only retry with new_game_confirmed=true after confirmation. It also names prerequisites and alternatives, e.g. pulling folders from suggest_game_setup and asking about the Godot plugin path before touching the project.

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?