Gomo Sounds

Godot plugin: install kit

godot_plugin

Read-only

The kit to put the Gomo Sounds plugin into the user's Godot project, with the rules to do it without breaking anything, AND the version check: call it only when the user chose the plugin (it is optional: the conversation alone also works) or asks for it, and ALWAYS before telling the user to Sync or to Install sounds. Returns the current version, the versions the plugin of this account has reported (installed) with the verdict (status: up_to_date, outdated, blocked, unknown), the .zip link, the folder it goes to, whether the plan allows connecting it, and the steps: YOU download and extract it (after the user says yes), the USER enables it in Godot and connects (once per computer); then you offer to bring the project scenes in as entities (asking about images) and confirm with game_scenes. Also compare with addons/gomo_sounds/plugin.cfg in the project when you can read it. Never delete the addons folder or any project file.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "godot_plugin"
  }
}

Input Schema

Name	Required	Description	Default
`game_id`	No	The game the project will link to (its name is what the user picks in the dock). Optional.

Output Schema

Name	Required	Description	Default
`game`	Yes
`steps`	Yes
`folder`	Yes
`planOk`	Yes
`status`	Yes
`docsUrl`	Yes
`minimum`	Yes
`version`	Yes
`plansUrl`	Yes
`installed`	Yes
`downloadUrl`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 11, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Annotations only supply readOnlyHint, so the description carries nearly the full burden and does so well: it enumerates the return payload (current version, reported versions with status verdicts up_to_date/outdated/blocked/unknown, .zip link, target folder, plan eligibility), the division of labor (agent downloads/extracts after user consent; user enables and connects once per computer), the plugin.cfg comparison, and a hard safety rule (never delete the addons folder or project files). This also clarifies why readOnlyHint is consistent despite the 'install' framing.

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 single run-on block with ALL-CAPS emphasis and many unrelated clauses (version check, install steps, entity import offer, safety bans) chained together. Every fact is arguably relevant, yet the lack of structure makes it harder to scan than it needs to be.

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 one-parameter install-helper tool with an output schema, the description covers prerequisites (user must have chosen the plugin), ordering, consent requirements, what gets returned, who performs each step, and destructive-action prohibitions. Nothing an agent needs in order to call it correctly or act on the result is missing.

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?

There is one optional parameter with 100% schema description coverage, so the schema already explains that game_id is the game the project links to and that its name is what the user picks in the dock. The description adds no further meaning about game_id — e.g. what happens if it is omitted, or how it affects the returned zip/folder. Baseline 3 is appropriate given the schema does the work.

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 description names a concrete resource (the Gomo Sounds Godot plugin) and concrete operations (install kit, version check), so an agent can tell what it delivers. It also references the downstream sibling game_scenes and the Sync/Install moments. It loses a point because the purpose sentence bundles two things (install kit + version check) into one long clause, so the primary function takes a moment to extract.

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?

Explicit when-to-use and when-not-to-use: call it only when the user chose the plugin (noting the conversation alone also works, i.e. the plugin is optional) or asks for it. It also gives an ordering constraint — ALWAYS before telling the user to Sync or Install sounds — which is exactly the kind of sequencing guidance an agent needs. Alternatives and exclusions are both present.

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?