Godot MCP Server

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

Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false. The description adds valuable behavioral context beyond annotations: it specifies the default behavior (active scene if no path given), recursion depth limits (default: 10, max: 50), and the return structure (nested node tree with specific fields). No contradiction with annotations exists.

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 efficiently structured with a clear opening sentence stating the purpose, followed by organized sections (Args, Returns, Examples). Every sentence adds value: the first defines scope, Args clarifies parameters, Returns describes output, and Examples provides usage guidance. No wasted words.

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 tool's moderate complexity (2 optional parameters, read-only operation), the description provides complete context: purpose, parameter usage, return structure, and examples. With annotations covering safety aspects and 100% schema coverage for inputs, the description fills all necessary gaps despite no output schema.

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?

Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description adds minimal value beyond the schema: it restates the optional nature of scene_path and depth's default/max values, but doesn't provide additional semantic context about parameter interactions or edge cases.

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 clearly states the specific action ('Returns the full node hierarchy') and resource ('of the specified scene'), distinguishing it from siblings like godot_get_node (which gets a single node) or godot_list_scenes (which lists scene files). The verb 'returns' and scope 'full node hierarchy' precisely define the tool's function.

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 description explicitly provides usage guidance with 'Use when' examples ('Show me the scene tree' or 'What nodes are in res://player.tscn?'), giving clear context for when to invoke this tool. It also distinguishes from alternatives by specifying it returns the 'full node hierarchy' rather than individual nodes or scene lists.

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