Parse a .tscn file and return its node tree as JSON, with each node's name, type, parent path, and properties to inspect Godot scene structure.
Parses a .tscn file and returns its node tree as JSON (name, type, parent path, properties).
| Name | Required | Description | Default |
|---|---|---|---|
| scene_path | Yes | Path to the .tscn file, relative to project_path or absolute | |
| project_path | Yes |
Changes observed during successful MCP inspections.
v0.2.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It does indicate the return value and fields ('name, type, parent path, properties'), which is useful. However, it does not explicitly state that the tool is read-only, how invalid or missing files are handled, or whether it affects the editor state.
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 a single front-loaded sentence that communicates the core action, target file type, and return structure without any filler. Every element earns its place.
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?
For a tool with no output schema, no annotations, and a partially documented input schema, the description provides the output shape but omits important operational context like project_path semantics, failure modes, and when to prefer this over editor-based siblings. It is adequate but not fully complete.
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 coverage is only 50%: scene_path is described, but project_path has no schema description. The description does not add any parameter-level meaning beyond the schema, so it fails to compensate for the undocumented project_path parameter, leaving its role and relationship to scene_path mostly implicit.
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 names a specific verb ('Parses'), a specific resource ('.tscn file'), and the output format (JSON with name, type, parent path, properties). This clearly distinguishes it from siblings like editor_get_scene_tree, which operates on the editor's current scene, or read_script, which handles scripts.
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 explicit guidance is given about when to use this tool over alternatives such as editor_get_scene_tree, editor_open_scene, or list_project. The description only states what the tool does; the agent must infer usage from the phrase 'Parses a .tscn file' without any comparison or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.