Gomo Sounds

New voice line

create_voice

Creates ONE voice sound (a character line) in a game, in its Voices folder ("Vozes" in Portuguese games), created with the first line. Free: nothing is generated yet. name = what the game calls it (e.g. "Victory line", "Groovy"); text = exactly what the character says, as written (up to maxChars of list_voices; split longer speeches into several lines). Pick the voice, register and emotion from list_voices; language defaults to the game's. Returns the sound page (url) and the cost per version; then ask the user and generate it with generate_voice.

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": {
      "game_id": "<game_id>",
      "name": "<name>",
      "text": "<text>"
    },
    "name": "create_voice"
  }
}

Input Schema

Name	Required	Description
`name`	Yes	The sound name the game calls (e.g. "Victory line").
`text`	Yes	The exact line the character says.
`emotion`	No	calmo (calm), normal (the default) or intenso (intense).
`game_id`	Yes
`language`	No	Language of the line. Omitted: the game's language.
`register`	No	coloquial (loose, the default), conversa (conversational) or formal (read). A voice without the register speaks formal.
`voice_id`	No	A voice id from list_voices. Omitted: the first voice of the library.

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 load and does disclose key traits: creation is free with nothing generated yet, the sound is created together with its first line, and the response returns the sound page url and cost per version. It stops short of stating permission requirements or what happens on duplicate names, but the workflow-critical behavior is covered.

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-loads the core action and the free/generate distinction, then packs parameters and next steps efficiently. It is dense, with stacked parentheticals and the Portuguese "Vozes" aside, but nearly every clause carries actionable 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?

With 7 parameters, no output schema and no rich annotations, the description still covers the return payload (url and cost per version), enum defaults, the required handoff to generate_voice, and the free-vs-paid boundary. 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.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is already 86%, yet the description adds real meaning: name is "what the game calls it" with examples, text must be verbatim dialogue bounded by maxChars from list_voices rather than just the schema's 500, and the fallback defaults for voice_id and language are spelled out. The split-longer-speeches instruction is guidance the schema cannot express.

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?

States a specific verb and resource ("Creates ONE voice sound (a character line) in a game") plus its placement in the Voices folder and the free/non-generating nature of the call, which cleanly separates it from generate_voice. An agent can distinguish it from siblings without opening the 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?

Explicitly tells the agent to pick voice/register/emotion from list_voices, that language defaults to the game's, and that after creation it should ask the user and then call generate_voice. It also flags the line-splitting rule instead of leaving the agent to guess when text is too long.

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?