godot_open_scene

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

Annotations declare readOnlyHint=false, indicating this is a state-mutating operation, and destructiveHint=false, indicating it is non-destructive. The description adds minimal context beyond this — it notes the action happens 'in the Godot Editor workspace', implying a workspace state change, but does not disclose what happens on open (e.g., whether it replaces the current scene, prompts about unsaved changes, or fails on missing paths). With annotations carrying the safety profile, the description adds some but not rich context, meriting a 3.

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?

A single, front-loaded sentence with no filler — every word earns its place. It is efficient and readable. It is not penalized as under-specification here since brevity is assessed separately from completeness on other dimensions.

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 mutating editor operation, the description is thin: it omits behavioral effects on the current workspace, error/edge-case handling, and the role of the response_format output schema. Although an output schema exists, the description provides no operational context an agent would need to reliably invoke the tool and interpret the outcome, leaving the definition incomplete for its complexity.

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 reported at 0%, so the description must carry the burden of explaining parameters. The description only implies scene_path should be a .tscn resource, which is a minor addition. It offers nothing about the response_format parameter or path requirements. Given low schema coverage, the description does not adequately compensate for the undocumented parameters.

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 uses a specific verb ('Open') with a concrete resource ('scene file (.tscn)') and target ('Godot Editor workspace'), making the operation clear. It doesn't explicitly name sibling tools (godot_create_scene, godot_instantiate_scene, godot_save_scene), but the verb+resource combination is specific enough for an agent to distinguish 'open existing scene' from create/instantiate/save operations.

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 closely related siblings such as godot_create_scene, godot_instantiate_scene, godot_save_scene, or godot_diff_scene. There is no mention of prerequisites (e.g., the scene must already exist as a project resource) or exclusions. An agent must infer the appropriate scenario from the tool name alone.

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