Skip to main content
Glama

Gomo Sounds

Maximum refinement: the site's setup assistant

suggest_game_setup

Call it only after the USER picked "maximum refinement" and answered or confirmed the six fields. Make each field rich and concrete (the look and palette, every character and what it is made of, the mood, reference games), read from the project when you can, and review the result before showing it (see the QUALITY BAR in the instructions). The same assistant as the site's "I want maximum refinement": from the name and "what the game is like" (one line per field: Genre, World, Tone, Sound style, Camera, What's in the game) it writes the description, the sound direction (with the rules every sound follows) and the folders of each tab with the events this game needs, loop and duration decided. Nothing is created: show the result to the user, let them change it, then call create_game with name, engine, description, profile, sound_direction and these folders, with from_ai=true. Uses the account's AI quota (a few per minute).

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

Input Schema

NameRequiredDescriptionDefault
nameYes
rulesNoRules for every sound, one per line. Omitted: the site's default rules (same loudness, natural endings, no music or voice inside effects, dry sounds).'
scenesNoIn an engine project: the scenes that make noise (e.g. res://player/player.tscn, res://enemy/enemy.tscn), so the proposal follows the real game.
profileYesWhat the game is like, one line per field in the game's language, e.g. "Gênero: estratégia\nMundo: floresta viva\nTom: cartoon\nEstilo de som: seco, retrô\nCâmera: de cima\nO que tem no jogo: besouros, formigas, quartel". Fields: genre, world, tone, soundStyle, camera, contents.
languageNoThe game's language (folder and event names). Omitted: the account's.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/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 load and does disclose key traits: no side effects ("Nothing is created"), a prerequisite on user confirmation, a quality-review step before showing output, and a quota constraint ("a few per minute"). It also sketches what the response contains (description, sound direction, tab folders with events, loop and duration). What it doesn't state is failure behavior or what happens if the quota is exhausted.

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

Conciseness3/5

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

The call condition is front-loaded, which is correct, but the remaining text is a dense run-on with nested quotes and parentheticals ("(see the QUALITY BAR in the instructions)", repeated phrasing about the same site assistant) that make it harder to parse than needed. Information is valuable but the packaging is heavier than the content requires.

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

Completeness4/5

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

For a five-parameter generative tool with no output schema, this covers the essentials: inputs, prerequisite user state, non-destructiveness, quota cost, and the handoff to create_game. It stops short of describing the exact shape of the returned folders or how to handle partial/edited results.

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 the baseline is 3; the description adds real meaning by enumerating the six profile fields (Genre, World, Tone, Sound style, Camera, What's in the game) and instructing the agent to read from the project where possible, which motivates the scenes parameter. The rules parameter's default behavior is only covered by the schema, not the description.

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 states a specific verb and resource: from the name and a one-line-per-field profile it writes the game description, the sound direction with rules, and per-tab folders with the events each game needs. It explicitly contrasts with create_game ("Nothing is created"), so the agent can tell this apart from the sibling that actually persists a game.

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 gives an explicit precondition ("Call it only after the USER picked 'maximum refinement' and answered or confirmed the six fields") and an explicit follow-up path: show the result, let the user edit, then call create_game with name, engine, description, profile, sound_direction and these folders with from_ai=true. The when-to-use and what-to-do-next are both named, including the alternative tool.

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