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

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds real behavioral value beyond that: it discloses that the scene file is saved (persistence mutation) and that property strings beginning with res:// are resolved as resources, neither of which is in the structured fields. It omits failure behavior (missing scene, name collision), keeping it out of 5 territory.

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?

Two sentences, front-loaded with the action, with the example packed inline rather than expanded into a block. Every clause earns its place by clarifying either persistence or value syntax.

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 6-parameter mutation tool with no output schema, it covers the action, the save behavior, and the non-obvious value semantics; parent path and project defaults are handled by the schema. It leaves undefined what happens when the scene path is invalid or the node name already exists, a modest gap.

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 baseline would be 3, but the description adds syntax beyond the schema: the propertyName→value shape with an inline nested example, plus the res:// resource-loading rule for string values. That is genuine semantic enrichment the schema's terse "Property values to set on the new node" does not provide.

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?

States a specific verb+resource ("Add a node to an existing scene") and adds the persistence side effect ("and save it"), which an agent needs. It does not explicitly distinguish itself from siblings like create_scene or load_sprite, so it stops short of 5.

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 phrase "existing scene" implies a precondition (the scene must already exist), which is useful usage context, but there is no explicit when-to-use/when-not guidance or named alternative such as create_scene for new scenes. Usage is implied rather than stated.

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

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

With readOnlyHint/destructiveHint=false already covering the safety profile, the description adds real operational context the annotations do not: Movie Maker mode, a game window briefly appearing, and the image being written to a temp folder. That window/side-effect disclosure is exactly the extra context an agent needs, though it doesn't say how long capture can block or whether the run is torn down afterward.

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?

Two sentences with no filler; the core action and its purpose are front-loaded, with mechanism and side effects trailing. Every clause 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?

With no output schema, the description carries the return-value burden and does say it returns the rendered screenshot plus a temp-folder copy. It stops short of saying in what form the image is returned (inline image vs. file path), which is the one thing an agent might still need to know.

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 scene, seconds, resolution and projectPath with defaults and bounds. The description only loosely echoes two of them ("or one scene", "for a moment") without adding syntax or format detail beyond the schema, so the baseline 3 applies.

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?

"Run the game (or one scene) for a moment and return a screenshot of what it renders" gives a specific verb (run/capture) and resource (screenshot of rendered scene), and the Movie Maker mechanism makes the behavior concrete. It is clearly distinct in function from run_project, but it never names that sibling, so the differentiation is implicit rather than explicit.

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?

"So you can see the result of your changes" implies the use case (visual verification after edits) but states no explicit when-to-use rule, no exclusions, and no pointer to run_project as the non-capturing alternative. Usage is inferable but not spelled out.

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

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

Annotations already establish the harmless read-only profile, yet the description adds real value: it uses the real Godot engine, reports file+line for parse/compile errors, and does not launch the game. This goes meaningfully beyond the safety hints, though it omits what success/failure output looks like.

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?

Three tight sentences, front-loaded with the core behavior and scoped default. Every sentence carries distinct information with no filler.

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 low-complexity, read-only tool with no output schema, the description covers the essential operating model (real engine, error reporting, no game launch, default scope). It could note how failures surface or what counts as success, but nothing critical for correct invocation is missing.

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 100%, so both parameters are already documented. The description's 'checks every script in the project unless paths are given' merely restates the schema's default for paths, adding no syntax or format detail. Baseline 3 applies when the schema does the heavy lifting.

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?

States a specific verb (compile/check) and resource (GDScript files), and explicitly distinguishes itself from runtime siblings by clarifying it works 'without launching the game.' An agent can separate it from run_project/launch_editor without opening any schema.

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?

Gives clear triggering context ('Run this after editing .gd files') and the scoping condition ('every script unless paths are given'). It does not explicitly name the runtime alternatives it replaces, but the 'without launching the game' clause implies the boundary.

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

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

Annotations already establish write, non-destructive, non-open-world behavior, so the safety profile is covered. The description adds that a .tscn is written with a typed root node, but omits key behavior such as what happens if scenePath already exists (overwrite vs. error) or whether the parent directory must exist.

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?

One front-loaded sentence with zero waste that states the action, artifact, and result in a single pass.

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?

Adequate for a simple file-creation tool whose params are fully documented, but with no output schema the description should clarify collision/overwrite behavior and what the call returns. A create-and-write tool leaves that gap unaddressed.

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 100%, so the schema already documents scenePath, projectPath, and rootNodeType with examples and defaults. The description only alludes to the root node type, adding nothing beyond the schema; baseline 3 applies.

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?

Specific verb (Create) plus resource (.tscn scene file) with a clarifying detail about the root node type. An agent can distinguish it from mutation siblings like add_node or save_scene, though no sibling is named explicitly.

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 when-to-use guidance and no mention of alternatives such as save_scene (persisting an existing scene) or add_node (mutating one). The agent must infer the workflow from the name alone.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=false, so the mutation/safety profile is covered. The description adds nothing beyond that: it doesn't say whether an existing file at outputPath is overwritten, whether the editor must be running, or whether the source scene is modified.

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 zero filler; every word carries information about the operation, the input and the output artifact.

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 no output schema, the description should ideally state the write semantics (file creation/overwrite at outputPath) and whether the operation touches the source scene. It is adequate for identifying the tool but thin on the behavioral details an agent needs before invoking a file-writing operation.

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 all four parameters (including the meshItemNames filter and the projectPath default) are already documented in the schema. The description contributes no additional parameter meaning, which is the expected baseline when the schema does the work.

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 ("Export"), a specific resource ("meshes in a 3D scene") and the output artifact ("a MeshLibrary resource for GridMap"). No sibling tool in the list overlaps with this job, so no explicit differentiation is needed, but it also doesn't need to say more.

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?

"for GridMap" is the only hint of when this tool is appropriate; there is no statement of prerequisites, when-not-to-use, or what alternative to pick (e.g., save_scene). An agent must infer the use case from the resource format alone.

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

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

Annotations already establish read-only, non-destructive, closed-world behavior. The description adds something the annotations cannot: the default is incremental/delta output ('only lines you have not seen yet'), which is a non-obvious stateful read semantic an agent must account for when deciding between repeated calls.

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?

Two short sentences, front-loaded with the tool's function followed immediately by its most surprising default. No filler or restatement of the title.

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?

With no output schema, the description correctly indicates what is returned (lines and errors). It stops short of covering edge cases such as behavior when no game is running or whether output is buffered/persisted, but for a simple read tool the coverage is close to sufficient.

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 100%, so tail, onlyNew, errorsOnly, and waitSeconds are fully documented in the schema, and the description's mention of the incremental default simply mirrors onlyNew. Baseline 3 is appropriate since the schema carries the parameter burden.

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?

States a specific verb and resource (read output and errors) and binds it to the originating sibling (run_project), so an agent knows exactly which process this reads from. It is clearly distinguishable from list_projects, get_scene_tree, capture_screenshot and the other siblings.

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 implies the correct usage window by naming run_project as the prerequisite, and states the default retrieval mode. It does not spell out what to do if the game is not running or contrast itself with a full-log alternative, but the context is clear enough to select the tool.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds genuine value by disclosing what information is surfaced (path, version, discovery method, other installs), which matters since there is no output schema to convey returns.

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 that states the primary purpose first and the supplementary detail ('any other Godot installs') second. No filler or redundancy.

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 zero-param, read-only diagnostic with annotations covering safety, the description supplies everything needed: what the tool does and what it returns. With no output schema, the enumeration of returned fields closes the gap fully.

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 tool takes no parameters, so the baseline is 4. There is nothing for the description to disambiguate, and the empty schema leaves no ambiguity to resolve.

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 a specific verb and resource ('Show which Godot executable this server uses') and enumerates the exact facts returned (path, version, how it was found, other installs). This is clearly distinct from all siblings, which deal with projects, scenes, and nodes rather than installation diagnostics.

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 implies the tool is used to inspect the server's Godot installation, but it gives no explicit when-to-use guidance and names no alternatives or conditions. For a zero-param diagnostic tool the implied usage is reasonably legible, but nothing is stated.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds the content inventory, but says nothing about behavior when projectPath is invalid, whether the listed scenes/scripts are truncated, or performance on large projects, which is the remaining useful ground.

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?

Two sentences, zero filler, with the resource and its contents front-loaded and the usage hint placed last. Every clause 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?

With no output schema, the description correctly takes on the burden of describing the return payload and does so field by field. The only gap is that it does not signal whether the scene/script lists are bounded or paged.

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?

There is only one optional parameter and schema description coverage is 100%, including the default-project fallback, so the schema carries the load. The description does not mention projectPath at all, adding nothing beyond the structured field.

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 ('Overview') and resource ('a Godot project') and enumerates exactly what is covered (name, main scene, renderer, autoloads, plugins, scenes/scripts). It is clearly broader than siblings like get_godot_version or get_scene_tree, but it never names those siblings to force the distinction.

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?

'A good first call' gives explicit positive usage context — an agent knows to reach for this during project discovery. There is no when-not guidance or named alternative, so it stops short of full routing instructions.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered; the description still adds genuine value by clarifying the operation is purely a file read that does not launch the engine, and by disclosing the breadth of the returned tree. It omits any note on behavior for large scenes or malformed paths.

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?

Two sentences, no waste, with the resource and returned content front-loaded and the read-only guarantee second. Every clause 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?

With read-only annotations covering the safety profile, a complete parameter schema, and the description enumerating the returned tree contents in lieu of an output schema, an agent has enough to call this correctly. Only rendering/format details of the tree output are left unspecified, which is minor.

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 scenePath, projectPath, and includeProperties are already fully documented in the schema. The description's content list does not map back to parameters such as includeProperties, so it adds no parameter-level meaning beyond the baseline.

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?

States a specific verb and resource ('Show the node tree of a .tscn scene') and enumerates exactly what the tree contains: names, types, scripts, instanced scenes, groups, signals. This clearly separates it from mutating siblings like create_scene, add_node, and save_scene.

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 clause 'Reads the file only; does not run Godot' implicitly tells the agent this is the static-inspection option and not a substitute for run_project or launch_editor. However, it never names an alternative tool or states a positive when-to-use condition (e.g. 'use before editing with add_node'), so usage is only implied.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds a useful version constraint (Godot 4.4+), implying UIDs are unavailable on older projects, but says nothing about failure modes such as files without a UID or nonexistent paths.

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 tight sentence with the core action front-loaded and the version caveat parenthesized at the end. No filler.

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 simple two-parameter read tool with full schema coverage and no output schema, the description is nearly sufficient; the return value is implied by 'uid://'. It stops short of noting behavior when a file has no UID or the version requirement is unmet.

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 both filePath and projectPath (including its default behavior) are already fully documented in the schema. The description adds no parameter-level detail beyond implying a file within a project; baseline 3 is appropriate.

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?

States a specific verb (get) and resource (uid:// of a file), which is unambiguous and distinct from siblings like update_project_uids. It does not explicitly contrast itself with that sibling, but the purpose is immediately clear.

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?

There is no when-to-use or when-not-to-use guidance, and no mention of the related update_project_uids tool or the prerequisite that the project must already use Godot 4.4+ UIDs. The agent must infer usage from the purpose alone.

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

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

Annotations declare readOnlyHint=true, openWorldHint=false, idempotentHint=false, and destructiveHint=false, so the agent knows the safety profile. The description adds that the editor opens in its own window for the user, which explains observable behavior beyond annotations, but it omits whether repeated calls spawn multiple windows (despite idempotentHint=false), what happens if the project path is invalid, or any auth/permission requirements.

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 efficient sentence with no waste, front-loading the verb and resource. Slightly terse given the mutation-like nature of opening an editor window, but appropriate size overall.

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 zero-required-param tool with full schema coverage, the description is adequate for basic invocation. However, given annotations (non-idempotent, readOnly) and an openWorldHint=false, a few more words about side effects (e.g., whether it blocks or returns immediately, whether multiple calls create multiple windows) would round it out.

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 both params (scenePath, projectPath) are already documented with optionality and defaults. The description adds no extra parameter syntax or format details beyond what the schema provides. Baseline 3 per rules when schema does the heavy lifting.

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?

States a specific verb and resource ('Open the Godot editor for the project') and adds clarifying scope ('in its own window, for the user'). Clear purpose, though it does not name or differentiate from siblings like run_project, which could be confused with launching the editor.

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?

Usage context is implied by the name and description ('for the user'), but there is no explicit when-to-use vs when-not-to-use guidance, nor any mention of alternatives such as run_project or capture_screenshot. Minimum viable.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds the useful qualification that only folders with project.godot qualify as results, but says nothing about depth default behavior, result count, or ordering. With annotations carrying the safety burden, a 3 is appropriate.

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 short sentence with the search scope front-loaded and the result definition in parentheses. 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?

For a simple, read-only, two-parameter discovery tool with full schema coverage and no output schema, the description supplies enough to call it correctly. The main omission is any hint about the practical difference between this and the other project-inspection siblings.

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 both parameters (directory, maxDepth) are already documented in the schema. The description's phrase 'under a folder' loosely restates the directory parameter without adding format or default details. Baseline 3 applies when the schema does the heavy lifting.

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?

States a specific verb (Find) plus resource (Godot projects) and even disambiguates what counts as a project — folders containing project.godot. It does not name or distinguish itself from siblings like get_project_info, so it falls short of a 5.

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 never says when to use this tool versus alternatives such as get_project_info or get_scene_tree, nor does it state prerequisites or when discovery is unnecessary. Usage is only loosely implied by 'under a folder'.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so safety is largely covered. The description adds real value by disclosing the persistence side effect ('save it'), which tells the agent the scene file is mutated, not just an in-memory node. It does not explain prerequisites (is the scene required to be open/loaded?) or failure behavior for invalid node types.

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 sentence that front-loads the action and resource, then appends the save side effect. No filler, no redundancy.

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 mutation tool with annotation coverage, no output schema and full schema descriptions, the description covers the core action and its persistence effect. It is still thin on prerequisites (scene/node/texture existence, required project context) and on error behavior when the target node isn't a supported type, which matters for a write operation.

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% and each parameter carries a concrete example ('root/Sprite2D', 'res://player.tscn'), so the schema does the heavy lifting. The description lists node types but adds no format or constraint detail beyond what the schema already gives; baseline 3 applies.

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?

States a specific verb+resource ('Set the texture of a Sprite2D, Sprite3D or TextureRect node') and enumerates the supported node types, so an agent immediately knows what operation and which targets are valid. It doesn't explicitly contrast with siblings like add_node or save_scene, but the operation is distinct enough that confusion is unlikely.

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?

Usage is only implied: the phrase 'in a scene and save it' hints this is for persisting a texture change to a scene file, but there is no explicit when-to-use, when-not-to-use, or alternative (e.g., add_node for node creation, save_scene for committing other changes). The agent must infer the context.

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

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

Annotations declare readOnly=false, destructive=false, openWorld=false, but do not convey that the process remains running asynchronously. The description adds this crucial trait ('the game keeps running') plus the fact that output is only the first few seconds, which meaningfully shapes agent behavior.

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?

Three tight sentences, front-loaded with the primary action and scoping, followed by the continuation/cleanup routing and the script variant. No filler.

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?

With no output schema present, the description still summarizes the return ('the output and any errors') and the ongoing-process model. For a six-param tool with full schema coverage and no required params, nothing essential is missing.

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 100%, so all six parameters are already documented in the schema. The description adds only modest framing (scene vs SceneTree script) beyond what the parameter descriptions provide, so the baseline 3 is appropriate.

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?

States a specific verb (Run) and resource (the project or one scene), and explicitly names the sibling tools get_debug_output and stop_project. An agent can distinguish it from launch_editor or create_scene without opening any schema.

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?

Clear context for use: run the project/scene, then use get_debug_output for continued output and stop_project to close. It also notes the SceneTree-script variant (e.g. headless test script). It lacks an explicit when-not-to-use or a comparison to launch_editor, so it stops short of the top score.

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

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

Annotations declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so safety is largely covered structurally. The description still earns credit by disclosing behavior the annotations do not: the scene is round-tripped through Godot, the file is normalized, and supplying newPath converts an overwrite into a copy.

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 sentence, front-loaded with the core action and appending the optional-path behavior without padding. Nothing redundant.

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?

With only three simple parameters, full schema coverage, and no output schema, the description covers the operation and its two modes (overwrite vs copy) adequately. It omits return/confirmation behavior, but that is a minor gap for a mutation tool of this simplicity.

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 baseline is 3. The description slightly exceeds the schema by explaining that newPath creates a copy/variant rather than just a destination, adding intent beyond the field description 'Save a copy here instead of overwriting.'

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?

States a specific verb+resource ('load and re-save a scene through Godot') and adds the notable effect that the file is normalized, which distinguishes it from plain reads like get_scene_tree. It does not explicitly contrast with the sibling create_scene, which is the closest point of confusion.

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 phrase 'optionally to a new path to make a copy/variant' implies the copy use case, which is useful context for newPath. However, there is no explicit statement of when to use this versus create_scene or get_scene_tree, and no preconditions are given.

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

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

Annotations already declare this is non-read-only, idempotent, and non-destructive, so the safety profile is covered. The description adds that it returns the last output, which is useful context, but says nothing about behavior when no game is running or how the output is delivered. Adequate but with clear gaps.

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 zero waste. The action and its relationship to run_project are stated immediately.

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 zero-parameter tool with no output schema, the description covers the essential points: what it stops and that it returns the last output. It could note the failure mode when no project is running, but the definition is largely 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?

The tool takes zero parameters, so the baseline is 4. There is nothing for the description to clarify, and it does not add confusing or misleading parameter claims.

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?

States a specific verb ('Stop') and resource ('the game started with run_project'), and explicitly names the sibling tool that started it. An agent can immediately distinguish it from run_project and the rest of the project/scene siblings.

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 pairing with run_project clearly implies when to use it: after a game has been launched. No explicit when-not condition is given (e.g., what happens when no game is running), but the context is unambiguous and sufficient to select the tool.

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

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

Annotations already declare non-read-only, idempotent, non-destructive behavior, so the bar is lower. The description still adds meaningful context: this is a project-wide rewrite touching every scene/resource, and it applies to Godot 4.4+ projects. It does not contradict destructiveHint=false, though it does not discuss backups or whether files are written in place.

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?

Two short sentences, zero filler, with the action and its effect front-loaded before the situational hint. Every clause 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 one-parameter, annnotation-covered tool with no output schema, the description covers what the tool does and when to use it. A note on scope/safety (e.g. that it rewrites project files in place) would close the only remaining gap.

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 100% and the single parameter's real semantics (defaults to the running project) come from the schema itself. The description only adds the Godot 4.4+ version constraint, not parameter-level detail, so baseline 3 applies.

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?

States a specific verb (re-save) and resource scope (every scene/resource) plus the outcome (all references use up-to-date UIDs). An agent can distinguish this bulk UID refresh from siblings like get_uid (single lookup) or save_scene (single-scene write).

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?

"Useful after upgrading a project from an older Godot" gives clear triggering context for when to reach for it. It stops short of naming alternatives or stating when not to run it, but the usage condition is explicit.

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