Godot MCP Bridge

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

With no annotations provided, the description bears full responsibility for behavioral disclosure. It mentions 'reconnect bridge' but doesn't explain what state is preserved/destroyed during reload, whether this operation is idempotent, what happens if the plugin fails to reload, or the impact on the running game/editor. 'Compatibility tool' hints at legacy/edge-case usage without explaining the implications.

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 compact (one sentence plus a tag) and front-loaded with the primary action. However, the brevity crosses into underspecification given the complete lack of schema documentation. The '(Compatibility tool)' tag earns its place but could be more descriptive.

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 zero schema description coverage, no annotations, and no output schema, the description needs to be substantially more informative. It omits critical details about parameter semantics, return values, side effects, and sibling differentiation, leaving the agent with minimal actionable context beyond the tool name itself.

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?

The input schema has 0% description coverage for its two parameters ('timeoutMs' and 'autoConnect'). The description fails entirely to compensate, providing no information about what the timeout applies to (connection attempt? plugin load?), the units (milliseconds implied by 'Ms' suffix but not confirmed), or the behavior of the autoConnect flag.

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 ('Reload plugin') and mentions reconnecting a 'bridge', but 'bridge' is ambiguous (MCP bridge? Godot editor bridge?). It fails to distinguish clearly from sibling tools like 'reload_project' or connection management tools ('godot_connect'). The '(Compatibility tool)' tag adds some context but doesn't fully clarify scope.

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?

The parenthetical '(Compatibility tool)' implies a specific use case but provides no explicit guidance on when to use this versus 'reload_project' or other connection-related tools. No prerequisites, error conditions, or alternatives are mentioned.

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