Godot MCP Bridge

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

With no annotations provided, the description carries the full burden of behavioral disclosure but offers almost none. It does not state whether the override affects the current session only or persists to disk, whether it requires an open scene, or what happens if the constant doesn't exist. The 'compatibility' label hints at special behavior but is not elaborated upon.

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

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

The description is extremely brief (four words plus a parenthetical), avoiding verbosity, but this brevity results in underspecification. The '(Compatibility tool)' tag is front-loaded but unexplained, wasting potential information density. Every sentence should earn its place; here, the parenthetical raises questions without answering them.

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

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

Given the lack of annotations, output schema, and parameter descriptions (0% coverage), the description is insufficient for an agent to use the tool correctly. It fails to explain the additionalProperties pattern essential for passing the constant name and value, leaving a critical gap in the absence of schema documentation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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

With 0% schema description coverage, the description must compensate but fails entirely. The schema defines timeoutMs and autoConnect (likely connection parameters) and allows additionalProperties: true, suggesting the actual theme constant name/value pairs are passed dynamically. The description gives no hint about this critical usage pattern, nor does it explain the two defined parameters' purposes.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the core action ('Set theme constant override') using a specific verb and resource type, which implicitly distinguishes it from siblings like set_theme_color or set_theme_font_size. However, it fails to explain what constitutes a 'theme constant' in this context (Godot integer constants vs. other theme properties) or what 'override' means (temporary vs. persistent). The '(Compatibility tool)' parenthetical is cryptic and unexplained, reducing clarity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus the more specific sibling tools (set_theme_color, set_theme_font_size, set_theme_stylebox). The description does not explain the 'compatibility' designation—whether this is deprecated, legacy, or serves a specific niche use case—leaving agents without selection criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.