Gomo Sounds

Create several tracks

create_tracks

Creates several tracks at once in the game's Music folder (created with the first track) or in one of its subfolders: free, nothing is generated. Each track has a name (what it is in the game: Main theme, Forest, Boss fight), a prompt (how it sounds, sent to the model as is: English comma-separated tags such as genre, mood, instruments, tempo), a duration, loop AND the same form as generate_music, saved on the track so the site shows it before generating: genres (musical style), bpm, key_scale, time_signature, mode, instrumental/lyrics/language, vocal_level, voice, quality (a genre and a voice are also written into the prompt as words, as the site does). A name that already exists there is UPDATED with what you send (prompt, duration, loop and the form; what you omit stays): use it to fill or fix existing tracks. Returns each track with its page and the cost of generating it, plus the total per quality level: show the user the plan and the total, and after their yes generate them (generate_music with wait=false for each, then job_status).

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

Input Schema

Name	Required	Description
`tracks`	Yes
`game_id`	Yes
`folder_id`	No	A subfolder of the Music folder (create_folder with section "music"). Omitted: the Music folder itself.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 11, 2026

TDQS

A4.4/5.0

Behavior5/5

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

With only a title annotation and no readOnly/destructive hints, the description carries the full behavioral burden and does so well. It discloses that nothing is generated at creation, that the Music folder is created with the first track, that an existing name is UPDATED with merge semantics ('what you omit stays'), and that the response includes per-track cost plus totals per quality. These are exactly the mutation and financial side effects an agent needs before calling.

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 purpose is front-loaded, but the body is a dense, run-on sentence with heavy parenthetical nesting ('a name (...), a prompt (...), a duration, loop AND the same form as generate_music, saved on the track so the site shows it...'). The information mostly earns its place for such a complex tool, but bulleted or multi-sentence structure would make it far easier to parse.

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 complex planning/mutation tool with no output schema, the description covers the important missing pieces: what is returned ('each track with its page and the cost of generating it, plus the total per quality level') and the required next steps in the workflow. It does not discuss permission requirements or error conditions (e.g., the plan duration limit), though the nested schema covers several of those constraints.

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?

Top-level schema coverage is 33% (game_id has no description), but the nested track schema is richly documented and the description adds meaningful semantics beyond it: name is 'what it is in the game,' prompt is sent verbatim as English comma-separated tags, genres are written at the start of the prompt, and voice is written at the end. It also explains that the same form fields as generate_music are stored on the track for site preview. Some top-level meaning (game_id, folder_id relationship) is left to the schema, so it is strong but not exhaustive.

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 opening sentence gives a specific verb and resource ('Creates several tracks at once in the game's Music folder') plus scope ('or in one of its subfolders') and the key distinction from siblings: 'free, nothing is generated.' An agent can immediately tell this apart from generate_music, which actually produces audio.

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?

The description gives a clear workflow: show the plan and total, get user approval, then call generate_music with wait=false for each track and poll with job_status. It also states a second use case explicitly ('use it to fill or fix existing tracks' when a name already exists). It does not say when not to use it (e.g., for a single track), but the alternatives and conditions are named.

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?