godot-mcp-bridge

Overview Schema Related Servers Score Discussions

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation2/5
Several tools overlap heavily: find_node_references, find_script_references, and search_in_files all grep project files for substrings, and move_to/navigate_to both walk the player character. Multiple property-reading tools (get_node_properties, get_game_node_properties, batch_get_properties, monitor_properties) add further ambiguity, making misselection likely despite detailed descriptions.
Naming Consistency5/5
All 174 tool names follow a strict lowercase snake_case verb_noun pattern (e.g., add_node, get_scene_tree, set_shader_param, find_unused_resources). There is no camelCase, no mixed conventions, and the pattern is highly predictable across the entire set.
Tool Count1/5
At 174 tools, this is an extreme count that far exceeds even a generous interpretation of the domain's scope. The sheer number overwhelms agents and violates the typical 3-15 tool guideline, even for a game-engine bridge.
Completeness3/5
The tool set covers a wide range of Godot workflows (scene editing, animation, audio, physics, UI, navigation, particles, testing, export), but notable lifecycle gaps exist: no delete_resource, no remove_audio_bus, no rename_animation or duplicate_animation. Arbitrary code execution via execute_editor_script can patch some gaps, but the surface is not fully complete for its stated purpose.
Average 3.6/5 across 174 of 174 tools scored. Lowest: 2.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 5 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only states the action itself. It does not mention side effects, whether the action is destructive, whether a transition must exist, or any error conditions. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence, front-loading the key action. It is concise and easy to parse. However, it is under-specified given the tool's complexity, but for the information it does provide, it is well-structured and wastes no words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters, no annotations, and no output schema, yet the description provides almost no contextual information. It is a bare statement of the operation without explaining the state machine context, parameter requirements, or likely return behavior. The description is inadequate for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage and the description adds no meaning to any parameter. It does not explain what node_path, from_state, to_state, or state_machine_path refer to, nor how they relate. The description merely repeats the concept of 'two states' without clarifying parameter roles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Remove the transition between two states of an AnimationTree state machine.' It specifies the action (remove), the target (transition), and the context (AnimationTree state machine). This distinguishes it clearly from sibling tools like add_state_machine_transition or remove_state_machine_state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives, no prerequisites, and no mention of required parameters like node_path or state_machine_path. It neither explains the context in which removal is appropriate nor excludes any cases. This leaves the agent without direction on when this tool is the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It does not mention side effects such as whether existing offsets are overridden, if the node must be a Control, or how the 'keep_offsets' parameter affects behavior. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler. It is front-loaded with the core action, but it sacrifices necessary detail for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, no output schema, and a low schema coverage, this description is incomplete. It does not explain return values, preconditions, or the functional effect of the 'keep_offsets' parameter, leaving the agent without adequate context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explanation of the parameters. It does not describe what 'node_path' refers to, the meaning of the preset enum values, or the effect of 'keep_offsets'. All semantic burden falls on the schema, which is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Apply'), the resource ('Control layout anchor preset'), and the target ('Control node'). It is specific enough to distinguish from general node manipulation tools, though it does not explicitly differentiate from sibling tools like 'setup_control'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. There are no mentions of prerequisites, exclusions, or when another tool might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of disclosing behavioral traits. It does not explicitly state that the operation is read-only, nor does it mention how traversal or recursion works, performance implications, or any side effects. The verb 'List' implies read-only but is not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded and free of unnecessary words. It earns its place by stating the core action and output format clearly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has three parameters, no annotations, and no output schema, the description is incomplete. It does not explain the meaning of path, filter, or max_depth, nor the structure of the returned tree. The agent lacks critical context to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention any of the parameters (path, filter, max_depth). The agent is left without any explanation of what these parameters mean or how they affect the result, so the description adds no value beyond the schema's bare parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists the project filesystem as a nested tree of directories and files. It is specific about the action and resource, and is distinguishable from sibling tools like search_files, though it does not explicitly call out alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives. The description simply states what the tool does, with no mention of use cases, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It only mentions 'optionally show them in the Inspector' but fails to disclose the semantics of selection modes (replace/add/remove), what happens to the existing selection, or the effect of the focus parameter. The tool mutates editor state, but no side effects or prerequisites are stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. It is front-loaded with the core action. However, for a tool with this parameter complexity, the brevity borders on under-specification rather than effective conciseness, so it does not earn a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, no annotations, and no output schema, the description is far from complete. It states the basic purpose but omits all parameter behavior, selection mode semantics, and the relationship to sibling selection tools. This is inadequate for an agent to use the tool correctly in complex scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only vaguely hints at inspect-related behavior. The parameter names (mode, focus, node_path, node_paths, for_property, inspector_only) are left entirely to inference. This is insufficient for a 7-parameter tool where mode, for_property, and inspector_only have non-obvious semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action (select nodes), the target resource (editor scene tree), and an optional behavior (show in Inspector). It is specific enough to distinguish from sibling tools like get_editor_selection and clear_editor_selection, though it does not mention the selection modes (replace/add/remove) which are part of the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives such as get_editor_selection for reading the current selection or clear_editor_selection for deselecting. There is also no explanation of how the mode parameter affects usage, leaving the agent without context for selecting the right tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose side effects, failure modes, or requirements. It only states the action without explaining whether it overwrites existing nodes, requires a valid parent path, or sets defaults for unspecified parameters. This leaves the agent uninformed about important behavioral aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no filler words. It efficiently communicates the core action and is appropriately brief for a tool that still lacks necessary detail elsewhere.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 11 parameters, no annotations, and no output schema, a one-line description is wholly inadequate. The agent has no information about parameter relationships, type-specific behaviors, or expected return values, making the tool difficult to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 11 parameters with 0% coverage from the description. The description does not explain the meaning or purpose of any parameter, including ambiguous ones like unit_size and attenuation_model. This is a complete failure to aid parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Add' and names the exact resource types (AudioStreamPlayer, AudioStreamPlayer2D, AudioStreamPlayer3D) and the target context ('under a parent node in the edited scene'). This clearly distinguishes it from generic node tools like add_node.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as add_node or batch_add_nodes. It does not mention any prerequisites, exclusions, or conditions that would help an agent choose this tool over the generic add_node.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only discloses the basic create+assign behavior but omits side effects, whether it overwrites existing properties, required prerequisites, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. However, it is too terse to convey essential parameter or behavioral details, though those are penalized in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given four parameters with no schema descriptions, no output schema, and no annotations, the description leaves too much unexplained. It lacks details on parameter semantics, return values, and side effects, making it incomplete for reliable agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions are 0% covered, and the description only hints at node_path and property via 'assign it to a node property'. It does not explain resource_type or resource_properties, leaving most parameters underspecified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a Resource subclass instance and assigns it to a node property, using a specific verb and resource. It distinguishes from siblings like create_resource by emphasizing the node property assignment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives such as create_resource. The description gives no contextual indications or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral details. It reveals only that the call returns immediately, but omits whether navigation relies on a navmesh, whether movement stops at the target, how to interrupt, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with the action, and includes a key behavioral note without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, four parameters, and a sibling movement tool, the description is too sparse to fully specify behavior, parameter meaning, or return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It clarifies that target can be a node or world position (matching the string/object union), but move_speed, camera_path, and player_path are entirely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it starts walking the 3D player toward a target node or world position and returns immediately. The verb+resource+scope are specific, but it does not distinguish from the similarly-named sibling move_to.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use navigate_to vs alternatives like move_to or setup_navigation_agent. The 'return immediately' phrase implies non-blocking usage, but no when/when-not is stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavioral traits. It only states the core action and does not mention whether it overwrites existing tiles, what happens with invalid coordinates, layer behavior, or any side effects. This is a mutation tool, so such gaps are significant.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. However, it is overly brief for a tool with 8 parameters, and the brevity comes at the cost of necessary detail, making it under-specified rather than cleanly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 8 parameters, no annotations, and no output schema, the description is severely incomplete. It provides no information about return values, parameter semantics, or operational behavior, making it inadequate for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only hints at 'x,y' but does not explain any of the 8 parameters (x, y, layer, atlas_x, atlas_y, source_id, alternative). It fails to compensate for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action ('Place one tile'), the resource ('TileMapLayer or legacy TileMap'), and the location ('at grid x,y'). It distinguishes this from sibling tools like tilemap_fill_rect (placing many tiles) and tilemap_get_cell (reading a tile).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Place one tile' implies a single-tile use case, which indirectly differentiates it from tilemap_fill_rect. However, there is no explicit mention of when to use this tool versus alternatives, nor any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It discloses that the operation saves project settings, but it does not mention overwrite behavior, validation requirements, or error outcomes. The mutation side effect is only partially disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, efficient sentence with no unnecessary words. The primary action is front-loaded, making the tool's purpose immediately clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, output schema, and parameter descriptions, the description leaves critical gaps: parameter semantics, usage guidance, and detailed side effects. It is barely adequate for a simple registration operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has two parameters with no descriptions and zero schema coverage. The description does not explain the meaning of 'name' or 'path' beyond implying path refers to a scene/script file. This is insufficient for an agent to know exactly what values to provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Register') on a specific resource (scene/script as an autoload singleton) and mentions the persistence side effect ('save project settings'). This distinguishes it from siblings like remove_autoload and get_autoload.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as get_autoload or remove_autoload. It does not mention prerequisites, exclusions, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It mentions that 'rotation is in degrees', which adds some parameter context, but it omits any side effects, such as whether adding the node replaces existing nodes, the impact of parent_path, or the behavior of mesh_properties. The write nature is implied by 'Add' but not elaborated, and no other behavioral secrets (e.g., coordinate system, scaling behavior, material handling) are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, directly front-loaded with the action and resource. It wastes no words and efficiently conveys the core purpose. However, it omits necessary details about other parameters and usage context, walking a fine line between conciseness and under-specification. Still, as written, it is structurally clean and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain parameter formats (e.g., scale/position accept string, array, or object), the purpose of mesh_properties, or how parent_path works. It also lacks any context about the result of the operation or potential side effects, leaving the agent to guess on several important aspects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It references 'mesh_type' and 'mesh_file' and clarifies rotation units, but leaves six other parameters (name, scale, position, parent_path, mesh_properties) undefined. Even for the mentioned parameters, it doesn't explain valid values for mesh_type (though the schema has an enum) or the relationship between mesh_type and mesh_file. The description only partially compensates for the complete lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Add a MeshInstance3D' with a specific verb ('Add') and resource ('MeshInstance3D'). It further distinguishes between two input modes ('primitive mesh_type or a mesh loaded from mesh_file') and notes rotation units, making it distinct from sibling tools like 'add_node' or 'add_scene_instance'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives. It does not mention exclusions, prerequisites, or contrast with siblings like 'add_scene_instance' for loading external scenes or 'add_node' for generic nodes. The only usage hint is the binary choice between mesh_type and mesh_file, which is more about parameter selection than situational context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It mentions the operation occurs 'in the edited scene' and that a parent is required, but it does not explain side effects (e.g., whether the scene is saved, if changes are undoable), how errors are handled (e.g., invalid type), or what happens with conflicting names. This is inadequate for a mutation tool with no additional metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded and contains no filler. It is concise and easy to scan. However, it sacrifices necessary detail for brevity, so it is not perfect; a slightly longer description that explains parameters would be acceptable if still structured efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters (one nested object), no output schema, and no annotations, the description is too sparse. It fails to explain the return value, the expected format for 'type' (e.g., full path, class name), how 'properties' is structured, and potential failure modes. An agent would likely need to guess or make assumptions, making this incomplete for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining parameters. It only implicitly references 'type' (ClassDB class or script) and 'parent_path' ('under a parent'), but provides no explanation for 'name' or 'properties'. The 'properties' object is especially unclear—what keys, value types, or how they map to node properties. The description adds minimal value over the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add a node') and the specific resource type ('ClassDB class or project class_name script'), and mentions placement 'under a parent in the edited scene'. This distinguishes it from siblings like add_scene_instance (which adds a scene instance) and batch_add_nodes (which adds multiple). However, the phrasing 'class_name script' is a bit awkward and could be clearer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for adding nodes from scripts/classes rather than scene instances, which gives some usage context. However, it does not explicitly state when to prefer this over alternatives like add_scene_instance or batch_add_nodes, nor does it mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only says 'create' and 'save', without explaining what happens if the path exists, whether it overwrites, or what validation occurs. There's no indication of safety or side effects beyond the implied write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, making it concise and front-loaded. However, it lacks detail, but that's a completeness issue rather than a conciseness issue.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, output schema, and parameter descriptions, the description is too brief to fully contextualize the tool. It covers the core purpose but omits details about the default_font_size parameter, save behavior, and error conditions. This leaves significant gaps for an AI agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no descriptions for the two parameters, and the description only adds context for 'path' by specifying it should be a res:// path. The default_font_size parameter is completely unexplained, leaving the agent without guidance on its purpose or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a Theme resource and saves it to a res:// path, which is a specific verb+resource+destination. This distinguishes it from sibling tools like create_resource, which likely creates generic resources, and set_theme_color, which modifies themes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like create_resource or edit_resource. There's no mention of prerequisites, exclusions, or context where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavior. It only states 'Get', which implies read-only, but does not explicitly guarantee no side effects, error behavior, or how preset selection works. Missing context like 'read-only' or 'returns empty if not found'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the verb, and every word adds value by specifying the resource and the exact fields returned. No wasted words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple but the description is incomplete for effective invocation. It does not explain how to select the preset (name vs index), what happens if both or none are provided, or the return format (beyond field names). With no output schema and no annotations, the description does not provide enough context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not compensate. It never mentions preset_name or preset_index, how to use them, whether they are exclusive, or what the default values imply. This is a significant gap for a tool with two optional parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' and clearly identifies the resource as 'Android export preset', enumerating exact data fields (name, index, export path, package unique name). This distinguishes it from siblings like list_export_presets and get_export_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. It does not mention that list_export_presets may be better for listing all presets or that this tool is for a specific preset.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not mention what is returned (node paths, IDs), how the optional top_only parameter affects results, or what happens when nothing is selected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear, front-loaded sentence with zero unnecessary words. It is appropriately sized for such a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple, the description omits crucial context about the top_only parameter and the format of the returned selection. This leaves an agent unable to predict exactly what the tool will produce or how to use the parameter correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, top_only, is completely undocumented in the description. Schema coverage is 0%, so the description must explain its meaning and effect, but it does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists the nodes currently selected in the editor scene tree. This specific verb ('List') and resource ('nodes') distinguishes it from siblings like select_nodes and clear_editor_selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as get_scene_tree or select_nodes. There are no exclusions, prerequisites, or context about typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The term 'assert' implies it may throw an error or return a boolean, but the description does not specify the failure behavior, return value, or whether it scans the entire screen. This lack of transparency is a significant gap for a test assertion tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, grammatically correct sentence with no redundant words, front-loading the core action and target. It could be considered impressively concise, though it sacrifices detail that might be expected for a tool with 3 parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description is incomplete for the tool's complexity. It states the main function but omits critical details like assertion failure semantics, parameter meanings, and return values. The tool appears simple, but the missing context prevents full understanding for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must explain the parameters, but it only mentions 'text' and ignores 'partial' and 'case_sensitive'. The schema provides no descriptions, and the description adds no meaningful semantics beyond the parameter names, leaving agents to guess their meanings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Assert') and resource ('text' in any Control element of the running game). It distinguishes itself from sibling tools like click_button_by_text (clicking vs asserting) and find_ui_elements (finding vs asserting).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for verifying text visibility during game testing, but it does not explicitly state when to use this tool versus alternatives such as assert_node_state or wait_for_node. No exclusions or alternative scenarios are mentioned, leaving the usage context clear but unguided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does 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 reveal that the tool returns 'class and editor-visible properties', which is useful, but it omits safety implications, error behavior, and what 'editor-visible properties' entails. The read operation is implied, but not explicitly stated as non-destructive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It efficiently conveys the core action and return information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter, no output schema, and no annotations, the description is incomplete. It omits the path format, expected return structure, and error behavior. The simplicity of the tool does not excuse the lack of these critical details for an agent to invoke it reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required parameter 'path' with zero description coverage. The description mentions 'resource file' but does not clarify the expected path format (e.g., res://, absolute, relative) or how it relates to the resource. It fails to compensate for the schema's lack of detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Load a resource file and return its class and editor-visible properties'. The verb 'Load' and the specific return values distinguish it from other resource tools like edit_resource or get_resource_preview, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as read_script or get_resource_preview. The description implies a use case (inspecting resources) but provides no exclusions, prerequisites, or context for choosing it over other read tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It discloses the return format (file, line number, text), which is useful, but it does not mention behavior such as default path, recursion behavior, or treatment of binary files. It also doesn't explicitly state it's a read-only operation, though that is implied. This is a minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the core action and output without excess words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has five parameters, no annotations, and no output schema. The description only provides a basic overview and does not address parameter usage or output structure beyond the three fields. Given the complexity, this is insufficient for an agent to confidently invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it does not explain any of the five parameters. The term 'Grep' implies that 'query' is a search pattern, but path, regex, file_type, and max_results are not described. This is a significant gap given the number of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Grep' and identifies the resource as 'project file contents', with a clear output specification (matching file, 1-based line number and text). However, it does not explicitly differentiate from the sibling tool 'search_files', which could be interpreted as searching file names or contents, so it falls short of the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as search_files or other analysis tools. The description does not mention any context, exclusions, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool saves project.godot, implying a persistent write side effect. However, with no annotations, it fails to mention error conditions, overwrite behavior, or reversibility, leaving significant transparency gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the main verb and resource. It is efficient, though it sacrifices necessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is too sparse to fully guide an agent. It does not explain how to discover valid keys, what value types are acceptable (beyond schema), or what happens on failure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description gives no parameter meanings. It says 'Set one project setting' but does not explain what 'key' and 'value' represent or how to format complex value types from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly names the action (Set), the resource (project setting), and the effect (save project.godot). It distinguishes from sibling read tools like get_project_settings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. It does not mention get_project_settings for reading or any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It adds value by stating that only supplied values are set, implying no changes to unspecified properties. However, it does not disclose whether this creates or modifies an existing StyleBox, what happens to prior overrides, or any side effects or persistence behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence, front-loaded with the action. Every phrase contributes meaning, with no filler or repetition. It is appropriately concise for the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, no annotations, and no output schema, the description is too terse to be complete. It omits key details such as node_path format, the meaning of 'name', color value expectations, and the tool's effect on existing theme overrides. The brief description leaves significant gaps for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It maps 'background, border, corner radius and padding' to bg_color, border_color, border_width, corner_radius, and padding, but fails to clarify the purpose of the required 'node_path' and 'name' parameters, nor does it explain string formats for colors. This leaves critical parameter semantics unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add a StyleBoxFlat theme override on a Control') and specifies the resource (a Control) and the properties involved (background, border, corner radius, padding). It is distinguishable from sibling tools like set_theme_color or set_theme_constant due to the specific StyleBoxFlat focus, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It implies usage for styling Controls, but does not mention exclusions, prerequisites, or contrast with other theme-related tools. The 'setting only the supplied' phrase hints at selective overrides but does not elaborate on the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full burden. It fails to disclose what happens on failure, whether the tool returns a value, or if it halts the game. 'Assert' implies a check but lacks critical behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, direct, no filler. Front-loads the action and object, and every word contributes to understanding the tool's core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters, no annotations, and no output schema, the description is too sparse. It leaves unanswered questions about return value, error behavior, valid node paths, and practical use in testing workflows.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%; the description only names the concepts (property, node, expected value, operator) but does not explain node_path resolution, property naming, expected value type, or operator meanings beyond the schema's enum. It adds minimal value beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Assert' and clearly identifies the target ('a property of a node in the running game') and the mechanism ('against an expected value using the given operator'). This distinguishes it from editor node tools by specifying 'in the running game', aligning with testing/assertion semantics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No context is provided about when to use this tool versus alternatives. It does not mention test scenarios, suitable conditions, or contrast with sibling tools like 'run_test_scenario' or 'assert_screen_text'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing side effects. It reveals that a new ShaderMaterial is created and assigned, but does not mention whether existing materials are overwritten, whether the scene is saved/modified, or any potential errors (e.g., invalid paths). This is a mutation tool with significant undeclared behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that is free of redundancy. Every word earns its place, and the structure is clear: action (wrap) + object (shader) + result (new ShaderMaterial) + target (node in edited scene).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that creates a material resource and mutates a scene, the description is under-specified. There is no mention of return value, error cases, or whether the material is saved/persisted. Without annotations or an output schema, the description should provide more context to be considered complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It links node_path to 'a node' and shader_path to 'a shader', but does not clarify expected path formats (e.g., scene tree paths vs resource paths), whether shader_path must be a Shader resource, or how the wrapping affects the material's parameters. Minimal value added beyond parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb phrase 'wrap a shader in a new ShaderMaterial and assign it to a node' that clearly identifies the tool's unique function. It distinguishes this from siblings like set_material_3d (which sets an existing material) and set_shader_param (which modifies shader parameters).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as set_material_3d or create_shader. The description states what it does but not the context in which it is the preferred choice, nor any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It adds one useful trait—'fresh ParticleProcessMaterial'—indicating a new sub-resource is created, but it does not disclose overwrite behavior for existing nodes, error handling for invalid parent paths, default property application, or whether the operation is reversible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with zero filler words. It efficiently communicates the core action, target resource, and placement context, earning its place entirely.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 9-parameter creation tool with no annotations, no output schema, and 0% schema description coverage, this description is inadequate. It covers only the basic add-node action and leaves parameter behavior, side effects, and edge cases entirely unexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across 9 parameters, so the description must compensate. It only references parent_path (the required param) and hints at the 2D/3D distinction via 'GPUParticles2D/3D'. Seven other parameters (amount, emitting, lifetime, one_shot, randomness, explosiveness, name) have no descriptive explanation anywhere.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Add') with a specific resource ('GPUParticles2D/3D node with a fresh ParticleProcessMaterial') and location scope ('under parent_path'). This clearly distinguishes it from generic siblings like add_node and from material-configuration tools like set_particle_material or apply_particle_preset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus the many related siblings (e.g., apply_particle_preset, set_particle_material, add_node). Usage context is only implied by the action verb; there are no alternatives, exclusions, or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavioral traits. It mentions creating, applying properties, and saving to disk, but omits critical safety-relevant details such as overwrite behavior (the overwrite parameter defaults to false), path interpretation, resource type constraints, or error handling. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded with the action verb and contains no filler. Every word contributes value, making it highly concise and easily parsed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of 4 parameters, a nested properties object, no output schema, and no annotations, this description is incomplete. It does not explain the format or purpose of 'path', the semantics of 'overwrite', the allowed resource classes, or the return value/error behavior, leaving too much to inference for reliable agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It adds some meaning for 'type' ('given class') and 'properties' ('apply properties'), but leaves 'path' and 'overwrite' entirely unexplained. This is insufficient for a 4-parameter tool with nested objects.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action (Create), the object (a resource of a given class), and the outcome (save to disk). This distinguishes it from siblings like read_resource, edit_resource, or add_resource by emphasizing creation and persistence.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like add_resource or edit_resource. No context about prerequisites, exclusions, or typical workflows is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does disclose the 'exactly one mode' constraint, but fails to mention the force parameter, the destructive nature of replacing content, or what happens if the file does not exist. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently lists all operational modes without redundancy. While it could be more structurally clear (e.g., bullet points), it is appropriately sized and front-loaded with the core verb and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 8 parameters, no annotations, and no output schema, making it a complex tool. The description covers the main modes but omits critical context such as force semantics, file existence handling, return values, and potential side effects. This is insufficient for an agent to safely invoke the tool with full confidence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Given 0% schema description coverage, the description adds value by explaining the parameter combinations for each mode (replacements list, content+start_line, content, insert_at_line+text). However, it does not clarify the force parameter, the distinction between text and content, or explicitly mention end_line, leaving some parameter semantics ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as editing a script file and enumerates the precise modes of operation, which distinguishes it from siblings like read_script, create_script, and validate_script. The verb 'edit' and resource 'script file' provide immediate clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use edit_script versus create_script or read_script, nor any exclusions or alternative recommendations. It implies the tool edits existing files but does not explicitly state this prerequisite or any conditions under which another tool would be preferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only mentions that nodes are live and in the running game, but does not disclose return format, behavior when no nodes match, whether the game needs to be running, or any side effects. This is insufficient for a no-annotations tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the verb and resource, followed by the specific search criterion. It is concise, with no redundant words or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and sparse parameter information, the description leaves significant gaps. It does not specify what the tool returns, how the optional 'properties' parameter behaves, or any constraints on use. The description is too minimal to be considered complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% since parameter descriptions are absent. The description explains that 'script' is a substring but does not explain the 'properties' parameter at all. The array of strings likely specifies which properties to return or filter, but the description omits this, leaving the optional parameter undefined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (find), the target (live nodes in running game), and the specific criterion (script path contains substring). This differentiates it naturally from sibling tools like find_nodes_by_type and find_nodes_in_group.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention exclusions or when not to use it, and there is no reference to sibling tools like find_nodes_by_type or find_script_references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adds some behavioral context by specifying 'full text' and 'from the project,' implying it returns complete file content and is read-only. However, it omits details on path resolution, error handling, or return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no filler or redundant information. It immediately states the action and target.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with one parameter and no output schema, the description adequately states the outcome but misses usage guidelines and path semantics. It is minimally viable but not fully self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single 'path' parameter has no schema description and the description only hints that it points to a script or shader file. No path format, example, or expected value is provided, leaving the agent to guess.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads the full text of script or shader files from the project, with a specific verb and resource. It distinguishes from edit/list tools but could be clearer about its relationship to read_shader and read_resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives such as read_shader or read_resource. There is no mention of scenarios, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description gives no behavioral details such as side effects, error handling, or whether references are updated. The agent has no information about the consequences of renaming beyond the action itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no unnecessary words, effectively communicating the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, no output schema, and no parameter details, the description is too sparse. It lacks information about the operational context, potential constraints, or return values, leaving the agent with an incomplete picture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain the parameters node_path and new_name beyond what their names imply. With 0% schema description coverage, this fails to compensate for the lack of structured parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (rename) and the target resource (node) within the edited scene context, distinguishing it from sibling tools like move_node or delete_node.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives, nor any prerequisites or exclusions. The description only states the basic action without practical usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only explains the matching rule (case-insensitive substring or glob) but omits details like whether the search is recursive, the default search root (res://), or how max_results limits output. No information is given about return format or failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence of 11 words conveys the core functionality with zero waste. It is appropriately concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema, the description should clarify what the tool returns (e.g., file paths, matches) and how it behaves with no results. It also does not explain the input schema fields beyond the query, leaving the tool under-specified for an agent to invoke correctly in varied contexts.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for all four parameters. It only clarifies the semantics of 'query' (matching pattern), but leaves 'path', 'file_type', and 'max_results' without explanation. The defaults are visible in the schema, but their meaning (e.g., file_type as extension filter, max_results as a cap) is not disclosed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'search' with the resource 'project file names', and clarifies the matching method as 'case-insensitive substring or glob pattern'. This clearly distinguishes it from sibling tools like search_in_files, which presumably search file contents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives. For instance, it does not contrast with the sibling search_in_files, and there is no mention of scenarios where file-name search is preferable to content search or other file-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It does disclose a key behavior: it modifies both project settings and the live editor InputMap. However, it does not explicitly warn that 'replace' means all existing bindings for the action are overwritten, nor does it mention side effects, permissions, or undo behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the core action and target without any filler. Every word contributes to meaning, making it highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (nested event schema, replacement semantics, deadzone parameter) and lack of output schema or annotations, the description is too minimal. It omits explanations of event types, deadzone behavior, and the consequences of replacement, leaving significant gaps for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no parameter information. The events array has a complex nested structure with four event types, but the description provides no guidance on how to construct bindings, making it entirely reliant on the schema, which is not sufficient for this complexity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Create or replace') and resource ('InputMap action's bindings'), plus scope ('in project settings and in the live editor InputMap'). This clearly distinguishes it from sibling tools like get_input_actions (read-only) and simulate_action (simulation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It does not mention that this is for configuring input actions rather than reading them or simulating them, nor does it state any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It discloses that it adds a node and configures a nav mesh, but omits side effects: whether it overwrites existing nodes, requires an existing parent, mutates the scene graph, or how it handles errors. The unit clarification for agent_max_slope is minor and insufficient for 11 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with the action, no redundant words. Efficient and clear within its limited scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 11 parameters, no output schema, and no annotations, yet the description provides only a high-level overview. It fails to address many parameters, edge cases, or expected outcomes, making it incomplete for a setup operation of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description only clarifies the unit for agent_max_slope ('in degrees'). It does not explain key parameters like mode, source_geometry_mode, cell_size, or navigation_layers, leaving the agent to rely solely on the schema for meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add') and the specific resource ('NavigationRegion2D or NavigationRegion3D') and intended placement ('under a parent node'). It also specifies the key configuration ('configured navigation polygon or mesh'), distinguishing it from sibling tools like bake_navigation_mesh or setup_navigation_agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives, prerequisites, or exclusions. The phrase 'under a parent node' hints at context but provides no decision framework or comparison to other navigation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It mentions the coordinate space and units, but does not disclose that a child node is added, that dimension determines the node type, whether the operation is additive/non-destructive, or any side effects. The description fails to disclose key behavioral traits beyond the narrow detail of target_position.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the core action and adds relevant detail without verbosity. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 11 parameters, no output schema, and no annotations, the description is severely under-specified. It lacks any explanation of return values, expected behavior, parameter interactions, or prerequisites. The description is minimal and leaves most operational aspects unknown.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only explains target_position's coordinate space and units, while 11 parameters remain undocumented. The description fails to clarify parameters like collision_mask, hit_from_inside, collide_with_areas, and collide_with_bodies, which are non-obvious without further context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's verb ('Add'), resource ('RayCast2D/3D child'), and adds meaningful detail about the coordinate space of target_position. Context signals show it as one of many node-creation tools, and this description specifically distinguishes it as raycast-specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for adding a raycast node, but provides no explicit guidance on when to use it versus alternatives like add_node or when to choose 2D vs 3D. No exclusions or alternative recommendations are mentioned, but the context makes the primary use case clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It only states that the tool lists visible Control nodes with certain attributes; it does not clarify whether the operation is read-only, how 'visible' is determined (e.g., visibility filter vs on-screen), the effect of the type_filter parameter, or the response format. Key behavioral traits remain undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes to the tool's purpose and output specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but the description omits the type_filter parameter and does not specify the exact return structure beyond listing fields. Given the lack of annotations and output schema, more detail is needed for a fully contextual understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one optional parameter (type_filter) with 0% schema coverage from the description. The description does not mention the parameter at all, leaving its purpose and expected values entirely unexplained. This is a critical gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and identifies the resource 'visible Control nodes in the running game', further specifying the returned fields (text, global rect, center point in screen pixels). This clearly distinguishes it from sibling tools like find_nodes_by_type or get_game_scene_tree.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is for querying UI elements during gameplay, but it does not explicitly state when to use this tool versus alternatives such as find_nodes_by_type or get_game_node_properties. No exclusions or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description is the sole source of behavioral info. It implies a permanent mutation but does not disclose side effects, reversibility, permission requirements, or error conditions, which is insufficient for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with action and object, no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no output schema, the description does not explain return values, failure behavior, or side effects. It is adequate for the simplest cases but incomplete for agents needing operational details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no descriptions (0% coverage), but the description implicitly maps 'name' to the animation and 'node_path' to the AnimationPlayer. However, it does not explicitly name the parameters or specify formats, so it only partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Remove' and clearly identifies the resource ('animation') and its scope ('from an AnimationPlayer's default library'), which differentiates it from sibling tools like list_animations and create_animation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 vs alternatives, prerequisites, or edge cases. The description only states what it does, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It mentions 'save project settings', indicating persistence, but omits potential failure modes (e.g., if the autoload does not exist) or whether the action is irreversible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action and resource, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with no output schema, the description is minimally adequate, covering the action and side effect. However, it lacks details about error handling or prerequisites, making it incomplete for a mutation tool without annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description only says 'by name', which adds little beyond the schema's property name 'name'. It does not clarify constraints, casing, or valid values for the autoload name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Remove', the resource 'autoload singleton', and the qualifier 'by name', making the action unambiguous. It also notes the side effect of saving project settings, which distinguishes it from related tools like add_autoload and get_autoload.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. It does not mention that it complements add_autoload or that it should be used instead of get_autoload for removal operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It explains the action (build and assign) but does not mention side effects, prerequisites (e.g., a valid node_path with a particle material), color format expectations, or whether existing gradients are replaced. For a mutating tool, this is insufficient detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the tool's purpose without wasted words. It is appropriately concise and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no annotations, no output schema, and zero schema description coverage, the description is not complete enough. An AI agent would lack crucial details about color value formats, allowed offset ranges, potential errors, and exactly how the gradient is applied to the material. The tool is simple, but the description still leaves significant gaps for safe and correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning to 'stops' by specifying they are 'ordered offset/color stops' and that a 'color ramp' is built, which clarifies the relationship between the two parameters. However, it does not explain the color string format, offset range, or node_path semantics beyond what the schema already shows.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with specific verbs ('Build' and 'assign') and identifies the resource ('particle material'). It distinguishes from sibling tools like set_particle_material by focusing specifically on building a gradient from color stops, which is a unique capability among the listed particle tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives such as set_particle_material or apply_particle_preset. It implies usage for creating color ramps, but there is no explicit context, exclusions, or comparisons to related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It discloses one important behavior ("dropped if no game is running") and mentions optional motion delta and held-button mask. However, it does not explain what happens after the move, whether it is instantaneous, or any other side effects or dependencies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the primary action ("Move the mouse to viewport pixel x,y"), and packs necessary qualifiers (optional motion delta, held-button mask, dropped if no game) without excess wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With six parameters, no annotations, and no output schema, the description leaves significant gaps: the meaning of 'unhandled' is undefined, the behavior for motion delta is vague, and there is no mention of return values, error handling, or how this interacts with other simulate_* tools. It provides some context, but not enough for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It clarifies x and y as viewport pixel coordinates, and references "motion delta" (likely relative_x/relative_y) and "held-button mask" (button_mask). However, it leaves 'unhandled' completely unexplained and the connection to relative_x/relative_y is ambiguous (motion delta could mean several things).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: "Move the mouse to viewport pixel x,y in the running game." It uses a specific verb (Move) and resource (mouse, viewport), and mentions optional motion delta and button mask. It does not explicitly distinguish from siblings like simulate_mouse_click, but the action (move vs click) is implied.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: it is for moving the mouse in a running game, and notes the event is dropped if no game is running. However, it does not explicitly state when to use this tool versus alternatives like simulate_key or simulate_action, nor does it mention any preconditions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden of behavioral disclosure. It only states the action without mentioning side effects, prerequisites, error behavior, or whether the operation is reversible. For a mutating tool, essential context is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence that efficiently conveys the core action without unnecessary words. It is concise and well organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters, no annotations, and no output schema, the description is insufficiently detailed. It lacks parameter explanations, behavioral constraints, and usage prerequisites, making it difficult for an agent to invoke the tool correctly in varied scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for unexplained parameters. It provides some context for state_type (animation, blend tree, nested state machine) and position (graph position), but node_path, state_name, animation, and state_machine_path are not explained beyond their names, leaving key semantics ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool adds a state (animation, blend tree, or nested state machine) to an AnimationTree state machine at a graph position. This distinguishes it from sibling tools like add_state_machine_transition and remove_state_machine_state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied through context: it is for adding states to an AnimationTree state machine, but there is no explicit when-to-use or alternatives guidance. The description does not mention when to use this vs other state machine tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not mention side effects (e.g., overwriting an existing script attach), prerequisites (node existence, script resource validity), or whether the scene file is modified. The mutation nature is implicit but no consequences are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the core action without unnecessary words. It is appropriately concise and easy to parse, though it sacrifices depth for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's mutation nature and lack of annotations, output schema, or parameter descriptions, the description is insufficient for a complete understanding. It omits context about expected inputs, error cases, return values, and interaction with the scene. The two simple parameters might lower complexity slightly, but the missing behavioral and contextual details make this incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for both parameters. The description itself does not elaborate on node_path or script_path beyond their names, leaving users to infer format (e.g., absolute vs. relative paths). The names are somewhat self-explanatory, but the description fails to compensate for the absence of schema descriptions, only minimally aiding parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Attach an existing script resource') and target ('a node in the edited scene'), distinguishing it from sibling tools like create_script or edit_script. The verb and resource are unambiguously identified, making the tool's purpose instantly clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'in the edited scene' provides some context but offers no explicit guidance on when to use this tool versus alternatives like create_script, edit_script, or add_resource. The usage is implied from the verb-resource pairing, but there are no exclusions or comparative scenarios mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the behavioral disclosure burden. It mentions the output format and frame spacing, but does not disclose details such as whether the game must be running, how resolution affects results, or error behaviors when the game is not running. This is a significant gap for a capture tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the action and outcome. There is no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is straightforward, the description lacks coverage of key parameters (count, half_resolution) and lacks any usage context relative to sibling screenshot tools. Without annotations or an output schema, the description leaves too many details unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must explain the parameters. It only clarifies 'frame_interval' (spacing between frames) but does not mention 'count' or 'half_resolution'. Given three parameters and zero schema coverage, the description fails to adequately compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action (capture a burst) on a specific resource (viewport frames from the running game) with output format (base64 PNGs). It distinguishes itself from sibling tools like get_game_screenshot by focusing on a burst of frames.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for capturing multiple frames but does not explicitly discuss when to use this versus alternatives like get_game_screenshot or compare_screenshots. No conditions or exclusions are mentioned, leaving the agent to infer the use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose the template generation behavior, but it omits critical details such as whether an existing file is overwritten (despite the 'force' parameter), what happens if the path is invalid, and the return value. For a mutating create operation, overwrite semantics are essential and missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence, front-loaded with the action and resource, containing no superfluous words. The key extra detail about the template is efficiently integrated, making the description concise yet informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no annotations, and no output schema, this description is under-specified. It addresses only file type and the empty-content behavior, while ignoring parameter meanings and side effects. For a tool this complex, the description is incomplete and would leave an agent uncertain about key aspects such as force and class_name.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only explains the behavior related to 'content' when empty. It does not explain 'path', 'force', 'extends', or 'class_name', leaving most parameters undefined. The mention of template generation hints at some meaning but does not establish clear semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Create' with the resource 'a .gd or .cs script file', making it distinct from sibling tools like edit_script, read_script, and attach_script. It also adds the precise behavior of generating a GDScript template when content is empty, further clarifying its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied: create a new script file. However, there is no explicit guidance on when to use this tool versus alternatives like attach_script or edit_script, nor any exclusions. The clarity of the core action provides some context, but no explicit usage rules.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It discloses the template-generation behavior when content is empty, but it does not explain what happens if the file already exists, the meaning of the 'force' parameter, or any overwrite behavior. This is a significant transparency gap for a creation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that delivers the core purpose and key conditional behavior without any filler. It is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters, no annotations, and no output schema. The description explains the template behavior but fails to cover overwrite semantics, the force parameter, or what success/failure looks like. This is insufficient for reliable tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clarifies the roles of 'content' (empty triggers template generation) and 'shader_type' (determines template), but it does not explain 'path' (required) or 'force' (a boolean likely controlling overwrite). This leaves critical parameters undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create' and the resource 'shader file', and distinguishes from siblings like read_shader or edit_shader by focusing on creation. The additional detail about template generation when content is empty is specific and helpful.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for creating new shader files, which is a clear context. However, it does not explicitly mention when not to use it or name alternatives (e.g., edit_shader for modifications), so usage guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It explicitly warns that the operation 'blocks the editor while running,' which is a valuable side-effect disclosure. However, it doesn't mention prerequisites like a connected device, failure modes, or permissions. The description adds some behavioral context beyond the name, but not comprehensively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence, front-loaded with the main action, and no redundancy. Efficient and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a multi-step deployment operation with six optional parameters and no output schema. The single-sentence description provides an overview but lacks essential details about parameter semantics, prerequisites, device selection, and expected output. It covers blocking behavior but is insufficient for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has six parameters with zero description coverage, and the description does not explain any of them. It fails to clarify the meaning of debug, launch, preset_name, skip_export, preset_index, or device_serial, leaving users without guidance on parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies a three-step process: export APK, adb-install, and launch on a device. It distinguishes itself from sibling tools like export_project and list_android_devices by including installation and launch, and it identifies the resource (Android device).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternative guidance is provided. The usage is implied through the described sequence, but there's no mention of when this tool should be preferred over export_project or list_android_devices, nor any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must communicate behavior. It states the operation but does not disclose whether the connection must already exist, what happens if it doesn't, whether it is reversible, or any side effects. For a mutating operation, this lack of detail is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no redundant words. It conveys the core purpose immediately and earns its place without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no annotations or output schema, the description is minimal but covers the basic function. However, it lacks important context such as prerequisites (connection exists), error behavior, and relationship to connect_signal. Given the 4-parameter schema and no other docs, it is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only vaguely maps parameters: source_path and signal_name identify the signal, target_path and method_name identify the handler. It adds some meaning but does not explicitly describe the parameters or their required format/path syntax.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: disconnecting a node signal from a method on a target node. It uses the specific verb 'Disconnect' and identifies the resources (signal, method, target node). It distinguishes from siblings like connect_signal (inverse) and find_signal_connections (inspection).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the context but provides no explicit guidance on when to use this tool vs alternatives. It doesn't mention that connections must exist or that connect_signal is the inverse. Sibling tools like watch_signals and find_signal_connections are related, but no exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the operation saves to disk, which is important, but it does not explain how properties are merged or replaced, whether validation occurs, or what happens on error. Lacks detail on permissions and response behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that communicates the core action and resource type. No wasted words, and it is front-loaded with the verb 'Set'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, no output schema, and sparse parameter documentation, the description is too minimal. It fails to explain return values, error conditions, or how the properties object interacts with existing resource properties, leaving significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clarifies that 'path' refers to a resource file and 'properties' are the properties to set, but gives no information about the structure or allowed keys for the properties object beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it sets properties on an existing resource file and saves it back to disk. This specific verb+resource combination distinguishes it from related tools like create_resource, read_resource, and update_property.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'existing resource file' implies it is not for creating new resources, but there is no explicit guidance on when to use this tool versus alternatives like create_resource or batch_set_property. No exclusions or alternatives are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It discloses that it can include the whole subtree, and the verb 'Report' implies a non-mutating read operation. However, it does not specify behavior for missing nodes, performance impact, or what the returned information looks like, leaving room for surprises.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the verb and main subject. Every word contributes to the tool's purpose, with no redundancy or filler. It earns the highest score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool reports multiple complex types of collision information, yet the description is brief and lacks detail on return format, prerequisites, or how the subtree behavior works. Without an output schema or annotations, the description does not provide enough context for an agent to fully understand the tool's behavior and results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It adds context for 'include_children' via 'optionally its whole subtree' but does not clarify node_path format or default behavior. The word 'optionally' conflicts slightly with the schema default of true, and no parameter-specific guidance is given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Report' and clearly enumerates the covered aspects (physics layers, body simulation properties, collision shapes, polygons, raycasts) and scope (node with optional subtree). This clearly distinguishes it from sibling tools like get_physics_layers or setup_collision, making it easy to identify the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives. It provides no exclusions, prerequisites, or comparisons to sibling tools like get_physics_layers (which might focus on layers alone) or setup_collision. The intended use case is implied but not articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral transparency. It does disclose the return record format (name/type/path/script) and scope (currently edited scene), which is helpful. However, it does not explicitly state that this is a read-only operation with no side effects, nor does it describe any potential limitations or error conditions. The word 'Get' implies a read, but the description could more explicitly reassure the agent about safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence of 15 words. It front-loads the primary action and resource ('Get the node tree...') and includes the output format without any fluff. Every word earns its place, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter), the description should thoroughly explain its use. While it states the purpose and return format, it omits any explanation of 'max_depth', which is essential for correctly using the tool. There is no output schema or annotations to fill the gap. The description is incomplete for fully informed invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema defines a single optional parameter 'max_depth' with no description, and the schema description coverage is 0%. The tool description does not mention 'max_depth' at all, leaving its semantics completely unexplained. The agent cannot determine what values mean (e.g., -1 likely means unlimited depth) or how it affects the result. The description fails to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get the node tree of the currently edited scene as nested name/type/path/script records'. It specifies the resource (currently edited scene) and the output format (nested name/type/path/script records), distinguishing it from sibling tools like get_game_scene_tree (runtime scene tree) and get_scene_file_content (scene file content).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool is for the editor's current scene, providing clear context for when it would be used. However, it does not explicitly mention alternatives or when not to use it, such as 'use get_game_scene_tree for the running game' or 'use get_scene_dependencies for dependencies'. The context is present but guidance is not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states the operation without mentioning side effects such as whether the node's global transform is preserved, how child nodes are handled, whether the operation is undoable, or what happens if paths are invalid. Given the mutation nature of the tool, this lack of detail is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is direct and free of extraneous words. It front-loads the action and clearly states the object and destination. Every word contributes to the meaning, making it an ideal concise description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It does not mention critical behavioral details such as transform preservation, handling of child nodes, uniqueness constraints, or error responses. Although the operation is conceptually simple, the missing context around reparenting semantics (e.g., does the node retain world position?) leaves the agent under-informed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not describe the two parameters. While the parameter names 'node_path' and 'new_parent_path' are self-explanatory, the description adds no value beyond the schema's type and required fields. It does not compensate for the missing schema descriptions, leaving potential ambiguity about expected path formats (e.g., absolute vs relative, node names with special characters).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'reparent' and identifies the resource ('a node') and destination ('to a new parent'). It clearly distinguishes this from sibling tools like rename_node, delete_node, and duplicate_node. The phrase 'in the edited scene' adds scoping, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for restructuring the scene hierarchy, but it does not explicitly state when to use this tool over alternatives or provide exclusions (e.g., 'use this instead of remove + add'). No mention of prerequisites or conditions for reparenting is given. It relies on the user understanding the standard concept of reparenting.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry full behavioral disclosure. It mentions the optional wiring capability but omits crucial details like what 'replace' does to existing connections, prerequisites for node type validity, or side effects on the blend tree state. This is insufficient for a mutation tool with 10 parameters and no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence without filler or repetition. It efficiently communicates the core action and an optional capability, earning every word's place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of 10 parameters, no annotations, and no output schema, this description is far from complete. It lacks return value details, error conditions, and any guidance on parameter combinations or constraints. The add/replace semantics and coordinate system assumptions are unstated, leaving substantial gaps for an agent to navigate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides a single hint about wiring output to input ports (relating to connect_to/connect_port) but fails to clarify the meaning of animation, position_x/y, state_machine_path, or the relationship between blend_tree_state and node_path. Parameters are left mostly unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool adds or replaces a node in a blend tree state and optionally wires outputs, using a specific verb and resource. It distinguishes itself from sibling animation tools by focusing exclusively on blend tree node manipulation, with no overlapping tool among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage in blend tree editing but does not explicitly state when to use this tool versus alternatives or mention exclusions. No alternative tools are referenced, leaving the agent to infer context from sibling names like add_state_machine_state, which target a different hierarchy.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It merely says 'Add a theme font size override', which implies mutation but does not explain side effects, whether existing overrides are replaced, persistence, or what happens on invalid node paths. The behavior is largely opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It conveys the core purpose efficiently and is appropriately sized for a straightforward tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description is the only source of context. It does not explain parameter semantics fully, nor does it mention defaults, preconditions, or side effects. For a mutation tool, more context is needed for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must clarify the parameters. It clarifies that 'size' is in pixels and that the override applies to a Control, but the 'name' parameter is unexplained. This leaves one of three parameters ambiguous and does not fully compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Add' and the resource 'a theme font size override on a Control', which distinguishes it from sibling tools like set_theme_color or set_theme_stylebox. It also specifies the unit 'in pixels', adding precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternative guidance is provided. The description implies usage when you need to override a control's font size, but it does not mention exclusions or when another theme-related tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It only lists configurable aspects without stating whether it overwrites existing settings, requires a Control node, or how invalid values are handled. For a mutating tool, this is a notable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence. It leads with the action and resource, then lists properties without any filler. Every word contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite a rich schema with enums, the tool has 9 parameters, nested objects, no output schema, and no annotations. The description is too sparse to fully support autonomous invocation: it omits prerequisites (e.g., node must be a Control), side effects, and how properties interact. It is inadequate for this complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does map high-level concepts to parameters (e.g., 'grow directions' to grow_h/grow_v), but it doesn't explain nuances like the string vs object form of min_size or the meaning of size flag values. Partial compensation but insufficient for full clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Configure a Control's layout' and enumerates specific properties (anchor preset, minimum size, size flags, grow directions, margins, separation). This verb+resource+scope is specific and distinguishes it from generic setters like batch_set_property and the narrower set_anchor_preset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for layout configuration but provides no explicit guidance on when to use it versus alternatives such as set_anchor_preset or individual property updates. It gives clear context but no exclusions or alternative recommendations, so it earns a mid-range score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful detail about rotation/spot_angle being in degrees and the two input modes, but it omits many behavioral aspects: what happens if both light_type and preset are provided, default values, whether it modifies the current scene, or any return value. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence that states the primary action, the two input modes, and critical unit details. Every word earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (13 parameters, 0% schema coverage, no output schema, no annotations), the description is far from complete. It communicates the core purpose but does not provide enough information about parameter semantics, valid combinations, side effects, or return values for an agent to invoke it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clarifies the preset enum values and the relationship between light_type and preset, and specifies units for rotation and spot_angle. However, the remaining 10+ parameters (color, range, energy, shadows, position, attenuation, parent_path, spot_angle_attenuation) are left completely unexplained, which is insufficient for a 13-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add a 3D light') and specifies the two input modes ('from a light_type or a preset'), which distinguishes it from sibling tools like setup_camera_3d or setup_environment. The enumerated presets (sun, indoor, dramatic) further clarify the exact scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a 3D light needs to be added and explains the key selection method (light_type or preset), but it does not explicitly state when to use this tool over alternatives, nor does it mention any exclusions or preconditions. Usage is decently implied but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses a key behavioral trait: only the provided pathfinding and avoidance properties are applied, implying no changes to other agent properties. However, it omits important details such as what happens if the node already exists, default naming, whether it overwrites, and any failure modes. Some transparency is provided, but significant gaps remain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence with no redundant words. It front-loads the action and resource, then qualifies the behavior. Every word earns its place, making it highly concise and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 11 parameters, no annotations, and no output schema, the description is far from complete. It does not explain parameter defaults, the meaning of 'mode' auto, interaction with parent nodes, or result feedback. The description suffices only for a high-level understanding and would leave an agent guessing on details critical for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, leaving the description to compensate. It categorizes properties as 'pathfinding and avoidance' but does not explain any of the 11 parameters (e.g., mode, radius, max_speed) or how they map to the agent. This provides minimal semantic value beyond the schema's bare parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add') and the resource ('NavigationAgent2D or NavigationAgent3D'), along with the placement ('under a parent node') and scope ('applying only the pathfinding and avoidance properties given'). This distinguishes it from sibling tools like setup_navigation_region or bake_navigation_mesh, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It does not mention any preconditions, such as the parent node existing, or contrast with generic add_node or navigation-specific tools. The description only states what it does, not when to choose it over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden. It fails to disclose whether an existing animation with the same name is overwritten, whether the default library is auto-created, or what happens if the AnimationPlayer path is invalid. For a mutation tool, these side effects and prerequisites are critical.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the core action and includes essential parameter details inline. It is efficient and free of unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations or output schema, the description should provide more context about side effects and prerequisites. It covers the purpose and two parameters but omits overwrite behavior, error handling, and requirements for the node path, making it incomplete for a creation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning for length ('in seconds') and loop_mode ('0 none, 1 linear, 2 pingpong'), but leaves node_path and name to be inferred from the tool's purpose. This partial coverage falls short of fully compensating for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Create' with a clear resource ('empty Animation') and container ('AnimationPlayer's default library'), clearly distinguishing it from sibling tools like add_animation_track or set_animation_keyframe. It also specifies the key attributes (length, loop mode).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for initializing an empty animation before adding tracks or keyframes, but it doesn't explicitly state when to use this tool vs siblings, nor does it mention alternatives or exclusions. The context is clear but the guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses a notable behavior (deleting the .import sidecar), which adds value. However, it does not mention that deletion is irreversible, whether permissions are needed, or if the scene must be closed, so transparency is partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that communicates the core action and a key side effect without any extraneous words. It is highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no annotations and no output schema, the description covers the primary purpose and the sidecar detail, but lacks usage context, path semantics, and consequences. It is minimally complete but leaves important gaps for an AI agent to safely invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines 'path' as a string, and the description does not elaborate on what path format is expected (absolute vs. project-relative, with/without extension). Since schema coverage is 0%, the description should compensate but does not provide this needed clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and the resource ('a scene file from disk') with a specific detail ('.import sidecar') that distinguishes it from other delete tools like delete_node or remove_animation. It is a specific verb+resource description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives such as delete_node or remove_autoload. The description only states what it does, not the context or prerequisites, leaving the agent to infer usage from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It correctly indicates a non-mutating detection operation and mentions a specific technique (textual parsing), but does not disclose potential limitations (e.g., false negatives for non-textual references), error behavior, or performance implications. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that packs all essential information (what, how, output) without redundancy. Every word contributes value, and it is front-loaded with the primary action. This is an excellent example of concise writing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two optional parameters and no output schema, the description provides a reasonable overview of functionality and return value. However, it omits any detail about the meaning of the 'path' and 'include_addons' parameters, and the structure of the returned cycle paths is unspecified. Given the moderate complexity, the description is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 ('path' and 'include_addons'). The description does not mention these parameters at all, leaving their purpose and acceptable values entirely to the schema defaults, which are minimal. Since schema descriptions are absent, the description fails to compensate for the lack of parameter guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Detect cycles'), the resource ('scenes'), the method ('by parsing ext_resource scene references textually'), and the output ('return each cycle path'). This specific phrasing distinguishes it from sibling tools like get_scene_dependencies, which lists dependencies but does not detect cycles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the usage scenario: finding circular dependencies among scenes. It does not explicitly state when to prefer this tool over alternatives or provide any exclusion criteria. The reference to textual parsing gives a hint about its approach but not about when it is most appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It adds useful context about the exclusive mode requirement and that replacements are literal search/replace. However, it does not disclose what happens if both modes are supplied or neither, nor any side effects, permissions, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that delivers essential information without padding. Every phrase is meaningful, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema or annotations exist, so the description must compensate. It explains the core mode selection but leaves out the purpose of 'force', file path requirements, and potential failure modes. For a mutating file-edit tool, this is insufficient for an agent to confidently invoke it in all circumstances.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage. The description clarifies that 'content' is for a full replace and 'replacements' is a list of literal search/replace items, which adds meaning for two of the four parameters. However, it does not explain the 'path' or 'force' parameters at all, and the schema itself gives no hints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool edits a shader file, with a specific verb and resource. It distinguishes between two modes (content and replacements) and uses 'exactly one mode' to disambiguate, separating it from siblings like read_shader or create_shader.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool vs. alternatives like edit_script or read_shader. It does not mention prerequisites, preferred use cases, or when the replacement mode might be preferable over content mode.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only says 'Read', implying non-destructive behavior, but does not clarify what happens if the autoload is missing, the return format, or whether properties is optional. The meaning of the 'properties' parameter is entirely unexplained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It is concise and to the point, conveying the core action and resource in a compact form.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool, the main purpose is clear, but the unexplained 'properties' parameter and lack of any usage guidance or return behavior leave gaps. The description is not fully complete for an agent to invoke the tool correctly, especially regarding optional parameter semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains 'name' via the path placeholder '/root/<name>' but gives no meaning for the 'properties' parameter. Only half the parameters are semantically clarified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads an autoload singleton at a specific path, using the specific verb 'Read' and identifying the resource. It naturally distinguishes from sibling tools like add_autoload and remove_autoload.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied: it is the read counterpart to add/remove_autoload, but the description does not explicitly state when to use it or when to prefer alternatives. No exclusions or alternative tool names are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions 'optionally clear' but does not disclose that the 'clear' parameter defaults to true, meaning by default the tool clears results. This is a significant side-effect omission that could lead agents to unintentionally destroy data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that conveys the core action and side effect without unnecessary words. It is well-structured and front-loaded, achieving maximum informational density.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple with one parameter, the description lacks essential context such as the default destructive behavior, the format of the summary output, and whether results are permanently cleared. Without annotations or an output schema, these gaps make the tool under-specified for safe autonomous use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides only a boolean 'clear' with default true and no description. The phrase 'optionally clear the collected results' adds some meaning by linking the parameter to the behavior, but it does not explain the default behavior or the exact effect of setting clear to false, leaving ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'summarize' and identifies the resource ('every assertion recorded this plugin session'), clearly distinguishing it from sibling tools. It also mentions the optional clearing action, providing a complete purpose statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for reviewing assertion results after a test session, but it gives no explicit guidance on when to use it versus other tools or when not to clear results. The context 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits. It states the action (list files) and the summary information (class_name or extends), but does not disclose return format details, recursive behavior, or any side effects. This is minimal but acceptable for a simple read-only listing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately states the action and key details. No filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but the description lacks certain context: it does not specify whether listing is recursive (despite a 'recursive' parameter), nor does it clarify the exact return format beyond class_name or extends. Given no output schema, this is a gap, but the description still captures the core functionality.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% because the description does not explicitly reference any parameters. It mentions 'project path' which partially explains the 'path' parameter, but the 'recursive' parameter is completely omitted. The schema has no descriptions for parameters, so the description fails to fully compensate for the lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: listing script files (.gd/.cs/.gdshader) under a project path, and specifies the output includes class_name or extends. This is specific and distinguishes it from sibling list tools like list_animations or list_export_presets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as find_script_references or search_files. It does not mention exclusions, prerequisites, or situations where another tool would be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for disclosing behavior. It states the core conversion but omits important behavioral details such as whether the path must exist, what happens on invalid or missing resources, whether the operation is read-only, and what the return value format is beyond the implied uid:// string.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise, front-loaded sentence with no filler or redundancy. Every word contributes to the tool's meaning, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter conversion tool, the description provides the essential transformation but is incomplete in context: no error behavior, no explicit return type, no notes about whether the resource must already exist. Given the absence of annotations and output schema, a bit more detail would be needed to fully cover edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the bare `path` string parameter. It adds the useful context that the path should be a res:// project path, but it does not provide examples, format constraints, or any details about accepted path variants or error conditions. This is marginal compensation for a single undocumented parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Resolve') and names both input and output formats ('res:// project path' to 'uid:// identifier'), making the tool's purpose unambiguous. It also inherently distinguishes itself from the sibling tool uid_to_project_path, which performs the inverse operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when a res:// path needs to be converted to a uid:// identifier. However, it does not explicitly state when not to use it, mention alternatives (e.g., uid_to_project_path), or provide any prerequisites or context about when such a conversion is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It uses 'Get', implying a read-only operation, and constrains the accepted node types ('TileMapLayer or legacy TileMap'). However, it does not disclose return format, error behavior, or any side effects. It adds useful context but lacks details about what happens on invalid input or the structure of the returned data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the verb 'Get' and immediately enumerates the data items. It contains no fluff or redundant phrasing, making every word meaningful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple getter with one parameter, no annotations, and no output schema. The description lists the conceptual data returned, but it does not describe the return structure (e.g., dictionary keys, types). It also omits error scenarios and any behavior differences between TileMapLayer and legacy TileMap. Given the lack of annotations and output schema, more detail is needed for full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explicitly explain the 'node_path' parameter. Although the parameter name is self-explanatory, the description does not confirm that node_path must reference a TileMapLayer or legacy TileMap node. The description adds no meaning beyond the schema field name, failing to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies a specific verb ('Get') and resource ('TileMapLayer or legacy TileMap'), and lists exactly what information is retrieved (layers, used cell counts, TileSet sources, tile size in pixels). This distinguishes it from sibling tools like tilemap_get_cell and tilemap_get_used_cells, which focus on individual cells.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus the many other tilemap-related tools (e.g., tilemap_get_cell, tilemap_get_used_cells). The description implies a getter for metadata but does not explicitly state 'use this when you need tilemap-level info' or mention alternatives. No exclusions or context for selection are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the basic action and gives an example, but does not disclose side effects (e.g., whether it modifies the animation resource in place), prerequisites (e.g., whether the animation must already exist), or behavior for different track types.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the action and includes a concrete example. There is no wasted text, and the most important information is immediately accessible.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, 2 enums, no annotations, and no output schema, the description is insufficient. It only covers the path context and omits crucial details about track_type options, update_mode semantics, and how node_path relates to track_path. An agent would need additional knowledge to use this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It gives an example of the path format ('Sprite2D:position') but does not explicitly explain the roles of node_path vs. track_path, nor does it cover track_type or update_mode. This leaves significant ambiguity about the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Append a track to an animation') and specifies the target ('a node property path relative to the AnimationPlayer root node'), with a concrete example ('Sprite2D:position'). This distinguishes it from sibling tools like set_animation_keyframe or get_animation_info, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: this tool is for appending tracks, and shows the expected path format relative to the AnimationPlayer. However, it does not explicitly mention alternatives or exclusions (e.g., when to use set_animation_keyframe instead), leaving the differentiation to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses two important behaviors: the operation affects live audio state immediately, and persistence requires manual saving of the bus layout. This goes beyond simply saying 'add' and gives the agent actionable knowledge about side effects and persistence.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the core purpose and adds two key behavioral notes. No wasted words; every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there are 6 parameters, no output schema, and no annotations, the description is too sparse to fully equip an agent. It covers the main action and persistence but omits all parameter semantics, potential failure modes, or implications of different parameter values. The agent would likely need to guess or rely on examples.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate by explaining any of the six parameters (name, mute, send, solo, volume_db, at_position). The agent must infer parameter meanings solely from names/types, which is insufficient for a tool with this many parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Add an audio bus to the AudioServer'. It uses a specific verb ('Add') and resource ('audio bus'), and distinguishes it from sibling tools like 'set_audio_bus' or 'add_audio_bus_effect' by focusing on the bus itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some context about usage—'changes live audio state' and 'save the bus layout manually to persist'—which implies when to use it and what to do afterward. However, it does not explicitly compare to alternatives or state when not to use it, so the guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It discloses that painted cells are not undoable, which is important. However, it does not explain other behaviors like whether existing cells are cleared on reconfigure or what other side effects occur.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the core purpose and appends a critical limitation. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters, no schema descriptions, no output schema, and no annotations, the description is too sparse. It provides a high-level purpose and one warning but leaves many operational details (e.g., parameter meanings, reconfigure behavior) uncovered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only mentions MeshLibrary and painting cells, which relates to mesh_library_path and cells, but leaves name, position, cell_size, node_path, and parent_path unexplained. This is insufficient compensation for 7 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates or reconfigures a GridMap using a MeshLibrary and paints cells. This is a specific verb+resource+action that distinguishes it from sibling tools like tilemap_set_cell or add_mesh_instance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by naming GridMap and MeshLibrary, making it clear this is for GridMap creation/reconfiguration. However, it does not explicitly mention when to use this vs alternatives or provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the core action without disclosing side effects, error conditions, return values, or any prerequisites. For a mutating tool, more behavioral context is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes meaning, making it appropriately concise for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations, no output schema, and 3 parameters with undocumented semantics. The description provides minimal context about invocation requirements, failure modes, or what result to expect. This is insufficient for an agent to use it reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description indirectly hints at scene_path and parent_path via 'packed scene' and 'child node', but it does not explicitly explain the 'name' parameter or the semantics of the default parent_path. It fails to compensate for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Instance') and identifies the resource ('a packed scene') and the target location ('as a child node of the currently edited scene'). This clearly distinguishes it from siblings like add_node or add_mesh_instance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly states the context of use (instancing a packed scene into the currently edited scene), which implies when this tool is appropriate. However, it does not explicitly mention alternatives or exclusion cases, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the behavioral disclosure burden. It does disclose a key prerequisite for the advance_expression parameter and notes that Start/End are valid states. However, it does not describe side effects, return values, failure modes, or whether the operation is a mutation, which are important given the absence of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that communicates the primary purpose immediately and adds necessary detail without redundancy. It is appropriately sized for the tool's complexity and avoids filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 8 parameters, no output schema, and no annotations, the description is insufficient. It covers some parameter semantics and one prerequisite, but it does not explain the full parameter set, expected outcomes, or error conditions. This is a complex mutation tool that warrants a more thorough description to be contextually complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning for some parameters: from_state/to_state can be 'Start' or 'End', and advance_expression is optional and requires advance_expression_base_node. However, it does not explain the semantics of node_path, state_machine_path, xfade_time, or the practical effect of switch_mode and advance_mode values, leaving significant gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: adding a transition between two states in an AnimationTree state machine. It also adds useful context by mentioning that Start/End are accepted as state names, and specifies the transition modes involved. This distinguishes it from siblings like add_state_machine_state and remove_state_machine_transition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (to add a transition), but it does not explicitly state when to use it versus alternatives or provide exclusion criteria. It does mention a prerequisite (advance_expression_base_node), which offers some usage context, but no direct comparison to sibling tools is made.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosure. It discloses the comparison method (pixel by pixel) and the output shape (change count + diff image), but it omits important behavioral details such as how the threshold parameter affects the comparison, what happens with invalid/mismatched images, or whether the diff image is returned as a path or base64.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the core action and quickly lists input formats and outputs. Every phrase adds value, and there is no redundant fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main purpose, input types, and output summary, but it lacks critical context like threshold semantics and any error/edge-case behavior. Since there is no output schema, the description should more precisely define what 'change count' and 'red-highlighted diff image' mean in practice, but it does provide a reasonable high-level summary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides only basic types and a default for threshold, with no parameter descriptions. The description adds meaningful semantics for image_a and image_b (res:// or user:// paths, or raw base64), but it entirely omits threshold, leaving its purpose and behavior undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb (compare), a specific resource (two PNG images), and the expected outputs (change count and red-highlighted diff image). It is distinct from sibling tools that capture or generate screenshots, and it has no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used for comparing PNG screenshots, but it provides no explicit guidance on when to choose this tool over alternatives (e.g., get_editor_screenshot, get_game_screenshot, or capture_frames). There are no usage contexts, exclusions, or prerequisites stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden. It does disclose a key side effect—persistence into the scene file—which is more than a purely abstract statement. However, it does not mention what happens on duplicate connections, whether existing connections are replaced, whether the scene must be open/saved, or validation behavior for invalid paths/signals.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence of eleven words with no filler. Every word contributes meaning and it is immediately scannable, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite clear purpose, this is a mutation tool with no annotations, no output schema, no description of return values, error conditions, or prerequisites. For an operation that writes to scene files, the description leaves significant gaps about invocation context and expected outcomes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the parameters beyond the high-level mapping of 'node signal' and 'target node.' Parameter names are suggestive but lack needed format details, such as whether paths are scene-relative or absolute, and whether nodes/signals must already exist in the scene.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Connect') and clearly names the resource (a node signal) and the outcome (method on a target node, persisted into the scene file). The persistence detail distinguishes it from runtime signal watching tools like watch_signals and from the inverse disconnect_signal sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'persisted into the scene file' implies this is for making static, scene-saved connections rather than runtime-only ones, but there is no explicit when-to-use or when-not-to-use guidance, nor mention of alternatives like watch_signals or find_signal_connections.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the read-only nature via the verb 'Read', but does not cover behaviors like return format, error handling, or behavior when node_path is invalid or properties is empty. This is basic transparency but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes to understanding the tool's core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and zero parameter coverage, a simple one-line description is insufficient. It does not mention expected results, error scenarios, or how it differs from the many sibling read tools. For a low-complexity tool, it is still under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it adds no parameter-specific meaning. It does not explain node_path format, how the properties array works, or what happens if omitted. The description provides no value beyond the schema's structural field names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Read'), resource ('live property values of a node'), and scope ('in the running game'), which distinguishes it from similar siblings like 'get_node_properties' (likely editor-side) and 'batch_get_properties'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'in the running game' provides clear context for when to use this tool (runtime, not editor). However, it does not explicitly name alternatives or exclusion conditions, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It adds useful context like 'live', 'from the tree root', and 'including autoloads'. However, it doesn't disclose output format, default depth behavior, or potential performance impact, leaving behavioral transparency only partially addressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately conveys the core action and scope. It contains no filler and is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given four optional parameters and no output schema, the description is too sparse to fully guide an agent. It doesn't mention return values, parameter semantics, or any specific use cases, so completeness is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides zero explanation of the four parameters (max_depth, named_only, type_filter, script_filter). The description does not compensate for the lack of parameter documentation, leaving the agent to guess how filters affect the dump.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Dump'), the resource ('live scene tree of the running game'), and the scope ('from the tree root, including autoloads'). This distinguishes it from editor scene tree tools like get_scene_tree and find_nodes_by_type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when you need the runtime scene tree, not the editor scene tree. It provides clear context but does not explicitly name alternatives or specify when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the burden. 'List' implies a read-only operation with no side effects, which is adequately transparent for a simple getter. However, it does not disclose behavior for invalid node paths or return format details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the action, and contains no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema. The description explains the purpose and implies the return (a list of groups). It is sufficient for basic invocation, though it lacks detail on error behavior and path semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not elaborate on node_path beyond the parameter name. It does not specify path format, whether it is file-system path or scene-tree path, or any constraints, leaving the agent to infer from the name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and a clear resource 'the groups a node belongs to'. It is distinct from sibling tools like set_node_groups (mutates groups) and find_nodes_in_group (finds nodes for a group).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 instead of alternatives such as find_nodes_in_group or set_node_groups. The context of siblings exists but the description does not mention them or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. 'Summarize' strongly implies a read-only operation, and the listed metrics suggest it gathers and aggregates data without side effects. However, it does not explicitly state that it does not modify files, nor does it mention potential performance impact on large projects or handling of invalid paths. The implied non-destructive nature earns a mid score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the action ('Summarize the project') and enumerates the key outputs. Every word adds value, with no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has two parameters and no output schema, so the description must compensate by explaining parameter behavior and return shape. It lists what is included in the summary but omits any detail about the 'path' and 'include_addons' semantics, and it does not describe the format of the returned statistics. This leaves significant gaps for a stats-gathering tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description provides no explanation of the parameters. The 'path' and 'include_addons' parameters are left entirely to the schema's name and default values, which is insufficient for an agent to understand their exact meaning or effect on the results.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Summarize') and explicitly lists what the tool covers: file counts by extension, GDScript line count, scene and resource counts, autoloads, and plugins. This clearly distinguishes it from sibling tools like get_project_info or get_filesystem_tree, which focus on different aspects of the project.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use this tool when you need a quantitative summary of the project. However, it does not mention alternatives or exclusions, such as when to use get_filesystem_tree or get_project_info instead, so it stops short of fully explicit usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It states that it triggers a rescan but does not mention potential side effects, whether the operation is synchronous, or any impact on unsaved changes. This is a minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the function. It is concise and free of extraneous information, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters or output schema, but the description lacks information about return values and potential side effects. Given the 'reload' context, more details about the consequences of the rescan would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no need for the description to explain parameter meanings. The schema is empty, and the description correctly does not invent parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Trigger a rescan' and identifies the resource as 'the project filesystem in the editor.' This clearly distinguishes it from sibling tools like reload_plugin or get_filesystem_tree.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool or when to prefer an alternative. It only states the action without context, conditions, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly discloses two important side effects: Godot drops transitions touching the state, and undo does not restore them. This goes beyond a basic action description, though it could mention prerequisites or failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that gets straight to the point. It is front-loaded with the action and resource, and the parenthetical adds critical side-effect information without bloat. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has three parameters with no schema descriptions, no annotations, and no output schema, the description is too sparse. It does not explain what node_path vs state_machine_path mean, return values, error conditions, or when the state machine path is needed. While the side effects are disclosed, the overall context is incomplete for safe and correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has three parameters (node_path, state_name, state_machine_path) with zero description coverage, and the description does not explain the meaning or format of these parameters. It only mentions 'state' and 'AnimationTree state machine' without clarifying which parameter refers to what, leaving the agent to guess from names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Remove a state') and the resource ('AnimationTree state machine'), distinguishing it from the sibling tool 'remove_state_machine_transition' which removes transitions. The parenthetical adds specific context about side effects, further clarifying the tool's scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to remove states from an AnimationTree state machine but does not explicitly state when to use it versus alternatives like 'remove_state_machine_transition' or 'add_state_machine_state'. The side-effect warning about transitions being dropped and undo not restoring them gives some usage context but no direct comparison or exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It does mention the mutation ('insert or replace') and the easing curve, which gives some transparency. However, it does not state prerequisites (e.g., whether the animation/track must exist) or error/side-effect behavior, leaving gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action, and contains no filler or redundant information. Every phrase earns its place, making it highly concise and structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and 6 parameters, the one-sentence description is insufficient for full context. It does not explain how to specify the track (track_index), the accepted types for 'value', or the relationship between node_path and animation, leaving the agent to infer critical invocation details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only partially compensates by mentioning 'time in seconds' and 'easing transition curve,' which map to the time and easing parameters. It does not clarify the semantics of node_path, animation, value, or track_index, leaving most parameters undocumented in prose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Insert or replace') and the resource ('a keyframe at a time in seconds on an animation track'), with an additional detail about easing. This distinguishes it from sibling tools like add_animation_track or set_blend_tree_node, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating what the tool does, but it does not explicitly say when to use it versus alternatives, nor does it mention any exclusions or prerequisites. For example, there is no guidance like 'use this to modify keyframes; to add a track, use add_animation_track instead.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description is the sole source of behavioral disclosure. It reveals the critical behavior that groups not in the desired set are removed, which is important for a setter. However, it does not mention prerequisites, side effects on related nodes, or error handling, leaving some transparency gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence with no fluff. It front-loads the core action (set full group membership) and adds necessary clarification. Excellent brevity and clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, no output schema, and low parameter coverage, the description is sparse. It explains the core action but lacks usage guidance, parameter format details, and edge-case behavior, making it insufficient for confident invocation without additional information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description only loosely maps to the parameters ('node' and 'groups'). It does not explain node_path's expected format (e.g., full path vs node name) or whether groups are created if they don't already exist. The description fails to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to set a node's full group membership, with 'adding and removing to match the desired set' specifying that it replaces the current set. This distinguishes it from siblings like get_node_groups (read-only) and batch_add_nodes (likely additive only).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'full' modifier implies this tool is for replacing all group memberships, but no explicit alternatives or exclusions are given. The description does not state when to prefer this over batch_add_nodes or find_nodes_in_group, leaving usage context only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It does convey the color format ('#rrggbb[aa]' or 'Color(r, g, b, a)') and implies an override semantics, but it fails to mention side effects, reversibility, or what happens if the control lacks a theme. This is limited but non-empty transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that identifies the operation and then provides essential format details. It is concise with no filler, effectively using its limited length to convey the core purpose and a key parameter detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the presence of many theme-related sibling tools, the description lacks sufficient context to fully guide an agent. It does not explain how this tool differs from set_theme_constant or set_theme_stylebox, and it does not mention return values or side effects. The gaps are critical given the lack of annotations and output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions (0% coverage), so the description must clarify all parameters. It only explains the 'color' parameter format, while 'node_path' and 'name' remain ambiguous. The description does not add meaning to these two parameters, leaving a significant gap in parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add a theme color override') and the target resource ('a Control'), which distinguishes it from sibling tools like set_theme_constant or set_theme_stylebox that handle different theme property types. The verb 'Add' is specific, and the scope is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by mentioning 'on a Control' and 'theme color override', which suggests it is intended for overriding theme colors on controls. However, it does not explicitly state when to use this tool versus alternatives like set_theme_constant or set_theme_font_size, nor does it mention exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the mutation ('Add') and target ('Control'), but does not disclose side effects, prerequisites, persistence, or impact on existing overrides. This is a minimal level of transparency for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no fluff or redundancy. It communicates the core purpose immediately and efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is too terse. It does not explain what a theme constant is, the meaning of the value, or how node_path should be specified. Context is limited, leaving the agent to rely on assumptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage and the description does not explain node_path or value. It only hints at possible values for 'name' via examples. This is insufficient for a 3-parameter tool and fails to compensate for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add') and the resource ('theme constant override on a Control') with concrete examples ('separation or margin_left'). It effectively differentiates from sibling tools like set_theme_color and set_theme_stylebox by focusing on constants.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool by giving examples of theme constants, which are distinct from related theme properties. However, it does not explicitly state exclusions or alternative tools, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses one behavioral trait: the auto-prefixing of 'parameters/' when missing. However, annotations are absent, so the description carries full burden for behavioral transparency. It does not mention side effects, error conditions, or any requirements, which limits the transparency to a single helpful detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the main action and includes a useful behavioral note. There is no wasted wording, and it fits the tool's simple nature perfectly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no annotations, no output schema, and a 0% schema coverage, the description is sparse. It lacks information about prerequisites (e.g., an existing AnimationTree), error handling, and what happens after setting the parameter. For a mutation tool, this is a significant gap, making the description incomplete for an agent to use confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It adds meaning to the 'parameter' field by giving examples (condition or blend amount) and hints at the format via auto-prefixing. However, it does not clarify 'node_path' or 'value', and the compensation is partial. The description thus provides only marginal value beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: setting an AnimationTree parameter (e.g., condition or blend amount), with the specific verb 'Set' and resource 'AnimationTree parameter'. It also differentiates from sibling tools like set_blend_tree_node by focusing on the tree's parameter rather than node properties.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context—it is for setting AnimationTree parameters—but does not explicitly mention when to use this tool over alternatives or provide exclusions. The mention of 'such as a condition or blend amount' gives some context but no direct comparison with sibling tools, so usage guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It does disclose the timing behavior ('one event every frame_delay frames') and the dropped-if-no-game-running condition. However, it omits other behavioral aspects like return values, error handling, or whether a mid-sequence game stop cancels the entire batch.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the core action. Every element—ordered, batch, running game, frame_delay, dropped condition—serves a distinct purpose, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complex nested event schema, lack of annotations, and absence of an output schema, the description is too sparse. It does not explain event types, valid actions, failure behavior, or return value, leaving significant gaps for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal meaning for frame_delay (defines it as the interval between events) and calls events 'input events', but does not explain the nested event object variants, keycodes, buttons, modifiers, or defaults. With schema description coverage at 0%, this is insufficient for the highly structured events array.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb (Send), identifies the resource (running game), and specifies the scope (ordered batch of input events with timing). This clearly distinguishes it from single-event siblings like simulate_key or simulate_mouse_click.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for sending multiple events in a timed sequence, and the 'ordered batch' phrasing suggests when to prefer it over single-event tools. However, it does not explicitly state when not to use it or mention alternatives, leaving usage guidance implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosure. It adds useful context about compound value encoding (constructor strings like Vector2(100, 200) or #ff0000), which is a behavioral trait. However, it does not mention mutation effects, error behavior, or whether changes are reversible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundant words. It front-loads the primary action and then adds a necessary clarification about value encoding. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple three-parameter setter, the description gives the core operation and parameter encoding but lacks usage guidance and any detail about return values or failure modes. Given no output schema and no annotations, this is minimally viable but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explicitly explains the value parameter's format for compound types, which is essential. The node_path and property parameters are not described, but their names are largely self-evident.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Set one property on a node' clearly states the action and target. It also differentiates from sibling tools like batch_set_property by emphasizing 'one property' and from cross_scene_set_property by focusing on a node.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide guidance on when to use this tool versus alternatives such as batch_set_property or cross_scene_set_property. It does not mention preferred scenarios, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a mutating operation ('Bake') and mentions the side effect of optional 2D region rebuilding, but does not disclose details like whether existing meshes are overwritten, prerequisites, or potential performance implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that immediately states the core action and resource. It is concise, with no redundant phrases or extraneous details, effectively front-loading the most important information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's moderate complexity, the description omits key context such as whether the node must already exist, what happens if baking fails, and expected return values. There is no output schema to clarify results, and no mention of related setup steps, making it incomplete for a navigation mesh baking operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning to the 'outline' parameter by explaining it triggers 2D region rebuilding, but it does not clarify the expected format of outline items or elaborate on 'node_path' beyond its obvious schema name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Bake' with a clear resource ('navigation mesh or polygon') and scoping ('of a NavigationRegion2D/3D'). It also distinguishes this from sibling tools like setup_navigation_region by indicating this performs the actual baking computation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on the optional outline parameter ('optionally rebuilding the 2D region'), but does not explicitly state when to use this tool versus alternatives or any preconditions. It lacks explicit 'when not to use' guidance or mention of related tools like setup_navigation_region.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses one important behavioral trait: the scene root cannot be deleted. With no annotations, the description carries the transparency burden, but it does not mention that deletion is permanent or irreversible, which is significant for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the verb and includes a parenthetical constraint. Every word earns its place, with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, the description covers the core action and a key constraint. However, with no output schema, the agent is left guessing about return values and error behavior (e.g., what happens if the node does not exist), so completeness is only adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage and the description does not explain the node_path parameter format or provide examples. The name 'node_path' implies a path string, but the lack of any parameter-level semantics means the description compensates poorly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Delete' and the resource 'a node from the edited scene', distinguishing it from siblings like delete_scene. The parenthetical constraint about the scene root further clarifies the tool's scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the action: use this tool to delete nodes from the current scene. However, it does not explicitly compare against alternatives (e.g., delete_scene) or state when not to use it, so guidance is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description must carry the transparency burden. It discloses several behaviors: matching Node2D and Node3D, accepting both a position and a node path, using world units, and sorting by distance ascending. However, it does not mention behavior when no nodes are found, whether the supplied node is included, or any performance considerations for large scenes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly packed sentence that front-loads the core purpose ('List Node2D/Node3D nodes within a radius') and adds value with 'in world units' and 'nearest first'. There is no redundancy or wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, no output schema, and no annotations, the description provides a decent high-level overview but lacks coverage of filtering and result-limiting parameters. It does not explain the use of type_filter or group_filter, which are important for narrowing the search, and does not mention whether the result includes the node at the query position or how many results will be returned by default.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description is expected to clarify parameters. It does explain that 'radius' is in world units and that 'position' can be a node or coordinate object. Yet it provides no meaning for 'max_results', 'type_filter', or 'group_filter', which are present in the schema and have no explanatory text. This leaves a significant portion of the parameter surface undefined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and concrete resources ('Node2D/Node3D nodes'), and clearly defines the spatial scope ('within a radius in world units'), sorting ('nearest first'), and input flexibility ('position or node'). This distinguishes it from siblings like find_nodes_by_type or find_nodes_in_group, which are non-spatial lookups.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the usage scenario: you need to find nodes near a given point or node. However, it does not explicitly mention alternatives, exclusions, or when to prefer this over other search tools like find_nodes_by_type or find_nodes_in_group. No 'use this instead' guidance is present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It clearly conveys that the tool performs a read-only grep operation, is case-sensitive, and returns file, line number, and text. It does not mention hidden behaviors like addon handling, but the core behavior and output are transparently described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the action ('Grep') and packs purpose, scope, case-sensitivity, and output format into minimal text. Every word contributes meaning, and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core function and return format, which is adequate for a relatively simple tool with 3 parameters and no output schema. However, it fails to explain the optional parameters (path default and include_addons) and ignores the addon file exclusion behavior, leaving the description only minimally viable for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the lack of parameter documentation. It indirectly describes 'query' as a case-sensitive substring and 'path' as the project file scope, but it completely omits the 'include_addons' parameter and does not mention the default path res://. This leaves significant gaps for the agent to correctly invoke the tool with all parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('grep') and clearly identifies the resource ('project scene, script, resource and config files') and the exact behavior ('case-sensitive substring'). It distinguishes itself from siblings like find_node_references or search_files by specifying it searches file contents and returns file/line/text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives like find_node_references, search_files, or search_in_files. It implies a text-based search use case but does not state exclusions or contrast with sibling tools, leaving the agent to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It accurately lists the returned data fields, but does not explicitly state that the operation is read-only, what happens if the animation doesn't exist, or the exact structure of the response. This is a getter, so the read-only nature is somewhat implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence that front-loads the key function. It avoids filler and is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lists the data returned but omits the exact structure of the return value and fails to explain parameter semantics. Given the lack of an output schema and annotations, more detail would be needed for reliable invocation and response parsing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage and the description does not elaborate on the parameters. While 'animation' is self-explanatory, 'node_path' is ambiguous—it could refer to the path of the AnimationPlayer or the animation resource. The description does not clarify the expected format or how the parameters interact.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: retrieving a single animation's length, loop mode, step, and all track keyframe data. This distinguishes it from sibling tools like list_animations or get_animation_tree_structure, which have different scopes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when detailed info about a specific animation is needed, but it does not explicitly contrast it with alternatives like list_animations or get_animation_tree_structure. There is no 'when not to use' guidance, so the agent must infer usage from the context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It usefully lists three distinct sources (editor log file, script editor compile markers, debugger Errors tab), which adds context. However, it does not clarify whether the operation is read-only, how 'recent' is defined, whether errors and warnings are merged, or what the response format 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that conveys the tool's purpose and scope without any wasted words. It is front-loaded and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one optional parameter, no output schema), and the description covers the sources of errors. However, it omits details about the parameter and the return format, leaving the agent to guess at important behavioral specifics. It is adequate for basic understanding but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the only parameter 'max_lines', and the description does not mention it at all. The parameter's meaning must be inferred from its name and default value. Since the description fails to compensate for the low schema coverage, the agent receives no explicit guidance on this parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Collect') and identifies the exact resource ('recent editor errors and warnings') and the sources (log file, script editor compile markers, debugger Errors tab). This clearly distinguishes it from sibling diagnostic tools like get_output_log or get_editor_performance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (when you need recent editor errors/warnings) but does not explicitly state when to use this tool versus alternatives like get_output_log or get_editor_performance. It provides no exclusions or when-not-to-use guidance, but the intended context is reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses the output content (actions, deadzone, bound events) and the optional builtin inclusion, but does not mention side effects, permissions, or any caveats. It is a read-only operation, but this is inferred rather than stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with the action, no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Core purpose is covered, but the filter parameter is undocumented and there is no output schema or description of return format, leaving gaps for invocation and result interpretation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description only hints at include_builtin via 'optionally including builtin ui_* actions'. The filter parameter is completely unexplained, leaving the agent to guess its purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') plus resource ('InputMap actions') and specifics (deadzone, bound events), clearly distinguishing from sibling tools like set_input_action or simulate_action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it is for reading input mappings, but provides no explicit when-to-use guidance or comparison with alternatives like set_input_action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the read-only nature via 'List' and the filter behavior, but does not mention return format, error conditions, or whether all node types are supported. This is acceptable for a simple read operation but leaves gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no redundancy. It front-loads the core purpose and includes the optional filter in a concise way.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two parameters and no output schema, the description is mostly complete: it states the action, scope, and filter option. However, the unexplained 'category' parameter and lack of output format details leave gaps that affect completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It mentions 'filtered by name prefix' but does not clarify which parameter (category or node_path) that refers to, and the 'category' parameter is completely unexplained. This is insufficient for an agent to correctly set parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the resource ('a node's editor-visible properties'), with an additional filter option. It distinguishes from siblings like get_game_node_properties (runtime) and batch_get_properties (multiple properties) by specifying editor context and listing behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (for listing editor node properties with optional prefix filter) but provides no explicit alternatives or exclusions. It does not mention when to use this over batch_get_properties or get_game_node_properties, leaving some ambiguity for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full transparency burden. It correctly implies a read-only operation, but it does not disclose return format, error handling, or whether the node must be a GPUParticles type. For a simple read operation, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that lists the exact items being read. There is no redundant or filler text, and it is front-loaded with the action verb.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one parameter, no output schema) and the read-only nature, the description gives the essential scope of what is read. It does not describe return values, but that is not critical for a straightforward read tool. It is reasonably complete for its purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% with one parameter. The description clarifies that node_path refers to the GPUParticles node to inspect, but it does not explain path format, constraints, or how the path is interpreted. Some meaning is added, but the single parameter could use more detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Read') and clearly identifies the resource (GPUParticles node) and the specific data (emission settings, process material properties, color gradient stops). It does not explicitly contrast with sibling tools like get_node_properties, but its specificity makes its purpose clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for reading particle-related properties, but it provides no explicit when-to-use or when-not-to-use guidance, nor does it mention alternative tools. The usage context is inferable from the resource type and the sibling tools, but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only uses the verb 'Get' to imply a read-only operation, but does not explicitly state that it is non-destructive, what the return format is, or whether any project must be open. This lack of detail for a simple getter leaves the agent with uncertainty about side effects and output structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that lists exactly the six pieces of information the tool provides. Every word earns its place, with no redundant explanations or filler, making it highly efficient and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema or annotations, the description is sufficient for a simple parameterless getter by clearly enumerating the returned fields. However, it falls short of fully complete by not specifying the return format (e.g., JSON object) or any preconditions, which could be inferred from similar tools but is not explicitly stated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is trivially complete with no properties. Per the rubric, 0 params baseline is 4, and since there are no parameter semantics to explain, the description does not need to add anything beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Get') and resource ('Godot project info') and enumerates the exact fields returned: name, engine version, main scene, viewport size, renderer, and autoloads. This distinguishes it from broader sibling tools like get_project_statistics, which likely provides aggregate metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention when to avoid it or reference sibling tools such as get_autoload or get_project_settings, leaving the agent to infer applicability solely from the listed fields.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds value by specifying that output includes 'current values, Variant types and hints', but it does not disclose whether the tool is read-only, what happens with invalid paths, or any potential side effects. The 'List' verb suggests read-only, but this is implicit rather than explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the core action and resource. Every phrase contributes meaningful detail (which nodes, what is listed, output components), making it appropriately concise without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read-only tool, the description covers the main output aspects but leaves gaps: it does not clarify the 'path' parameter's exact semantics, whether the scene must be open, or what an invalid path returns. The lack of an output schema and annotations increases the need for this information, so overall completeness is only adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is only one parameter ('path') and schema description coverage is 0%, so the description must compensate. It implies the path refers to a scene file, but it does not describe expected format, file extension, absolute vs relative paths, or error behavior. This is minimal compensation at best.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and identifies a clear resource ('every node's exported script variables in a scene file'). It also distinguishes itself from sibling tools by focusing specifically on exported script variables, which is unique among the provided sibling names.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for inspecting scene file exports but does not explicitly state when to choose this tool over alternatives like 'get_scene_file_content' or 'read_resource'. No exclusions or alternative tool names are given, so it relies on the user to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses the primary action and outcome (opening a file and making it the edited scene), but it does not mention potential side effects like handling unsaved changes, closing the current scene, or error behavior. This is minimal but not misleading, so a middle score 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the action and outcome. Every word earns its place, with no redundancy or extraneous information. The structure is clear and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description covers the core behavior but omits important details such as error handling, what happens if the file doesn't exist, and whether the current scene is replaced or if confirmation is needed. It is minimally complete for basic understanding but lacks richness for an AI agent to anticipate edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'path' with no description, and the schema description coverage is 0%. The description only implies that 'path' refers to the scene file to open, but it does not clarify the expected format (e.g., project-relative vs absolute), file extension requirements, or any constraints. The description fails to sufficiently compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: opening an existing scene file and making it the edited scene. This distinguishes it from sibling tools like create_scene, save_scene, or play_scene, which have different purposes. The verb 'open' and resource 'scene file' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for opening an existing scene for editing, but it does not explicitly state when to use it versus alternatives like create_scene or delete_scene. There is no mention of exclusions or alternative tool references. The usage context is evident from the purpose, but the description lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It only states the action but reveals nothing about side effects (e.g., persistence, scope, whether a restart is needed, or what happens to currently open dialogs). This is a minimal disclosure for a state-changing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that communicates the tool's entire purpose with no wasted words. It is appropriately sized for the simplicity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple boolean setter with no output schema and one parameter, the description is largely complete. However, it could mention whether the setting persists across sessions or affects the current project, which would round out the context. Still, it covers the main action well.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It implicitly conveys that the boolean 'enabled' maps to enabling/disabling the behavior, but it does not explicitly reference the parameter name or define true/false semantics. This adds some meaning but leaves the mapping to inference.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Enable or disable') and clearly identifies the resource ('automatic dismissal of blocking modal dialogs in the editor'). It distinguishes itself from sibling tools, which are mostly about nodes, scenes, and assets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to control the editor's auto-dismiss behavior for modal dialogs, but it does not provide explicit when-to-use guidance or mention alternatives. The context is fairly obvious given the tool's purpose, but no exclusions or comparisons are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds unit context for spread and velocities, but lacks disclosure of side effects such as whether unspecified properties are preserved, whether a material is created if absent, or any prerequisites. With no annotations, the full burden falls on the description, which does not cover these aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the core purpose and key unit constraints. Every word contributes meaningful information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 22 optional parameters, no output schema, and no annotations, this one-sentence description is insufficient. It omits behavioral details about unset properties, material creation, return values, and prerequisites, making it incomplete for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning for some parameters by stating spread is in degrees and velocities use different units in 2D vs 3D. However, with 22 parameters and zero schema descriptions, this covers only a small subset, leaving many parameters semantically under-specified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it sets ParticleProcessMaterial properties on GPUParticles nodes, with a specific verb and resource. It distinguishes itself from sibling tools like set_material_3d and set_particle_color_gradient by naming the exact material type and target node.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: when needing to set ParticleProcessMaterial properties on GPUParticles nodes. It does not explicitly mention alternatives or exclusions, but the domain is well-defined. The unit clarifications help guide parameter usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It only states the action ('set') but does not mention side effects, failure modes (e.g., missing ShaderMaterial), whether the value is required, or any permissions needed. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It conveys the essential action and target in eleven words, earning a perfect score for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, no annotations, and no output schema, the description leaves critical gaps: it does not clarify whether 'value' is optional, what happens if the node lacks a ShaderMaterial, or what the tool returns. These ambiguities make it incomplete for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It implies 'param' is a uniform name and 'value' is the value to set, and 'node_path' identifies the node. However, it does not explicitly explain each parameter's role or type, and notably omits that 'value' is not required by the schema, which could confuse the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Set') and resource ('one shader uniform on a node's existing ShaderMaterial'), clearly distinguishing it from sibling tools like assign_shader_material (assigning a whole material) or get_shader_params (reading parameters). It unambiguously states the tool's core function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'existing ShaderMaterial' provides clear context that the node must already have such a material, and 'one shader uniform' implies use for setting a single param rather than replacing the material. However, it does not explicitly name alternative tools or exclusion scenarios, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the 'capped at max_count' behavior and covers both TileMapLayer and legacy TileMap nodes. However, it does not mention error handling, ordering, or what happens when max_count is exceeded beyond truncation, leaving some behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no fluff. Every word adds value, including the output format and the cap behavior, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description must explain return values. It does so vaguely with 'grid x,y with source_id', but does not specify the exact data structure (e.g., array of objects) or handling of empty results. Given the tool's simplicity, the description is minimally viable but leaves room for more detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains max_count ('capped at max_count') and implicitly clarifies node_path by referring to tilemap layer types, but it does not explain the 'layer' parameter (e.g., that it is an index within the TileMap). This leaves a significant parameter unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the specific resource 'used cells of a TileMapLayer or legacy TileMap layer'. It also specifies the output format as 'grid x,y with source_id', which distinguishes it from sibling tools like tilemap_get_cell that handle individual cells.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving all used cells from a tilemap, but it does not explicitly state when to use this tool versus alternatives such as tilemap_get_cell or tilemap_get_info. It provides no 'when not to use' guidance or naming of alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It states the action is recording signals for a duration, but does not disclose whether this is non-destructive, what happens to the recorded data, whether it blocks, or how it behaves if nodes are not live. This is a moderate disclosure but leaves important behavior unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no filler. Every word adds meaning: 'Record' is the verb, 'every signal' is the scope, 'live nodes' and 'duration in milliseconds' are key parameters. Excellent conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal for a tool with no annotations and no output schema. It does not explain what the tool returns (e.g., a log of emitted signals), whether it has side effects, or the semantics of signal_filter. Given the tool's moderate complexity (3 params, no output schema), the description leaves important gaps for an agent to understand the full behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description implicitly covers node_paths ('given live nodes') and duration_ms ('duration in milliseconds'), but does not mention signal_filter. With 0% schema coverage in the description, it partially compensates by explaining two of three parameters, but the third parameter's semantics rely solely on its name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Record'), the target ('every signal emitted by the given live nodes'), and the duration. It distinguishes this from sibling tools like connect_signal, get_signals, and analyze_signal_flow, which manage or inspect signals rather than record emissions over time.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when you need to capture signals from live nodes over a period, but it does not explicitly state when to prefer this over alternatives like get_signals or connect_signal, nor does it mention exclusions (e.g., nodes must be live). This is adequate but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavioral traits. It explicitly states 'previews by default, requires force=true to write', which discloses the preview/write mode and guards against accidental mutation. It also clarifies the operation happens 'across all scene files on disk', which is a significant behavioral scope. This is value beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One succinct sentence front-loaded with the action and scope. Every word contributes to understanding the tool's core functionality and key safety behavior. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, no annotations, no output schema), the description is too brief. It omits critical contextual details such as how path_filter and exclude_addons affect the scope, what dry_run does relative to the preview default, and what happens to existing files or unsaved changes. Complete enough for a simple tool but not for this one.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meanings. It only hints at 'force=true' and the relational mapping of 'engine class' to the 'type' parameter. Parameters like path_filter, exclude_addons, and dry_run are not explained. With 7 parameters and zero schema descriptions, this is a major gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: 'Set one property on every node of a given engine class across all scene files on disk.' This distinguishes it from siblings by emphasizing cross-scene, on-disk scope, and mass assignment of a single property. No ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (bulk property updates across scenes) but does not explicitly state when to prefer this over alternatives like batch_set_property or update_property. It provides no exclusions or prerequisites. The 'previews by default, requires force=true to write' hints at safe usage but not when to use versus not use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It states read-only behavior and the two modes (single vs. dump), which is useful but does not explain edge cases like both parameters empty, result format, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence, front-loaded with the verb 'Read', clearly communicating the action and two modes without wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only 2 parameters, no output schema, and no annotations. The description explains the core functionality but leaves gaps: no return value format, no mention of the exact meaning of 'section prefix', and no guidance on parameter combination. Adequate for a simple read tool but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning. It explains 'key' selects one setting and 'section' dumps all matching, giving some semantics. However, it does not clarify what happens when neither is provided, defaults, or parameter precedence.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads project settings, with two specific modes: by key or by section prefix. This distinguishes it from sibling tools like set_project_setting (write) and get_project_info (general info).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use key for a single setting, section for a group. However, it does not explicitly mention alternatives or when not to use this tool, nor does it clarify precedence when both parameters are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. The word 'list' implies a read operation, but it does not disclose potential prerequisites (node must have a ShaderMaterial), error behavior, or side effects. This is a minimal disclosure for a getter tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the verb and clearly identifies the resource. There is no filler or repetition, making it efficiently concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one param, no output schema, no annotations), and the description covers the core functionality. However, it lacks details about the return format, what happens if the node lacks a ShaderMaterial, or any edge cases. Given the absence of annotations and output schema, the description could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only shows node_path as a string with no description. The tool description adds context by indicating the path refers to a node and that its ShaderMaterial is the target, which is meaningful. However, it does not specify the expected syntax (e.g., Godot NodePath format) or examples, so the semantics remain partially ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (List), the resource (shader uniforms), and the scope (on a node's ShaderMaterial). It distinguishes this from siblings like 'set_shader_param' (which sets) and 'get_node_properties' (which reads general properties).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for shader uniform inspection by its read-only tone, but it does not explicitly state when to use it vs alternatives (e.g., 'use this to debug shader values' or 'use set_shader_param to change them'). No exclusions or specific prerequisites are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It conveys a non-destructive sampling behavior, but does not disclose important details such as return format, whether it blocks during sampling, or whether it operates in editor or runtime context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single well-structured sentence, front-loaded with the action verb 'Sample' and no redundant information. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, and the description only gives a high-level purpose. It does not explain what the tool returns, how results are presented, or any edge cases. For a tool with 4 parameters and no output schema, this is insufficient for an agent to use it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain individual parameters like node_path, properties, frame_count, or frame_interval. It only indirectly references properties and frames, leaving the agent to infer specifics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool samples properties of a live node over several frames to observe changes over time. This specific verb+resource combination distinguishes it from siblings like get_node_properties and batch_get_properties.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a clear use case: when you need to observe how properties change over time. However, it does not explicitly mention when not to use it or provide alternatives, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the transparency burden. It discloses blocking behavior ('wait for arrival'), the arrival radius criterion, and timeout fallback. However, it omits what happens on timeout, return values, and side effects like camera_path or player_path usage. It provides some useful behavioral detail but not comprehensive coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the core action and outcome. It is appropriately concise with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters, no output schema, and no annotations, the description is insufficient for a complex movement tool. It lacks interaction details between camera_path and player_path, the effect of run, look_at_target semantics, and failure/timeout return behavior. The outcome is only partially specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains target (node or world position), arrival_radius, and timeout, but ignores run, camera_path, player_path, and look_at_target. The schema only provides types/defaults without descriptions, leaving 4 out of 7 parameters effectively unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the verb ('walk') and resource ('the 3D player'), and specifies the objective ('toward a target node or world position') with explicit success criteria ('wait for arrival within arrival_radius, or timeout'). It distinguishes itself from sibling tools like move_node and navigate_to by focusing on player movement and blocking until arrival.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys a clear usage context: move the 3D player and wait for completion. However, it does not explicitly mention when not to use this tool or provide alternatives (e.g., navigate_to for pathfinding, move_node for moving arbitrary nodes). It lacks exclusions but gives enough context for typical movement scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It discloses key timing behavior: events are replayed 'honoring their time_ms timeline scaled by speed', which explains the effect of the speed parameter and the relative timing mechanism. It also implies a dependency on a prior recording, but does not state whether it blocks until replay completes or whether it requires the game to be in a specific state; still, the timing disclosure provides useful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense sentence that efficiently packs the core action, target, and the essential timing behavior. Every clause earns its place: 'Replay recorded input events' defines purpose, 'into the running game' specifies context, and 'honoring their time_ms timeline scaled by speed' explains scaling semantics. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 params, no output schema, no annotations), the description covers the core replay concept and timing behavior but omits important operational details: whether replay is synchronous, what happens if events are invalid, whether the game must be in play mode, and how to obtain the 'events' array from a recording. The sibling tools (start_recording/stop_recording) suggest a workflow, but the description alone leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'time_ms timeline' and 'scaled by speed', which explains the semantics of the 'speed' parameter, but it does not explain the structure of the 'events' array (e.g., items have input data and time_ms fields). The schema itself provides minimal structure (additionalProperties: {}), leaving a significant gap for the events parameter, though the description's timing detail gives partial value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Replay' and identifies the resource as 'recorded input events' into the 'running game', which clearly distinguishes it from sibling tools like start_recording/stop_recording that capture events. It states the action and the target context, though it doesn't explicitly name a sibling alternative for contrast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a context: replaying previously recorded input events into a running game, which is a clear use case. It does not explicitly state when to use this tool versus alternatives (e.g., simulate_sequence for new input sequences), but the sibling tools and the 'recorded' qualifier provide sufficient context for an agent to infer the appropriate scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals that reconfiguring an existing node is not undoable, which is a useful safety warning. However, it does not disclose other behavioral aspects such as return values, handling of omitted parameters, or scene tree side effects beyond the node itself. With no annotations, more transparency would be expected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the primary purpose and ends with a practical warning. Every part adds value, with no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (28 parameters, no output schema, no annotations), the description is too sparse. It fails to explain parameter semantics, expected behaviors when fields are omitted, or return values. The agent would need to infer too much from property names alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meanings. It only lists high-level categories (sky, ambient, tonemap, etc.) rather than explaining individual parameters like fog_density or tonemap_mode. With 28 parameters, this is insufficient to guide correct usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates or reconfigures a WorldEnvironment, listing the major setting categories. This distinguishes it from sibling tools like setup_lighting or setup_camera_3d, which target different node types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for environment setup, but does not explicitly exclude alternatives or mention when not to use it. It provides clear context by naming the node type and setting groups, though no explicit comparisons to sibling tools are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses two useful behaviors: angles are in degrees and only provided parameters are written, which implies partial updates. However, it omits important details such as error handling for non-physics-body nodes, body-type-specific parameter compatibility, or whether changes affect a running scene.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the core purpose, then uses a semicolon to add two key behavioral notes. Every word adds information, with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 17 parameters, no output schema, and no annotations, yet the description provides only a bare overview. It does not explain parameter semantics, prerequisites, or per-node-type applicability, leaving significant gaps for an agent to use it correctly on diverse physics body types.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meanings. It only notes that angles are in degrees and parameters are individually writable, but does not explain any of the 17 parameters. Many property names are self-explanatory, but enums like freeze_mode, motion_mode, and continuous_cd remain unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool configures simulation properties of existing CharacterBody2D/3D or RigidBody2D/3D nodes, using a specific verb and resource. It distinguishes from sibling tools like setup_collision or set_physics_layers by focusing on simulation-specific properties.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: it applies to existing physics bodies, implying it is not for creation or collision setup. It does not explicitly name alternatives or exclusion cases, but the scope is reasonably bounded and understood within the sibling tool set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose useful behaviors: the rectangle is inclusive and corners can be given in any order. However, it omits other behavioral details such as whether existing tiles are overwritten, how the layer parameter is used, or what the operation returns. It provides some transparency but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the verb 'fill', and includes key behavioral caveats ('inclusive', 'corners in any order') without any wasted words. It is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has 10 parameters, no output schema, and no annotations, so the description must carry significant weight. It covers only the basic rectangle-filling concept and corner parameters, but leaves out essential context like node_path, tile atlas coordinates, and layer behavior. The description is too brief for the tool's complexity, resulting in an incomplete picture for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the corner parameters (x1, y1, x2, y2) and their 'any order' property, but it does not clarify the remaining 7 parameters (node_path, layer, atlas_x, atlas_y, source_id, alternative). With schema description coverage at 0%, the description should compensate by explaining the tile-related parameters, but it doesn't, leaving most parameters semantically unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'fill' and clearly identifies the resource: an inclusive grid rectangle between two corner points, with the added detail that corners can be in any order. This distinguishes it from sibling tools like tilemap_set_cell (single cell) and tilemap_clear (empty the tilemap).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a clear use case: when you need to fill a rectangular region with a single tile. It does not explicitly name alternative tools or state when not to use it, but the context is evident from the operation described. Since it lacks explicit exclusions or alternative mentions, it falls short of a 5 but is above a 3.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It discloses two important behavioral traits: the action is undoable as a single unit, and later entries can reference earlier created nodes as parents. This adds meaningful context beyond the tool name, though it omits error handling and return behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, two sentences, front-loaded with the primary purpose, and every clause earns its place. No unnecessary information or duplication of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has moderate complexity with a nested parameter schema, no annotations, and no output schema. The description explains the core behavior and the important parenting quirk, but it does not cover parameter details, potential errors, or what is returned, leaving notable gaps for a batch operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no information about the 'nodes' parameter structure—it does not mention required 'type', optional 'name', 'properties', or 'parent_path'. The description must compensate for the low schema coverage but fails to do so.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: 'Add several nodes to the edited scene'. It also distinguishes from the sibling 'add_node' by emphasizing the batch nature and the undoable action, making it unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides context that this is for multiple nodes and that the action is undoable as one unit, implying usage when an atomic batch operation is needed. However, it does not explicitly mention when not to use it or name alternatives like 'add_node' for single-node additions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states the core behavior clearly, but it does not add context such as whether the action is reversible, whether it affects only the editor selection vs. runtime state, or if it has any side effects. For a simple clear operation, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence: 'Clear the editor scene tree selection.' It is front-loaded with the verb and target, contains no extraneous words, and every word contributes to the meaning. It is an exemplar of concise specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a trivial tool with no parameters, no output schema, and no annotations, the description provides enough information to understand the function. It could be more complete by adding a note about typical use cases or clarifying that it only affects the editor selection, but given the simplicity, it is satisfactory.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and schema description coverage is trivially 100%. Under the rubric, a tool with 0 params receives a baseline of 4. The description adds no parameter semantics, but none are necessary since there are no parameters to explain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Clear' and names the exact resource 'editor scene tree selection', making the purpose unambiguous. It naturally distinguishes itself from sibling tools like 'select_nodes' and 'get_editor_selection' by indicating the opposite action (clearing vs. getting/setting selection).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'select_nodes' or 'get_editor_selection'. There is no mention of prerequisites, typical scenarios, or exclusions, leaving the agent to infer usage solely from the action phrase.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses the selection behavior ('first visible') and the programmatic nature (bypassing the mouse), which are useful. However, it does not disclose potential side effects, what happens if no button matches, or whether the click triggers any observable outcome, leaving gaps for a state-changing operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the action, target, matching condition, and execution mode without waste. Every element earns its place, making it highly efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no output schema, the description covers the core behavior but lacks important contextual details such as the 'partial' parameter's role and error behavior when no button matches. It is adequate but not fully complete, especially considering the absent annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It meaningfully describes the 'text' parameter by explaining it matches button text, but it entirely omits the 'partial' parameter's meaning (e.g., whether it enables substring matching). This incomplete coverage leaves the agent to guess about a default-enabled parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Press'), a specific target ('the first visible button in the running game'), and a matching condition ('whose text matches'). It also clearly distinguishes itself from mouse-based simulation by stating 'programmatically rather than via the mouse', which differentiates it from sibling tools like simulate_mouse_click.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when you need to press a button without moving the mouse, as indicated by 'programmatically rather than via the mouse'. This provides clear context for selection, though it does not explicitly name alternative tools or mention exclusions, so it falls short of full alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It states the file is created on disk and the editor is not opened. However, it does not mention overwrite behavior, error handling (e.g., if the file exists), or permission requirements. These are important for a file-creating tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that starts with the action and includes all necessary differentiators. There is zero wasted wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple file-creation tool, the description covers the core behavior but omits edge-case details like file existence handling, path resolution, and the purpose of root_name. It is adequate for basic use but not fully complete given the lack of annotations and output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for all parameters. It only hints at 'root node type' (root_type) but provides no explanation of the required 'path' or the optional 'root_name'. This leaves significant ambiguity for the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'create' with a clear resource 'scene file on disk' and a key differentiator 'without opening it in the editor'. It distinguishes itself from sibling tools like open_scene or save_scene. The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use this tool (when you need to create a scene file without opening it). However, it does not explicitly state when not to use it or name alternative tools, so it lacks the explicit exclusions needed for a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses the key behavior of not running the export and returning a string. However, it does not mention error conditions, how preset selection works, or any dependencies on other tools, leaving gaps in the behavioral profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with a parenthetical clarification. It wastes no words and front-loads the most important non-execution behavior, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the basic purpose and return type, which is helpful given no output schema. However, it does not explain how to identify a preset (preset_name vs preset_index), the meaning of debug, or the need to first list presets. It is minimally viable but not fully complete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only refers to 'preset' generically and does not explain the roles of preset_name, preset_index, or debug, nor how they interact. This leaves the agent without sufficient guidance for choosing parameter values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Build the headless CLI command to export a preset.' It also explicitly distinguishes this from actually performing the export by saying 'returns the command string, does not run the export,' which separates it from sibling execution/deployment tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when you need the CLI command string rather than executing the export. It provides a clear behavioral context but does not explicitly name alternatives or state exclusions, though the non-execution distinction is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'List' implies a non-destructive read, but it does not explicitly state that it has no side effects, nor does it describe behavior for invalid paths, empty results, or whether the listing is recursive. The information given is adequate for a simple read but lacks deeper transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes to defining the tool's purpose and output fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no annotations, no output schema), the description provides the essential operation and fields returned. However, it does not specify the return format (e.g., array of objects) or error behavior, which would be helpful since there is no output schema to clarify this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only loosely ties 'node' to the node_path parameter. It does not explain the expected path format (e.g., absolute vs relative, from scene root). The parameter name is self-explanatory, but the description adds minimal semantic value beyond that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and specifies the resource: audio stream players under a node in the edited scene. It also lists the returned attributes (stream, bus, volume), making the tool's purpose unambiguous and clearly distinct from sibling audio tools like add_audio_player or set_audio_bus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies a read-only inspection use case within the edited scene. It states the scope ('under a node'), giving context for when to use it. However, it does not explicitly mention alternatives or exclusions, such as 'to modify audio, use set_audio_bus', so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden of behavioral disclosure. It reveals the log file path, that filtering is case-sensitive, and that it 'tails' the file, but it does not disclose max_lines behavior, whether it is a live/static read, or explicitly confirm it is a non-destructive read operation. This is partial but useful disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence that front-loads the verb and resource. Every element (file path, filter, case-sensitivity) earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no output schema, the description covers the core behavior well: source file, filtering, and case-sensitivity. The main gap is the absence of any mention of max_lines and its default cap, though the schema does include the default of 100, partially mitigating this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning for the `filter` parameter (case-sensitive substring) but says nothing about `max_lines` or how it caps the returned lines. The schema provides defaults, but not parameter semantics, leaving an incomplete picture.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Tail') and names the exact resource ('editor's log file (user://logs/godot.log)'), plus the precise filtering behavior. This clearly distinguishes it from sibling tools like clear_output or get_editor_errors.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (to view log lines containing a substring) but does not explicitly contrast it with alternatives or mention when not to use it. There is no guidance on how it differs from clear_output or get_editor_errors, so usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. 'List' implies a read-only operation, which is useful, but the description does not disclose whether dependencies are resolved recursively, what happens for invalid paths, or any permission requirements. The output fields (path, uid, type) are stated, but deeper behavioral traits are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that immediately front-loads the verb and object. Every word is purposeful, with no filler or redundant restatement of the tool name. It is highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 1-parameter tool with no output schema, the description is mostly complete: it states the input (scene/resource file) and the output characteristics (path, uid, type). It stops short of describing the exact return structure (e.g., an array of dependency objects) and does not cover error cases, but this level of detail is acceptable for a listing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clarifies that 'path' refers to a scene or resource file, adding meaning beyond the raw schema. However, it does not specify whether the path should be absolute, relative to the project, or a UID, leaving some ambiguity for the single parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and identifies the resource as 'scene or resource file', clearly distinguishing this tool from siblings like detect_circular_dependencies or find_node_references. It also specifies the output includes path, uid and type, leaving no ambiguity about 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when you need to know a scene or resource's dependencies, but it does not explicitly state when to use it over alternatives or mention any exclusions. No alternative tools are referenced, so the guidance remains implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It correctly implies a non-destructive read operation, but it does not disclose details such as error handling for invalid paths, encoding, or whether the text is returned as-is. This is minimal but sufficient for a simple read tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that communicates the core purpose without any wasted words. It is concise while remaining informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read operation with no output schema, the description adequately covers the tool's purpose and expected input. It does not explain return values or error conditions, but these are not critical for such a simple tool. It is complete enough for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines a 'path' string with 0% description coverage. The description adds context by saying 'scene file on disk', which clarifies that the path refers to a filesystem scene file, but it does not specify relative vs absolute paths or accepted formats. Partial compensation, but enough for a simple parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Read' and the specific resource: 'the raw .tscn text of a scene file on disk'. This distinctly identifies the tool's function and differentiates it from siblings like read_resource or read_script, which target other file types. The scope is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by specifying the target (scene files on disk), but it does not explicitly state when to prefer this tool over alternatives like read_resource or get_scene_dependencies. No exclusions or alternative tool names are given, so guidance is incomplete but not misleading.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The operation is clearly a read-only list action, which implies safety, but the description does not disclose behavior such as error handling when the file is missing, the exact return format, or whether it always reads from disk. Without annotations, the description carries some burden, and it provides partial transparency by specifying the source file and included fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that immediately states what the tool does and includes relevant details. There is no wasted information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with no parameters and no output schema, the description is mostly complete. It could mention the return format or behavior when no presets exist, but the core functionality is well covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing to describe. The baseline of 4 applies for zero-parameter tools, and the description adds no unnecessary parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (List), the specific resource (export presets in export_presets.cfg), and the fields included (platform, runnable, path). This is specific and distinguishes it from sibling tools like export_project or get_export_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as get_export_info or export_project. The description simply states what it does without any context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose key behaviors: uses random input actions, runs for a duration, and reports crashes/new errors. However, it does not warn about potential side effects (e.g., game state corruption, need for the game to be running) that one would expect for a stress-test tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence. Every phrase adds value: the action, the resource, the method (random inputs), the duration, and the expected output. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose and output, but lacks necessary context for a complete picture: no mention of prerequisites (e.g., game must be running), no clarification of the 'actions' parameter, and no guidance on potential consequences. Given the absence of an output schema and annotations, more completeness is expected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains 'duration' (seconds) but leaves 'actions' ambiguous—the description's phrase 'random input actions' refers to the general behavior, not the parameter. Since one of two parameters remains unexplained, the description insufficiently compensates for the schema's lack of detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: 'Hammer the running game with random input actions for a duration in seconds and report crashes and new log errors'. It uses a specific verb, identifies the resource (running game), and describes the output, distinguishing it from sibling simulation tools like simulate_key or run_test_scenario.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a clear usage context: stress testing a running game with random inputs over a specified duration. However, it does not explicitly mention when not to use this tool or name alternatives, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the scenario is 'ordered' and operates against the running game, and mentions optional scene launching. However, it does not disclose important behavioral traits such as whether assertion failures affect the game state, whether screenshots are saved, or whether the scene launch replaces the current scene. This leaves a moderate transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of about 20 words. It is concise, front-loaded with the primary verb and object, and every word contributes meaning. No redundant or filler content exists.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool as complex as this (with multiple step types, assertions, waits, and screenshots), the description is too sparse. It does not explain how assertions affect the scenario outcome, what happens on failure, whether the tool returns a pass/fail result or throws, or whether execution is synchronous. The schema covers parameter structure but not the runtime semantics. Given no output schema and no annotations, the description leaves critical gaps for an agent to correctly invoke and interpret the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema is rich and self-documenting, covering all step types and properties, but the description adds only a high-level overview by naming the step types and the optional scene_path concept. Since schema_description_coverage is 0%, the description does not fully compensate for low coverage, though the schema itself provides strong semantics. The description's mention of 'input/wait/assert/screenshot' and 'launching a scene' adds marginal meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Run an ordered input/wait/assert/screenshot scenario against the running game'. The specific verb 'Run', the resource 'scenario', and the enumeration of step types (input/wait/assert/screenshot) make it obvious what the tool does and distinguishes it from siblings like simulate_sequence (which likely handles only input sequences) or assert_node_state (single assertion). The optional scene launch adds further clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it is used against a running game and can optionally launch a scene first, which implicitly defines when to use this tool. However, it does not mention alternatives or exclusions (e.g., when to use simulate_sequence or run_stress_test instead), so it does not fully meet the highest bar for explicit when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that this is a mutating operation ('Set') and specifies the return value ('old and new value'), which is useful. But with no annotations, it doesn't address potential side effects, persistence, error conditions, or whether the property must already exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is a single 19-word sentence that front-loads the action and includes the key return behavior. There is no redundant or filler content, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple three-parameter setter with no output schema, the description covers the core operation and return value, but it lacks annotation-level safety info and details about path syntax or failure behavior. It is adequate but not fully complete for an agent to confidently handle edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only adds context around 'live node' and 'one property'. It doesn't explain the expected format of node_path, how property names are resolved, or how complex values are handled beyond the schema's anyOf type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Set') and clearly identifies the target resource ('one property on a live node in the running game') and the return behavior ('old and new value'). This distinguishes it from sibling tools like batch_set_property and update_property by emphasizing single-property mutation on a live/runtime node.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context: use this when setting a property on a live/running node, as opposed to editor-scoped tools. However, it does not explicitly mention alternatives or when-not-to-use cases, such as using batch_set_property for multiple properties.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description discloses the key edge case that input is dropped when no game is running, which is helpful. Since no annotations are provided, the description carries the burden, but it does not explain effects on game state, focus requirements, or whether the action toggles.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with action verb, and no unnecessary words. It conveys the core behavior and an important caveat efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool, the description covers purpose and a key edge case. However, it omits parameter semantics (especially `strength`) and does not differentiate from sibling simulation tools beyond the InputMap action mention, leaving some context gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description implies the action name and the pressed state via 'Press or release', but it does not explain the `strength` parameter or provide syntax examples. It partially compensates but leaves meaning unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action: 'Press or release a named InputMap action in the running game'. The verb is specific and the resource (InputMap action) distinguishes it from sibling tools like simulate_key or simulate_mouse_click.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context that it operates on InputMap actions in the running game, and notes the dropped-if-no-game-running condition. However, it does not explicitly mention alternatives or when not to use it, so it lacks full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description shoulders the transparency burden. It reveals the drop-if-no-game behavior, which is useful. However, it does not explain how the boolean parameters (alt, ctrl, shift, pressed) affect the event, nor whether both press and release events are sent. The 'pressed' semantics (default true) is left ambiguous, which is a notable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the action verb, includes useful examples, and adds a concise caveat. Every word earns its place; no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters, no annotations, and no output schema, so the description needs to provide substantial context. It covers the keycode parameter and the drop condition, but omits the behavior of the modifier toggles and the pressed state. For a relatively simple tool this is partially complete, but leaves an agent guessing about essential input semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides examples for the 'keycode' parameter, clarifying it expects a key name. But it says nothing about the meaning of alt, ctrl, shift, or pressed, leaving four parameters unexplained. This is inadequate for a schema with no parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Send a keyboard event'), the target ('the running game'), and provides concrete key name examples ('W, SPACE, ESCAPE or F1'). It unambiguously distinguishes itself from sibling input simulation tools like simulate_mouse_click and simulate_mouse_move by focusing specifically on keyboard input.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: this tool is for sending keyboard events to the running game. It includes an important caveat that events are dropped if no game is running, which gives practical usage guidance. However, it does not explicitly state when to prefer this over simulate_action or simulate_sequence, nor does it mention exclusions, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavior. It clearly states it is a read operation and lists the returned information, but does not mention edge-case behavior (e.g., out-of-bounds coordinates), whether it errors, or what 'alternative' means specifically. The description adds some context beyond 'read' but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately states the verb 'Read' and the resource. Every phrase contributes meaning, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations or output schema, and moderate complexity with 4 parameters. The description explains the core action and output fields but omits the 'layer' parameter semantics and details on the return structure (e.g., what 'alternative' represents). It is adequate but leaves meaningful gaps for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains x and y as grid coordinates and implies node_path is a TileMapLayer or legacy TileMap layer, but it omits the 'layer' parameter entirely and does not clarify the meaning of 'alternative' in the output. This is insufficient for a 4-parameter tool with no schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Read' and names the resource ('tile at grid x,y of a TileMapLayer or legacy TileMap layer') along with the data reported ('source, atlas coords and alternative'). This clearly distinguishes it from sibling write operations like tilemap_set_cell and tilemap_clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description communicates that this tool reads a single tile's data, implying it is for inspection rather than modification. While it doesn't explicitly name alternatives like tilemap_get_used_cells or contrast with tilemap_get_info, the context is clear enough for an agent to infer when this read operation is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations provided, so the description carries the full burden of behavioral disclosure. It only states the conversion operation and does not disclose error handling for invalid/missing UIDs, whether the operation is read-only, or any side effects. This is a significant gap for a resolver tool without annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that is concise and free of redundancy. Every word earns its place, directly communicating the core conversion task without extraneous details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one parameter, no output schema or annotations), the description covers the essential input-to-output mapping. It lacks explicit error/edge-case behavior and return type details, but for a straightforward resolver it is sufficiently complete for an agent to understand the tool's role.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines 'uid' as a string with 0% description coverage. The description compensates by clarifying that the expected format is a 'uid:// identifier', which adds essential meaning beyond the bare schema type. It could further explain the exact format requirements (e.g., prefix validation) but already provides meaningful semantic context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Resolve a uid:// identifier to its res:// project path' clearly states the specific verb (Resolve), the input resource (uid:// identifier), and the output (res:// project path). It inherently distinguishes itself from the sibling tool 'project_path_to_uid' which performs the inverse operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied: use this tool when you have a uid:// identifier and need the corresponding project path. However, it does not explicitly mention when not to use it or reference the inverse sibling tool 'project_path_to_uid' for the opposite conversion, leaving the guidance somewhat implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is the sole source of behavioral disclosure. It does disclose that the tool polls and that it has a timeout, which is useful. But it does not state what happens on timeout (e.g., returns null, throws error), whether it blocks the main thread, or what 'node exists' means exactly. These gaps leave the agent uncertain about failure behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is a single, front-loaded sentence that directly states the action, condition, and timeout. No filler or redundant wording. It earns its place completely.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description has little to leverage. It covers the core mechanics (polling, timeout) but omits return conventions, error handling, and poll_frames semantics. For a blocking operation, these are significant gaps that prevent fully confident invocation, though the tool is conceptually simple enough to remain usable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains that timeout is in seconds and node_path refers to a path, but it does not explain poll_frames at all, nor does it describe the expected format of node_path or the relationship between timeout and poll_frames. This leaves one parameter semantically undefined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Poll') and clearly states the resource ('the running game') and the completion condition ('node exists at the given path or the timeout in seconds elapses'). It unambiguously distinguishes this from sibling tools that perform direct game state mutations or queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies a wait-for-condition scenario in a running game, which gives the agent a clear context for when to use it. However, it does not explicitly mention alternatives or when not to use it, so it misses the 'exclusions' tier.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses two key behaviors: it 'changes live audio state' and requires manual saving to persist. This goes beyond the schema, though it omits details like return values or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One compact sentence, front-loaded with purpose, and every clause adds value (live state, persistence). No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters including a nested 'params' object, yet the description offers no information about how to structure params for different effect types, what 'at_position' does, or return/error behavior. It is far from complete for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It barely addresses parameters: 'bus' and 'effect_type' are implicitly clear, but 'params' and 'at_position' are not explained. The description does not provide the necessary guidance for a nested object structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource+scope: 'Add an audio effect to a bus's effect chain'. It clearly distinguishes from sibling tools like add_audio_bus (adds a bus) and set_audio_bus (likely sets properties).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: it modifies live audio state and requires manual saving to persist. It implies when to use (when adding an effect to a bus chain) but does not explicitly exclude alternatives or name them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses that the tool sets node parameters and creates a fresh material, and that it sizes the preset based on the node's dimension. This gives useful behavioral context, though it does not detail whether existing materials are overwritten or describe potential side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the action, scope, and key behavior without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no output schema, the description provides sufficient context for selecting and invoking it: what it does, what it affects, and how it adapts to node dimension. However, it lacks details on return values or error conditions, which could be inferred from sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meaning. It mentions 'preset' and 'node' but does not specify valid preset values or explain node_path beyond the implied 'node's dimension.' The scheme's enum for preset provides some structure, but the description adds little beyond that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool applies a tuned particle preset, combining node parameters and a fresh material, sized for the node's 2D or 3D dimension. This specific verb-resource pairing distinguishes it from sibling tools like create_particles or set_particle_material, which handle individual aspects of particle setup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a complete preset effect is desired, but it does not explicitly mention when to choose this over granular alternatives like set_particle_material or set_particle_color_gradient. There is no explicit 'use this instead of X' guidance, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses that the operation is a single undoable action and confined to the edited scene, which is useful. However, it doesn't describe overwrite behavior, potential failure modes, or what happens if some nodes lack the property.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with the action verb, no redundant information. Every word contributes to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core behavior and scope, but with no output schema it doesn't explain return values, errors, or edge cases. It's adequate for a straightforward batch set but leaves some operational details unanswered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It identifies type as the engine class, property as the property to set, and value as the value to set. This is helpful but doesn't elaborate on accepted formats or constraints beyond the schema's basic types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action ('Set one property on every node of a given engine class in the edited scene') with a specific verb and resource. It distinguishes from siblings like update_property (single node) and cross_scene_set_property (cross-scene).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: applies to a class of nodes, targets the edited scene, and is undoable. Though it doesn't explicitly mention alternatives, the scope and purpose imply appropriate use versus single-node or cross-scene operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses a key behavioral trait: recursion ('recursively'), and specifies the scope of the dump. It does not mention error handling or return format, but the term 'Dump' and the tool name imply a read-only inspection, which is clear enough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the verb and immediately lists the content. Every word contributes value; there is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one parameter, no output schema, and no annotations. The description covers the core action and content, but it does not specify the return format or explicitly clarify the node_path parameter. Given these gaps, it is adequate but not fully complete for an agent needing to interpret the output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, node_path, has no schema description. The description indirectly suggests that it points to an AnimationTree ('an AnimationTree's root graph'), but does not explicitly define the parameter's format or domain. Given 0% schema coverage, this partial compensation is sufficient to infer meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Dump' and identifies the exact resource: 'an AnimationTree's root graph'. It further lists the included elements ('state machine states and transitions, blend tree nodes and connections'), making it clear what the tool does and distinct from sibling tools like get_animation_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through its action ('Dump an AnimationTree's root graph'), but it does not explicitly state when to use this tool versus alternatives or mention any exclusions. No sibling tool is referenced, so guidance is indirect.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. 'List every signal declared by a node' clearly implies a read-only operation with no side effects. It also discloses the scope (open scene) and the contents of the return (argument types and current connections), which is adequate for a simple query tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that starts with the verb 'List' and contains no extra words. Every part contributes meaningful information, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with one parameter and no output schema, the description adequately conveys what the tool does and what it returns. It mentions signals, argument types, and connections, which covers the essential output. The only notable gap is the node_path format, but this is a minor omission given the intuitive parameter name.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the node_path parameter. It only refers to 'a node' without specifying the expected path format (e.g., relative vs absolute, slash-separated). The parameter name is self-explanatory but the description does not add the necessary detail to fully understand how to provide the path.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and clearly identifies the resource: 'every signal declared by a node in the open scene'. It also specifies the included details ('argument types and current connections'), which distinguishes it from sibling tools like connect_signal or watch_signals.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'in the open scene' indicates that the tool operates on the currently active scene, providing some context. However, there is no explicit guidance on when to use this tool versus alternatives like find_signal_connections or analyze_signal_flow. Usage is implied but not clearly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses important behavioral traits: the camera moves in world space and look_at is applied after rotation_degrees and overrides it. This goes beyond basic 'move' by explaining parameter interaction, though it omits fov behavior and potential defaults.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single well-structured sentence with a semicolon separating the main action from a crucial caveat. It is front-loaded and contains no extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, no annotations, and no output schema, the description covers the core operation and the key interaction between look_at and rotation. However, it leaves gaps around fov semantics, default behavior, and return values, making it minimally viable rather than comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds semantic meaning for look_at and rotation_degrees (ordering and override) and implies position via 'move', but fov is not explained at all. Parameter names and nested structures are in the schema, providing some baseline understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool moves the 3D editor viewport camera in world space, which is a specific verb + resource. It distinguishes itself from siblings like get_editor_camera and setup_camera_3d by explicitly mentioning viewport camera movement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides useful context about operating in world space and the ordering of look_at vs rotation_degrees, which helps in usage. However, it does not explicitly mention alternatives or conditions when to use this tool instead of get_editor_camera or setup_camera_3d.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses critical behaviors: fov and rotation are in degrees, look_at is a world-space target, and reconfiguring is not undoable. These go beyond the schema and help the agent understand consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single semicolon-separated sentence that is front-loaded with the purpose and followed by essential parameter clarifications. Every clause is informative, with no redundant or unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (14 parameters, no output schema, no annotations), the description is insufficient. It covers only a few key parameter details and omits explanations for most parameters, behaviors like return values, and error handling. An agent would struggle to use it correctly without additional information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning for only three parameters (fov, rotation, look_at). With 14 parameters and 0% schema coverage, the other 11 parameters (far, near, size, current, cull_mask, projection, position, etc.) are left unexplained, failing to compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb and resource: 'Create or reconfigure a Camera3D'. It also provides key details about the parameters (degrees, world-space target), distinguishing it from generic sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use the tool: when creating or reconfiguring a Camera3D. It also warns about non-undoable reconfiguration, adding context. However, it does not explicitly mention alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It discloses key behavior: it creates and attaches a child collision shape node with a built shape resource, and notes the important unit difference (2D in pixels, 3D in metres). It doesn't mention effects like replacing existing shapes, but the core operation is clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every clause adds relevant information about the action, target, and units.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 15 parameters, no annotations, and no output schema, yet the description is only one sentence. It covers purpose and units but omits parameter semantics and usage caveats, making it incomplete for such a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only adds unit context for sizes. It does not explain parameters such as points, ax/ay/bx/by, one_way_collision, depth, or the shape enum, leaving many of the 15 parameters without meaningful semantic guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Add'), a specific resource ('CollisionShape2D/3D child holding a built shape resource'), and a target ('to a physics body or Area'). This clearly distinguishes it from sibling tools like setup_physics_body or add_node.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys clear context: use this tool when adding a collision shape to a physics body or Area. It doesn't explicitly mention alternative tools or when not to use it, but the target and purpose are unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It states the core action and return value, but omits side effects (e.g., whether recording state is cleared), error conditions (e.g., calling when no recording is active), or any safety profile. This is a state-changing operation and needs more detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, concise sentence that front-loads the action and result. No wasted words, fully readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter tool, the description covers the essential purpose and return. However, it lacks details about prerequisites (e.g., must be in an active recording), failure modes, and side effects. This is a meaningful gap given the absence of annotations and output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description does not need to explain parameter semantics. Per the baseline for 0 params, a score of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Stop' with a clear resource 'input recording in the running game' and states the return value ('recorded event list'). It clearly distinguishes itself from siblings like start_recording and replay_recording.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies this is the counterpart to start_recording, but it does not explicitly state 'use after starting a recording' or mention any exclusions. Context is clear enough, though no alternatives are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully convey behavioral traits. It discloses a key behavior (does not attach the script) and states that it returns validity as data, which implies non-destructive operation. However, it does not mention error handling, require file existence, or potential side effects, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficiently worded sentence with no filler. It front-loads the core action and includes a key differentiator, earning a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description must stand alone. It gives a high-level summary but leaves 'validity as data' ambiguous—does it return a boolean, a list of errors, or an object? This incompleteness could confuse an agent interpreting the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does not explicitly describe the 'path' parameter, but with only one parameter and the tool's name and description, the meaning is largely inferable. This is adequate but not thorough.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies a concrete verb ('compile-check') and a clear resource ('GDScript file'), and adds a crucial differentiator: 'without attaching it'. This distinguishes it from sibling tools like attach_script or edit_script, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'without attaching it' implies the tool is for validation in isolation, contrasting with attach_script. However, it does not explicitly state when to prefer this tool over other script-related tools or name alternatives, so guidance is clear but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the specific outputs and the ability to analyze either a file or the edited scene, which is useful. However, it does not explicitly state that the operation is read-only, mention potential performance costs on large scenes, or clarify what 'complexity warnings' entails.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that lists the key outputs without any filler words. Every element adds value, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema, the description adequately enumerates the return content (node count, max depth, histogram, scripts, warnings) and the two input contexts. It is slightly incomplete in not specifying the exact return format or warning criteria, but it is sufficient for an agent to decide whether to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no parameter descriptions (0% coverage), so the description's phrase 'for a scene file or the edited scene' directly explains that the 'path' parameter is optional and empty means analyze the currently edited scene. This adds meaningful semantics beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reports scene complexity metrics with a specific verb ('Report') and resource ('scene file or the edited scene'). It lists concrete outputs (node count, max depth, per-class histogram, attached scripts, complexity warnings), which distinguishes it from sibling analysis tools like get_scene_tree or get_scene_dependencies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when scene complexity analysis is needed, and mentions the two modes (file or edited scene). However, it does not explicitly state when to prefer this over alternatives like get_scene_dependencies or analyze_signal_flow, nor does it provide any exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It discloses scope and output grouping, but doesn't explicitly state it's read-only/no side effects, which is left to inference from the name 'analyze'. Lacks explicit safety or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, well-structured sentence that front-loads the action and delivers all key information without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema tool, the description is quite complete: it specifies scope ('currently edited scene'), coverage ('every connected signal'), and output structure ('grouped by emitter node with target and method'). Minor gap: no return type details, but acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist; schema coverage is 100% with zero params, so baseline 4. Description doesn't need to explain parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear, specific verb+resource: maps signal connections in the current scene, with explicit output grouping (by emitter node, target, method). Distinct from siblings like find_signal_connections by scope and stated structure.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies usage for analyzing scene signals, but doesn't explicitly state when to use vs alternatives like find_signal_connections or watch_signals. No exclusions or alternative guidance provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description discloses that this is a read operation on live nodes and, importantly, that missing nodes are reported inline instead of failing, which is critical for error handling. It does not describe the response format or permissions, but covers the most essential behavioral nuance.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense sentence conveying the operation, the batching benefit, and a key edge case, with no redundant words. It is perfectly sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core behavior and the missing-node edge case, but with no output schema and no parameter detail, the agent may not know the expected request/response structure. It is adequate for a simple batch read but leaves notable gaps for a tool with a nested parameter schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description fails to explain the structure of the nodes parameter: that each item requires node_path and optionally a list of properties to fetch. The agent cannot infer the request format or the meaning of the 'properties' field from the description alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads properties from multiple live nodes in a single round trip, and explicitly calls out the missing-node behavior, distinguishing it from sibling write tools like batch_set_property and the singular get_node_properties.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context for when to use this tool: when you need to read properties from several nodes at once and want to minimize round trips. However, it does not explicitly mention alternatives like get_node_properties for single-node reads or state exclusions, but the batching benefit is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description communicates the core behavior: it creates a duplicate of the node including its children, under the same parent, within the currently edited scene. It doesn't detail side effects like naming or the exact copy semantics, but for a simple duplication operation this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that conveys the essential information without any extraneous detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple tool with two parameters and no output schema or annotations. The description covers the high-level purpose but omits parameter semantics and any details about what the tool returns or how it affects the scene beyond duplication. It is minimally adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meanings. It does not explain 'node_path' (the path of the node to duplicate) or 'name' (optional name for the duplicate). The description only vaguely refers to 'a node', leaving parameter usage unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (duplicate), the target (a node), and the scope (with children under the same parent in the edited scene). This distinguishes it from siblings like add_node, delete_node, or move_node.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for when to use the tool: duplicating a node and its children while keeping the same parent. It does not explicitly mention alternatives or exclusions, but the context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It discloses important behavioral traits: inheritance-aware matching and the exclusion of script class_name. It does not cover return format or recursive behavior, but it adds significant value beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a front-loaded verb, direct purpose, and a useful qualifier. There is no unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the core search criterion and a key limitation, but omits details about the `recursive` parameter, possible values for `type`, and the return format. Given the tool lacks annotations and an output schema, this is a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only indirectly implies that `type` refers to an engine class name. No detail is given about the format of `type` or the `recursive` parameter, leaving the agent to infer.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (find nodes) and the specific filter (engine class type), and explicitly differentiates from script class matches, which distinguishes it from similar tools like find_nodes_by_script.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear exclusion by stating that script class_name values do not match, which helps the agent know when not to use this tool. However, it does not explicitly name an alternative tool, so it falls short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the core operation and scope ('edited scene', 'belongs to a group') but does not disclose return format, traversal behavior (e.g., recursive vs. direct children), or edge cases like groups on instanced scenes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, straightforward sentence with no redundant words. It front-loads the verb and object, making the purpose immediately clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one parameter and no output schema, the description covers the essential information: it finds nodes in a group within the edited scene. The return value is implicitly 'every node' matching the condition, which is reasonably complete, though it doesn't specify the node representation (e.g., paths vs. IDs).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a single required string parameter 'group' with no description (0% coverage). The description clarifies that this parameter refers to the group name nodes must belong to, which adds essential meaning. However, it does not provide format details such as case sensitivity or group path syntax.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Find every node') and the resource ('in the edited scene that belongs to a group'). It distinguishes from sibling tools like find_nodes_by_type and find_nodes_by_script by focusing on group membership.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when you need to locate all nodes in a group within the current scene, but it offers no explicit guidance on when to choose this over similar tools or when not to use it. No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It specifies what information is returned and implies a read-only operation, but does not disclose potential failure modes (e.g., missing Godot installation) or state that it has no side effects. This is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, tightly worded sentence that front-loads the verb and resource, listing the exact data returned. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fully covers the tool's purpose and output for a simple getter with no parameters and no output schema. It could arguably specify the return format, but the listed items give sufficient context. Minor gap: no context on when to use or error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the description needs to explain nothing about input semantics. The schema is empty, so there is no gap. Baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves export environment information and enumerates three specific items (Godot executable, project path, export templates directory), distinguishing it from siblings like list_export_presets and export_project.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage via its name and purpose but provides no explicit when-to-use guidance or comparison with alternatives. It does not mention when to choose this over list_export_presets or get_android_preset_info.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. 'List' implies a read-only operation with no side effects, but the description does not disclose details like return format, ordering, or whether unsaved/in-memory scripts are included. It gives basic transparency but leaves behavior underspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes to defining the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only query, the description is largely complete. However, without an output schema, it does not state the return format (e.g., array of script paths) or behavior for an empty editor, which would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters and the schema is empty with 100% coverage, so no additional parameter documentation is needed. The description adds no parameter semantics, but the baseline for a no-parameter tool is appropriately 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and a precise resource ('scripts currently open in the Godot script editor'). It clearly distinguishes itself from sibling tools like list_scripts by focusing on the editor's open state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its use case (when you need currently open scripts) but does not explicitly mention alternatives or when not to use it. It lacks comparisons to sibling tools like list_scripts or read_script, so the guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the output format and downscaling constraint, but does not mention potential errors (e.g., unsupported formats), whether the operation is read-only, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that includes all critical information without unnecessary words. It describes action, target, output, and constraint efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool, the description covers the essential output (base64 PNG) and constraint (max_size). Given no annotations or output schema, it could mention error handling or return format details, but is sufficiently complete for basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description compensates well by explaining max_size ('downscaled so its longest side is at most max_size pixels') and implying the path is the resource identifier. However, it could be more explicit about the path's accepted formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description has a specific verb ('Render'), a clear resource ('an image or texture resource'), and a well-defined output ('base64 PNG'). It also includes the downscale behavior, making it distinct from sibling tools like read_resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (generating a preview image) but does not explicitly state when to use this tool over alternatives like read_resource or edit_resource, nor does it mention any exclusions or preconditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It discloses the scope of what is read (assigned theme plus overrides and their categories), but it doesn't mention return format, error behavior, or whether inherited themes are resolved. This is acceptable but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word adds value, listing the exact categories of theme overrides.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one parameter and no output schema, the description is fairly complete: it states the resource, the scope (including all overrides), and the categories. It could be improved by explicitly documenting node_path and potential error cases, but it's sufficient for basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and there is no parameter description. The description implies 'node_path' should point to a Control node, but does not explicitly state it. It adds some meaning but leaves the parameter under-documented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Read' and clearly identifies the resource: a Control's assigned theme plus all overrides (colors, constants, font sizes, styleboxes). This distinguishes it from sibling tools that set or create themes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes it clear when to use this tool: when you need to inspect a Control's theme and overrides. It doesn't explicitly mention alternatives, but the read-vs-write distinction from sibling setters is obvious from the word 'Read'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavior disclosure. It indicates a read-only list operation and details return fields, but it does not address invalid node_path behavior, whether node_path must point to an AnimationPlayer, or if non-default libraries are excluded. Some key edge cases are left undefined.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence that front-loads the verb and resource, with no filler or repetition. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description covers the essential operation and return data. It could include more on error conditions or usage scenarios, but it is sufficiently complete for a straightforward listing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Since schema description coverage is 0%, the description must clarify the parameter's meaning. It does so by stating the tool works on 'an AnimationPlayer's default library,' strongly implying node_path is the path to an AnimationPlayer node. This compensates for the lack of schema details, though it could be more explicit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists animations from an AnimationPlayer's default library and specifies the included attributes (length, loop mode, track count). It uses a specific verb and resource, distinguishing it from siblings like get_animation_info or add_animation_track.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its use for inspecting animations in a player but does not explicitly state when to choose it over alternatives like get_animation_info or remove_animation. There is no mention of exclusions or specific scenarios, making the usage guidance merely implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It only says 'Run the project' and 'play that scene' without mentioning side effects (e.g., whether it stops the currently running scene), return values, or prerequisites. This is a significant gap for a tool that launches the game.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that leads with the main action ('Run the project') and supplies necessary detail in a concise manner. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, the description is adequate, but it lacks important contextual details: what happens if an invalid scene path is given, whether the current scene is stopped first, and whether it blocks or returns immediately. These gaps make it only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'mode' with no description (0% coverage). The description fully compensates by explaining the valid values: 'main', 'current', or a res:// scene path. This adds crucial meaning that the schema lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Run') and resource ('project'/'scene'), and enumerates valid modes ('main', 'current', or a res:// path). This distinguishes it from siblings like stop_scene and run_test_scenario.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool by listing the three modes of operation, implying it is for running the project or a specific scene. However, it does not explicitly exclude alternatives or name other tools, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It discloses that the tool mutates collision_layer and collision_mask, supports bitmask integers or lists of layer numbers 1-32, and targets collision objects/areas/raycasts. However, it does not state whether properties are overwritten or merged, validation behavior for invalid inputs, or side effects on existing physics setup.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly packed sentence that conveys the action, the affected properties, target node types, and accepted input formats. No wasted words; front-loaded with the verb and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with no output schema, the description is sufficient: it identifies the target nodes, the properties to set, and the accepted value formats. It lacks only minor details like return value (likely none) or error conditions, but these are not critical given the low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no descriptions (0% coverage), so the description must compensate. It explains collision_layer and collision_mask as bitmask ints or lists of layer numbers 1-32, which is meaningful beyond the schema's generic anyOf integer/array. It also indicates optionality via 'and/or', though node_path is not explicitly described (implied as the target node).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Set' and clearly identifies the resources being modified: collision_layer and/or collision_mask on a collision object, area, or raycast. It distinguishes itself from sibling tools like get_physics_layers or setup_collision by naming the exact properties and target node types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for setting collision layer/mask properties on specific node types, but it does not explicitly state when to use it over alternatives or mention exclusions. There is no direct comparison to sibling tools like setup_collision, so usage context is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tree is active, has a state machine root, is parented, and wired to an AnimationPlayer, but it does not explain potential side effects like whether existing nodes are overwritten, prerequisites such as a valid parent path, or whether the operation requires an open scene. This leaves some behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, actionable sentence with no filler. It front-loads the main action 'Add an active AnimationTree' and packs necessary detail into a compact form.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's side-effect nature and the lack of annotations and output schema, the description provides a basic understanding but omits important context: whether node_path must already exist, what 'active' means at runtime, and what the tool returns (if anything). A more complete description would mention prerequisites and potential failure modes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions are absent (0% coverage), so the description must clarify parameters. It does: 'parent node' implies node_path, 'wire it to an AnimationPlayer' maps to anim_player, and 'state machine root' provides context for the node's setup. The name parameter is not explicitly tied to the node name, but the description implies the created tree's identity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb 'Add' and the resource 'AnimationTree', with precise details about the state machine root, parent node, and connection to an AnimationPlayer. This distinguishes it from sibling tools like add_animation_track or get_animation_tree_structure, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its use case: creating a new active AnimationTree with a state machine root and wiring it to an AnimationPlayer. While it provides clear context, it does not explicitly state when to use this tool over alternatives or mention any exclusions, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the behavioral disclosure burden. It states the tool is advisory only, never auto-deletes, and warns about false positives (uid:// and dynamic references). This is excellent transparency about the tool's non-destructive nature and limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence that front-loads the core action ('List resource files under a path...') and appends important caveats. It is concise but slightly verbose with the em-dash phrase, making it less elegant than it could be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, scope, and key guardrails, which is largely complete for a listing tool. However, it omits the meaning of the include_addons parameter and does not describe the output format, which would be useful given the absence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not clarify the parameters. It indirectly references 'path' via 'under a path', but says nothing about 'include_addons'. The parameter names are self-explanatory, but the description fails to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and clearly identifies the resource ('resource files under a path') and the criterion ('no scene, script or config file text-references'). It distinguishes itself from siblings like find_node_references and find_script_references by focusing on unused resources rather than locating references.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage cautions: 'advisory only', 'uid:// and dynamic references are false positives', and 'never auto-delete'. These clearly tell the agent when it is safe to use and how to interpret results, though it does not explicitly name alternative tools for similar tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that the tool reads two specific properties and decodes them bit-by-bit with project physics layer names, implying a non-destructive operation. This is sufficient for a simple getter, though it doesn't detail edge cases or return structure beyond the decoding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the core action and key detail about layer name decoding. Every word adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description does hint at the output by mentioning bit-by-bit decoding with layer names, which suggests a mapping of bits to names. For a low-complexity tool with one parameter, this is reasonably complete, though it could explicitly state the return format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter (node_path) with no description, and schema coverage is 0%. The description only says 'of a node' without explaining the path format or expected syntax, leaving the agent to infer NodePath conventions. This fails to compensate for the missing parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Read collision_layer and collision_mask of a node' with a specific verb and resource. It also adds the unique decoding behavior with physics layer names, distinguishing it from siblings like set_physics_layers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for reading collision properties, which is clear from the verb 'Read' and the property names. It does not explicitly exclude alternatives or mention when to use set_physics_layers, but the read versus write contrast is evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden of disclosing behavior. It explicitly warns that changes are 'live' and that persistence requires manual layout saving, which are crucial behavioral traits. It does not cover details like error handling or reversibility, but the core transparency about non-persistent mutation is well addressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the primary action and object, then appends the two most important behavioral notes. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description must cover both usage and behavioral context. It successfully conveys the purpose, live mutation, and persistence caveat. However, the tool has 7 parameters and moderate complexity, and the description doesn't clarify parameter roles (identifier vs new name) or expected value formats, leaving gaps for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description groups parameters into categories ('volume, flags, send target or name') that map to schema properties (volume_db, mute/solo/bypass_effects, send, rename). This adds meaning beyond the bare schema names. However, with 0% schema description coverage and 7 parameters, it leaves room for ambiguity—e.g., it doesn't clarify that 'name' is the identifier while 'rename' is the new name, or specify unit for volume_db. Thus it partially compensates but not fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Update an audio bus's volume, flags, send target or name', clearly stating the action (update) and the resource (audio bus) along with the affected attributes. This distinguishes it from sibling tools like add_audio_bus (create) and add_audio_bus_effect (effect-specific). The mention of live audio state further clarifies its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'changes live audio state; save the bus layout manually to persist' gives strong contextual guidance about when to use this tool: for immediate modifications that require manual persistence. However, it does not explicitly mention alternatives or when not to use it (e.g., for adding a new bus), so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly reveals that omitted params reset to class defaults and that it replaces any previous override, which are key behavioral traits. It stops short of detailing side effects like texture loading or reversibility, but the core behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the main action and then adds critical behavioral details after the dash. Every word contributes value, with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and 15 parameters, the description provides the essential conceptual model: it creates a fresh material, resets omitted parameters, and replaces previous overrides. It does not cover return values (no output schema exists) or specific per-parameter interactions, but the core semantics and the required node_path are indirectly clear. Minor gaps prevent a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meaning, but it does not explain any of the 15 parameters. The generic statement about omitted params resetting to defaults is helpful at a high level, but it leaves all specific parameter semantics (e.g., cull_mode, emission_energy) to the schema, which only provides names and types, not operational meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action: setting a fresh StandardMaterial3D as a MeshInstance3D surface override. It uses a specific verb and resource, and distinguishes itself from sibling material tools like assign_shader_material by emphasizing 'fresh StandardMaterial3D' and 'surface override'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies clear usage context: use when you need to apply a new StandardMaterial3D to a MeshInstance3D surface, especially replacing an existing override. It does not explicitly list alternatives or when-not-to-use, but the context is strong enough to guide selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It adds the 'exactly one' constraint and implies the bitmask is replaced wholesale, but it does not state behavior when the node path is invalid, when more than one input is provided, or whether the operation is reversible. These gaps are notable for a mutating tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the verb and object, specifies input formats, and adds the 'exactly one' constraint without any wasted words. Every component contributes to understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and lack of output schema, the description covers the primary use and main constraints. However, it omits error handling, prerequisites for the target node, and the effect on existing layer settings. For a mutation tool with no annotations, these are important contextual gaps, but the description is adequate for a basic understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description maps the parameters layers, layer_bits, and layer_names to raw mask, 1-based bit numbers, and project layer names, and clarifies their mutual exclusivity. This compensates for the complete lack of schema descriptions. However, node_path is not explicitly described, though its meaning is inferable from the 'navigation region or agent' phrase.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: setting the navigation_layers bitmask on a navigation region or agent. It also lists the three accepted input formats (raw mask, 1-based bit numbers, project layer names), allowing easy distinction from sibling tools like setup_navigation_region or setup_navigation_agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to 'give exactly one' of the three layer specification methods, which is a critical usage rule for this tool. It implies the context of modifying an existing navigation region/agent, but does not name alternative tools or explicitly state when this tool is preferred over setup_navigation_region or setup_navigation_agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It usefully reveals that the click auto-releases to fire UI buttons and that the event is dropped if no game is running. However, it does not clarify behavior for edge cases like pressed=false, double_click, or the exact timing of events.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the action, target coordinates, and two key behavioral details without redundancy. Every clause contributes useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description gives essential context (running game, viewport coordinates, auto-release) but omits details about parameter interactions and return behavior. Given the tool has six parameters and no output schema or annotations, the description is only moderately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning for x/y as viewport pixels and for auto_release via 'auto-releasing', but leaves button, pressed, and double_click semantics undefined. With 0% schema description coverage, this is only partial compensation for the six parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: clicking a mouse button at viewport pixel coordinates in the running game. It distinguishes itself from sibling input tools like simulate_key and simulate_mouse_move by specifying click behavior and coordinate targeting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool—clicking in a running game to trigger UI buttons—and implies it should be used for mouse clicks rather than keyboard or movement simulation. It does not explicitly mention alternatives or when not to use, but the context is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden. 'List' clearly indicates a read-only operation, and the description discloses the exact data returned (volume, routing, flags, effect chain). It does not mention side effects or permissions, but for a list operation this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that uses an active verb and succinctly enumerates the returned fields. Every word adds value; there is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description adequately communicates the tool's purpose and the substance of its return value. It could be more explicit about the exact output format (e.g., array of bus objects), but for a simple list operation the coverage is good.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is empty, which is fully covered by the schema. The description correctly adds no parameter semantics. The baseline of 4 applies for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') with a clear resource ('every AudioServer bus') and lists the exact data returned (volume, routing, flags, effect chain). This distinguishes it from sibling audio tools like set_audio_bus or add_audio_bus_effect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: when you need an overview of all audio buses with their settings, this is the tool. However, it does not explicitly mention when not to use it or contrast with alternatives like get_audio_info or set_audio_bus, so the guidance is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses two key behavioral traits: empty save_path returns base64 and non-empty writes to disk. This is important because it reveals the output mode and file system side effect without relying on annotations. It does not detail the exact structure of the returned base64, but that is a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description fits in a single sentence, starting with the action and then providing a clean conditional clause. Every word serves a purpose, making it highly concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description covers the essential decision logic (base64 vs file) and identifies the target (editor window). A clearer statement about the exact return format of the base64 would improve completeness, but overall it is adequate for successful invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description successfully explains the sole parameter's role: save_path controls whether the screenshot is returned inline or written to disk. This adds essential meaning beyond the raw schema definition, though it could specify path format requirements.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Capture' and clearly states the resource: 'PNG screenshot of the Godot editor window'. This distinguishes it from sibling tools like get_game_screenshot, which target the game view, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is implied from the phrase 'editor window', which suggests using this tool when an editor screenshot is needed. However, it does not explicitly name alternatives or state when not to use it, leaving some ambiguity in tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must carry the burden. 'List' strongly indicates a non-destructive operation, and it details what will be returned (settings, layers). However, it doesn't explicitly mention side-effect absence or error behavior, but for a listing tool this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no redundant words, front-loaded with the verb, and structured to enumerate all the items included. Every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description must convey what is returned. It does list the categories (regions, agents, settings, layers) sufficiently. Some ambiguity remains about output structure, but for a straightforward listing tool this is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter (node_path) with 0% description coverage. The description partially compensates by saying 'under a node', clarifying that node_path is the target for the listing. However, it doesn't specify path format or traversal semantics, so it only partially adds meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and clearly specifies the resources: navigation regions, agents with their settings, and named navigation layers. This distinguishes it from sibling tools like setup_navigation_region or bake_navigation_mesh, which modify rather than inspect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The read-only nature is clear from 'List', implying use when you need to inspect navigation setup. It doesn't explicitly state when not to use or name alternatives, but the context among sibling mutation tools makes the intended usage obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the output is a raw dump, units for time/memory/VRAM, and filtering behavior. It does not explicitly state read-only or no side effects, but 'dump' implies non-destructive. The 'not a running game' clarification adds context but more explicitness would be better.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the core action, then units, then filter. Every clause adds value with no filler. Excellent conciseness for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with no output schema, the description covers key aspects: what it dumps, scope, units, and filtering. It could be more explicit about the output format (e.g., a map of key-value pairs), but 'key prefix' implies a dictionary. Given the tool's simplicity, this is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'category' with no description (0% coverage). The description's phrase 'optionally filtered by key prefix' directly explains the purpose of the 'category' parameter, adding essential meaning beyond the schema and compensating for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Dump' and the resource 'raw Performance monitors of the editor process', and explicitly scopes it to the editor process (not a running game). This distinguishes it from sibling tools that might target game performance or high-level statistics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides context that this is for the editor process, not a running game, and mentions optional key prefix filtering. However, it does not name alternative tools for game performance or specify when not to use it beyond the 'not a running game' parenthetical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool reads from adb ('visible to adb') and lists the specific device attributes. It does not hide any side effects (reading is safe) and provides enough context about behavior, though it could mention that it returns no devices if none are connected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence (13 words) that is front-loaded with the verb and resource, and includes all necessary information without any redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
As a simple listing tool with no parameters and no output schema, the description adequately covers the purpose and return fields (serial, state, product, model). It could enhance completeness by describing the output format (e.g., list of dictionaries), but that is not critical for this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is empty, so the baseline is 4. The description does not need to explain parameters, and it correctly describes the output instead.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'Android devices visible to adb', with explicit output fields (serial, state, product, model). This distinguishes it from sibling tools like 'deploy_to_android' or 'get_android_preset_info', making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when you need to see connected Android devices via adb, but it does not explicitly state when to use it versus alternatives, nor does it mention any prerequisites or exclusions. Usage context is inferred but not directly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The word 'Read' explicitly signals a non-destructive, read-only operation, and 'full source code' indicates the complete return value. With no annotations present, this description carries the burden of disclosing behavior and does so effectively, though it omits details on error handling or path requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly worded sentence with no redundancy. The key action and object are front-loaded, making it instantly scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one parameter, the description covers the essential return value (full source code) and purpose. It lacks edge-case details like missing files or path formats, but given the tool's low complexity, the description is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'shader file', which clarifies that the 'path' parameter points to a shader file, but it does not specify accepted path formats (e.g., res://, absolute, file extension). Since schema coverage is 0%, the description should compensate further to fully define the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Read' and identifies the resource as 'shader file', making the tool's function immediately clear. It distinguishes itself from siblings like edit_shader (modifies) and get_shader_params (reads parameters only) by adding 'full source code'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies the tool is for retrieving the complete shader source, which provides context for when to use it. However, it does not explicitly discuss alternatives or conditions for not using this tool, such as when only parameters are needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It discloses an important safety behavior: it refuses to overwrite a scene open in another inactive tab, and clarifies the save-as option. However, it does not mention what happens on success, whether it overwrites the current file when no path is given, or any error conditions, leaving some gaps in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the core purpose ('Save the currently edited scene') and then adds the optional save-as and refusal behaviors. Every word earns its place; there is no verbosity or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description is largely complete. It covers the main action, the optional save-as mode, and a key safety constraint. It lacks details like return values or error handling, but these may not be critical for a save operation given the simplicity of the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema defines a single 'path' parameter with a default value but no description, giving 0% schema coverage. The description compensates by explicitly explaining the parameter: 'optionally to a new res:// path (save-as)'. This clarifies that the path is for save-as and is optional, but it doesn't elaborate on what happens when path is empty, which is implied. Overall, strong compensation for a single parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Save the currently edited scene'. It specifies the exact resource (currently edited scene) and action (save), and distinguishes it from sibling tools like open_scene, create_scene, and delete_scene by its focus on saving rather than creating, opening, or deleting scenes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: it is for saving the currently edited scene, with an optional save-as behavior via a new res:// path. It also mentions a constraint (refuses to overwrite a scene open in another inactive tab), which helps the agent avoid errors. However, it does not explicitly mention when not to use this tool or name alternatives, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses two distinct output modes: empty save_path returns base64, otherwise writes to disk, and it specifies the PNG format. However, it doesn't cover error cases or whether file mode returns a confirmation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence front-loads the action and format, then clearly states the conditional behavior. No filler or redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with no output schema, the description covers the essential behavior: what is captured, what is returned, and how the parameter controls the output mode. This is complete given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines save_path as a string with default ''. The description adds critical semantics by explaining that an empty value triggers base64 return while a non-empty value writes to disk. This fully compensates for the 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Capture' and resource 'PNG screenshot of the running game's viewport', clearly distinguishing it from sibling tools like get_editor_screenshot. The scope is explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for capturing game viewport screenshots but does not explicitly mention alternatives (e.g., get_editor_screenshot) or state when not to use this tool. Usage is implied, not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing side effects. It explicitly notes that the WebSocket connection drops briefly and auto-reconnects, which is a valuable behavioral trait for the agent to anticipate. This goes beyond a simple 'reload' statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the primary action and adds the key side effect. Every word earns its place; no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters and no output schema, the description fully covers the necessary information: what it does and the notable consequence (connection drop). No additional context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description does not need to explain any parameters, and the schema fully covers the empty parameter set (100% coverage).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (reload) and the specific resource (Godot MCP Bridge plugin), which distinguishes it from sibling tool reload_project. It is unambiguous and specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for reloading the plugin but does not explicitly state when to use it versus alternatives like reload_project. The behavioral note about the WebSocket dropping gives contextual hints but no direct when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the read-only nature ('List') and the output format ('flat ... rows'), plus the filtering behavior. This goes beyond a bare 'find' description, though it doesn't discuss edge cases like empty results or invalid inputs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads the primary action ('List every signal connection'), then output format, then filters. Every phrase adds value with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (2 optional filters, no output schema), the description adequately covers purpose, output format, and filtering. It does not detail error handling or empty-result behavior, but for a straightforward list tool this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description explicitly explains both parameters: filtering by 'signal name' maps to signal_name, and 'source path substring' maps to node_path. This compensates for the missing schema descriptions, though it doesn't state defaults or matching exactness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' with a clear resource 'every signal connection in the edited scene' and defines the output as 'flat source, signal, target and method rows'. This distinguishes it from siblings like connect_signal or analyze_signal_flow, which have different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies usage: it is for enumerating all signal connections, optionally filtered by signal name or source path. However, it does not explicitly mention alternatives or when not to use it, though the purpose itself differentiates it from mutation and analysis tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden. It discloses the output fields and the verb 'Get' strongly implies a read-only operation with no side effects. However, it does not explicitly state that it does not modify anything or mention potential error conditions, but for a simple getter this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently lists the returned attributes with no filler words. Every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description must explain what the tool returns. It enumerates the key attributes (position, rotation, fov, clip planes), but does not specify the return structure (e.g., dictionary keys) or edge cases (e.g., missing camera). Still, it is largely complete for a simple getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is empty. According to the rubric, a baseline of 4 is appropriate for zero-parameter tools, and the description does not need to add parameter information since there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and clearly identifies the resource ('3D editor viewport camera') along with the exact data returned (global position, rotation in degrees, fov, clip planes). It is unambiguous and naturally distinguishes from sibling set_editor_camera.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its usage: it is for retrieving the editor camera's properties. It does not explicitly mention alternatives or exclusions, but the context is clear enough for an agent to know when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the responsibility of disclosing behavior. It explicitly states that omitting the layer clears every layer, which is a critical destructive side effect. The legacy TileMap distinction also adds useful context. It doesn't mention reversibility or errors, but the core behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the action, resource, and the conditional behavior of the layer parameter. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple destructive operation with no output schema and no annotations, the description covers the essential behavior and parameter semantics well. It lacks explicit error handling or return value details, but these are not critical for understanding the tool's purpose and usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only names and types with zero description coverage. The description adds crucial meaning to the layer parameter by explaining its role (specific layer vs all layers). The node_path parameter is implicitly the target node, which is reasonably inferable. This compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Clear') and the resource ('TileMapLayer' or legacy 'TileMap'), and distinguishes behavior based on the layer parameter. This makes it easy to understand what the tool does and differentiates it from sibling tools like tilemap_set_cell or tilemap_get_cell.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on how to use the tool: specify a layer to clear that layer, or omit it to clear all layers. While it doesn't explicitly compare to alternatives or state exclusions, the conditional usage is well explained, which is sufficient for this straightforward tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It clearly discloses the mechanism (printing blank lines) and the non-destructive nature ('nothing is deleted'). This is strong transparency for a simple zero-parameter tool, though minor details like scroll impact are not mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the action and includes the essential qualifier. Every word contributes; no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema tool, the description is fully complete: it explains what it does, how it does it, and the key safety aspect. There are no missing behavioral details that would impact an agent's invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema covers 100% of them (vacuously). Per the baseline for 0 params, a score of 4 is appropriate; the description does not need to add parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Push old content out of view') and a specific resource ('editor Output panel') with a method ('printing blank lines'). It is distinct from siblings like get_output_log or clear_editor_selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (clearing the output panel without deleting content) and the 'cosmetic only' qualifier clarifies the effect. However, it does not explicitly name alternatives or exclusionary conditions, but the purpose is clear enough to infer when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly reveals the search scope (scene, script, resource, shader files) and the output limitation (up to 5 line numbers per file). It does not state that the operation is read-only or address case sensitivity, but for a search tool the key behavior is adequately covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action ('Search'), and contains no filler words. Every phrase earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter search tool with no output schema, the description fully covers both the input semantics (substring) and the return value (matching files with line numbers). It is self-contained and leaves no major gaps for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only defines a string parameter 'pattern' with no description. The description clarifies that this pattern is treated as a literal substring, which is important semantic information distinguishing it from regex or glob. This compensates for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Search' and clearly defines the resource scope ('all project scene, script, resource and shader files') plus the output format ('matching files with up to 5 line numbers each'). This differentiates it from sibling tools like find_script_references (which only targets scripts) and search_files (which lacks this file-type scope).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: whenever you need to search a literal substring across the specified project file types. It does not explicitly name alternatives or exclusions, but the scope itself implies appropriate usage, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden. It discloses the exact metrics returned and the scope (editor process vs game). It doesn't mention side effects, but the verb 'Get' implies a read-only operation, making it reasonably transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately states what the tool does and enumerates the metrics. Every word earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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 fully specifies what the tool returns by listing the exact metrics. This is complete for the agent to decide when to invoke it and what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero parameters, so the baseline is 4. The description adds no parameter info, but none is needed since there are no parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and resource 'performance digest of the editor process', clearly distinguishing it from game performance tools by adding 'not a running game'. The metric list (fps, frame time, draw calls, etc.) makes the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by stating it's for the editor process, not a running game, which guides usage. However, it doesn't explicitly name alternative tools like get_performance_monitors or state when to prefer one over the other, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses an important behavioral trait: mouse motion is recorded unfiltered and can be voluminous. This warns the agent about potential large data, which is valuable beyond just 'start recording'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence. The core purpose is stated first, followed by a brief caution. Every word earns its place, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters, no output schema, and a simple start action, the description provides sufficient context. It explains what happens (starts recording) and adds a relevant side-effect warning. The sibling list further clarifies the recording workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds no parameter details (there are none to add), but the schema already covers the empty parameter set completely.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Start recording') and clearly identifies the resource ('player input events in the running game'). It distinguishes from siblings like 'stop_recording' and 'replay_recording' by focusing on the start action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: this tool is for starting input capture, with a warning about voluminous mouse motion data. While it doesn't explicitly name alternatives, the sibling tool names (replay_recording, simulate_mouse_move) imply the workflow. No exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosure. It transparently mentions the side effect of cleaning up bridge IPC temp files, which is additional behavioral context beyond simply stopping the game.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that efficiently conveys both the primary action and the cleanup side effect without any redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, simple stop tool with no output schema, the description fully covers what the tool does and its notable side effect. No additional information is necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. There is nothing for the description to add regarding parameters, and it correctly omits any parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Stop') and resource ('running game'), and adds a distinct cleanup action. It uniquely identifies this tool's purpose among siblings like play_scene or open_scene.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when a game is currently running, providing clear context. It does not explicitly mention alternatives or exclusions, but for a stop action with no alternatives, this is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses the execution context (editor process), the output mechanism (_mcp_print), the return mechanism (return value sent back), and a critical safety restriction (file/resource write APIs refused unless allow_unsafe_editor_io is true). This is rich, useful behavioral information beyond what the schema provides.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the core purpose. It packs essential information (execution context, output, return, safety flag) without any wasted words or repetition. The semicolon-separated clauses maintain clarity while covering all key aspects.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (arbitrary code execution) and lack of output schema/annotations, the description does a good job of covering the essentials: what the code should do, how to emit output, how to send back a return value, and a major safety guard. It could have mentioned error handling or access to editor APIs, but the provided info is sufficient for basic usage and safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero descriptions for parameters, so the description must compensate. It explains the allow_unsafe_editor_io parameter's purpose (controlling access to unsafe file/resource APIs) and describes how to use the code parameter (as the body of run(), with _mcp_print for output). While it doesn't detail every nuance, it adds significant meaning beyond the bare schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the tool's function: executing GDScript in the editor process. It distinguishes itself from sibling tools like execute_game_script by explicitly stating 'in the editor process'. The verb 'Run' and resource 'GDScript' are specific, and the added detail about _mcp_print and return values further clarifies its intended use.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (running arbitrary GDScript in the editor). It doesn't explicitly name alternatives or state when not to use it, but the 'editor process' qualifier implicitly differentiates it from execute_game_script. No exclusion criteria are given, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosure. It details the execution model (code as body of run(root: Node)), output mechanism (print()), and restrictions (no top-level func definitions, no await). These insights are critical for the agent to write valid code.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-structured sentence conveys the core action, execution context, output method, and key restrictions without redundancy. It is appropriately front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter execution tool with no output schema, the description provides complete guidance on code input and behavior. It stops short of mentioning error handling or return values, which could be useful but are not essential for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no description for the 'code' parameter, but the tool description fully compensates by explaining what the code should contain and its constraints. This gives the agent the semantics needed to provide correct input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool executes GDScript inside the running game process, with a specific verb (run) and resource (game process). This distinguishes it from siblings like execute_editor_script, which targets the editor context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'inside the running game process' provides clear context for when to use this tool (game runtime) versus editor-side alternatives. However, it does not explicitly name alternative tools or state exclusions, so it falls short of a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![godot-mcp-bridge MCP server](https://glama.ai/mcp/servers/rezaahmadn/godot-mcp-bridge/badges/card.svg)](https://glama.ai/mcp/servers/rezaahmadn/godot-mcp-bridge)

Score Badge

Copy to your README.md:

[![godot-mcp-bridge MCP server](https://glama.ai/mcp/servers/rezaahmadn/godot-mcp-bridge/badges/score.svg)](https://glama.ai/mcp/servers/rezaahmadn/godot-mcp-bridge)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/rezaahmadn/godot-mcp-bridge'

If you have feedback or need assistance with the MCP directory API, please join our Discord server