Godot MCP

Server Quality Checklist

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

Latest release: v0.1.1
Disambiguation4/5
Most tools have distinct resource+action mappings, and overlapping tools (send_input/send_key/send_key_sequence, set_property/set_node_properties) are clearly differentiated by descriptions that cross-reference the preferred choice. However, the sheer number of similar runtime/input/screenshot tools creates some initial ambiguity.
Naming Consistency5/5
All tool names follow a consistent snake_case verb_noun pattern (e.g., list_projects, create_scene, remove_node, validate_script). No camelCase or mixed styles, making the API predictable.
Tool Count1/5
75 tools is far beyond the typical well-scoped MCP server. Even for a broad engine like Godot, this feels bloated; many tools are micro-utilities that could be consolidated (e.g., several separate mouse/key/joypad senders).
Completeness4/5
The surface covers scene editing, project settings, scripts, tilemaps, animation, input simulation, testing, and asset management. Minor gaps include no file-level delete for scenes/resources/scripts and no create-project tool, but for the primary game-dev workflow it's largely complete.
Average 4.1/5 across 75 of 75 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- No commit activity data available
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description does not disclose any additional behavioral traits, such as error handling or what exactly constitutes 'metadata', thus adding no value beyond the 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 sentence with no superfluous words, extremely concise and front-loaded.
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 inform the agent what metadata is included (e.g., project name, version, settings), but it does not. Also, no usage scenarios are provided, making the description incomplete for a tool that may need to be selected among many siblings.
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's single parameter projectPath is fully described ('Path to the Godot project directory'), achieving 100% schema coverage. The description does not add parameter-level detail, but the schema is sufficient, so the baseline 3 applies.
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 verb 'retrieve' and resource 'metadata about a Godot project' clearly state the tool's function, distinguishing it from siblings like list_projects and get_godot_version. However, it does not enumerate what metadata is returned, leaving some ambiguity about 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no context for when to use this tool, no alternatives, and no exclusions. It is a single declarative statement without any guidance on selection.
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 is purely functional and does not disclose behavioral traits such as overwriting behavior, whether it affects the saved scene, or if any conditions must be met. With all annotation hints set to false, the description carries the full burden but provides no additional 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, clear sentence with no irrelevant content. It is concise and front-loaded, making it easy to understand at a glance.
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 moderate complexity (multiple parameters, nested cell definitions, and no output schema), the description is too sparse. It omits critical context such as whether existing cells are replaced, whether the change is saved to disk, or any side effects, leaving the agent under-informed.
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 100%, so all parameters are already well documented. The description adds no extra meaning to the parameters, maintaining the baseline score of 3.
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 sets tile cells on a TileMapLayer node, which is a specific verb and resource. It is distinct from sibling tools like get_tile_data or set_custom_tile_data, though it doesn't explicitly differentiate itself.
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 doesn't mention prerequisites, typical scenarios, or conditions under which this tool is preferred over related tools like set_custom_tile_data.
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 little beyond what annotations already state (readOnlyHint=false, destructiveHint=false). It does not disclose whether adding to an existing group is idempotent, whether new groups can be created, or any side effects on the 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?
A single, straightforward sentence with no fluff or repetition. Every word contributes to the meaning.
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 mutation tool with good schema coverage, the description is minimally adequate. However, it omits any mention of return values, error behavior, or whether node/group must already exist, which could leave an agent uncertain about expected outcomes.
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 100% and all parameters have descriptions, so the schema carries the semantic burden. The tool description adds no parameter-specific detail, which is acceptable given the high 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 states a specific action ('Add a node to one or more groups in a scene') with a distinct verb and resource. It easily differentiates from sibling tools like remove_from_group, 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 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 remove_from_group or add_node. There is no mention of prerequisites or scenarios favoring this operation over others.
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 no behavioral details beyond the annotations. It does not disclose whether the output file is overwritten, whether the scene must be part of an opened project, or any side effects during export. With annotations present (readOnlyHint=false), the agent knows it is a write operation, but the description offers no additional 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-formed sentence that immediately states the tool's purpose. It is concise and free of unnecessary details, earning its place with no 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?
For a tool with full parameter documentation and annotation coverage, the description is minimally sufficient. However, it lacks context about the operation's behavior, such as what nodes become mesh items or overwrite rules, making it incomplete for optimizing agent selection and safe 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?
The schema has 100% description coverage for all parameters, so the schema already explains each parameter fully. The description does not add parameter-level insights beyond what the schema provides, matching the baseline of 3.
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: 'Export a scene as a MeshLibrary resource.' This uniquely identifies the operation and distinguishes it from sibling tools like export_project or create_resource, which have different targets or formats.
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 are any prerequisites or typical use cases mentioned. The description only states the action without contextual cues for selection.
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 already indicate this is not read-only, not idempotent, and not destructive, but the description adds no further behavioral context. It does not clarify whether the scene file is modified, whether the node must exist, or any side effects of loading a sprite.
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. There is no wasted wording 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?
Given the tool's simplicity and complete parameter descriptions, the one-sentence description is minimally viable. However, it lacks information about behavioral outcomes (e.g., persistence, prerequisites) and offers no output schema or annotation support, leaving some ambiguity for an agent.
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 100% coverage, with each parameter (nodePath, scenePath, projectPath, texturePath) already described meaningfully. The description adds no additional parameter semantics beyond what the schema provides, so the baseline score of 3 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 'Load a sprite into a Sprite2D node' uses a specific verb and clearly identifies the resource (sprite) and target (Sprite2D node). It is distinct from sibling tools like add_node or set_node_properties, as it focuses specifically on loading a texture into an existing Sprite2D 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?
There is no guidance on when to use this tool versus alternatives, nor any mention of prerequisites or context. It simply states what it does, leaving the agent to infer 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already communicate that the operation is a safe mutation (readOnlyHint=false, destructiveHint=false). The description adds minimal behavioral context by specifying 'specific tile cells', implying a scoped change, but does not discuss effects like overwriting existing data, return values, or required preconditions.
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 immediately communicates the core function. There is no unnecessary wording or ambiguity; every word contributes to understanding the tool's purpose.
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?
While the description and schema together cover the 'what' of the operation, the tool is a mutation with no output schema and no mention of return behavior or preconditions (e.g., whether the TileMapLayer or custom data layers must exist). This leaves some context gaps for an agent evaluating side effects or follow-up actions.
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 100% coverage with descriptions for every parameter, including the nested structure of 'cells'. The description adds little beyond restating 'specific tile cells', so the schema carries the heavy lifting. Baseline 3 is appropriate.
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?
Describes a specific action: setting custom data layer values on tile cells in a TileMapLayer. The verb 'set' and resource 'custom data layer values' clearly indicate the operation, and it is semantically distinguished from sibling 'set_cells', 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?
Provides no guidance on when to use this tool versus alternatives. The description only states what it does, not the context or conditions under which it should be preferred over similar tools like set_cells or get_tile_data.
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 only indicate readOnlyHint=false, destructiveHint=false, and idempotentHint=false, which are not informative. The description adds 'typed properties' but does not disclose key behaviors such as whether an existing file is overwritten, whether the file is created atomically, or what happens on invalid input. There is no mention of return values or error handling.
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 filler. It front-loads the core purpose and avoids redundancy with the annotations or schema.
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 five parameters, a nested object, and no output schema, a one-line description is insufficient. It does not mention side effects (e.g., file overwrite behavior), prerequisites (e.g., valid project path), or return values. The description leaves too much unsaid 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?
Schema coverage is 100%: every parameter has a description in the input schema. The description does not add additional meaning beyond the schema, so it stays at the baseline of 3.
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 specific resource ('.tres resource file') and adds 'typed properties', which clearly differentiates it from sibling creation tools like create_scene or create_tileset. It is unambiguous 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 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, but the description implies usage: use when needing to create a .tres resource file with typed properties. It does not mention exclusions or when not to use it, so it stops at implied 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?
Annotations already indicate readOnlyHint=false (a mutation operation), but the description adds no behavioral context beyond the simple action. It does not disclose what happens to an existing script on the node, whether the scene file is saved, or any validation requirements. The description is neither misleading nor contradictory, but it is minimally informative.
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 core objects. It contains no redundant information and is appropriately brief for the tool's simplicity.
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 is adequate for a simple tool with fully documented parameters and annotations, but it lacks usage trade-offs, side-effect details, and any error conditions. Given the tool's complexity, this is a minimal but acceptable level of completeness.
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 100%, with all four parameters (projectPath, scenePath, nodePath, scriptPath) having clear descriptions. The tool description reinforces the role of scriptPath and nodePath ('GDScript file' and 'existing node') but adds no additional meaning beyond what the schema already provides.
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 ('attach') with a clear resource ('GDScript file') and target ('existing node in a scene'), which distinguishes it from sibling tools like write_script (which writes script content) and add_node (which adds nodes). The meaning is immediately clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 (when you have an existing node and a GDScript file to attach), but it does not explicitly mention alternatives or conditions when not to use it. There is no comparison with related script tools like write_script or validate_script.
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 provide no safety profile (all flags false), and the description does not disclose side effects, such as whether an existing .tres file will be overwritten, required permissions, or if the project needs to be open. The description only restates the basic creation action without adding 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?
Single sentence with no redundant words. Front-loaded with the verb 'Create' and efficient in conveying the tool's purpose.
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 (5 params, nested objects) but the schema provides comprehensive parameter details. The description lacks information about return values or post-creation behavior, but given the rich schema, it is minimally viable.
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 100%, so parameters are already fully documented. The description adds marginal meaning by mentioning 'atlas sources from texture files', but this is also evident from the schema. Baseline 3 applies since the schema does the heavy lifting.
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 (Create), the resource type (TileSet resource), and the source (atlas sources from texture files). It distinguishes itself from sibling tools like create_scene or create_resource by specifying the exact resource and 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 purpose implies when to use the tool (when a TileSet with atlas sources is needed), but there is no explicit guidance on when not to use it or comparison to alternatives. The context is clear but not fully articulated.
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 present but all false, providing minimal safety context. The description does not add behavioral details such as whether existing output files are overwritten, whether export presets are validated, or what happens on failure. It therefore adds little beyond the basic purpose.
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 clearly conveys the action and key conditions. No wasted words or redundant repetition of schema 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 has moderate complexity with four parameters and no output schema. The description covers the basic action but does not mention important context like output path requirements, preset prerequisites beyond 'configured', or behavior regarding existing files. While adequate for a simple export, it leaves some 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 coverage is 100%, so the schema fully documents all four parameters. The description mentions 'target platform' and 'configured export preset', which loosely align with the preset parameter, but it does not add detailed semantics or usage patterns beyond what the schema already provides.
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 ('Export') and resource ('a Godot project') with clear scope ('for a target platform using a configured export preset'). This distinguishes it from sibling tools like run_project or launch_editor, 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when needing to build an export artifact, but it does not explicitly contrast with alternatives (e.g., run_project for testing) or state when not to use. The context is clear enough for a straightforward export operation.
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 only indicate readOnlyHint=false and destructiveHint=false. The description adds input format details but does not disclose whether existing values are replaced, whether the scene file is saved, or validation behavior (e.g., out-of-range layer numbers). It does not contradict 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?
A single sentence effectively communicates the tool's purpose, target, and accepted input formats without unnecessary words. It is front-loaded with the core action and resource.
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 is adequate for a focused setter but lacks important behavioral context: what happens when both layer and mask are set, replacement semantics, scene persistence, and prerequisites. With no output schema and minimal annotations, these details 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?
While the schema covers all parameters, the description adds the valid range 1-32 and clarifies that both array and raw bitmask forms are accepted for collisionLayer and collisionMask. This is not explicitly stated in the schema descriptions, adding practical value.
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' with resource 'collision layer and/or mask' on 'physics node', clearly distinguishing from generic node property setters like set_node_properties. It also specifies accepted input formats (layer numbers array or raw bitmask), adding 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?
No guidance is provided on when to use this tool vs alternatives, nor any prerequisites or conditions. The description simply states the action without context such as 'use this when you need to configure collision layers' or comparing to set_node_properties.
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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds almost no behavioral context beyond what the name and annotations imply; it does not explain how projects are detected (e.g., presence of project.godot) or any constraints.
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 fully conveys the core functionality without unnecessary words. It is well-structured and front-loaded.
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 low complexity (2 params, one optional), good annotations, and full schema coverage, the description is adequate. It does not explain return values, but for a list tool this is often implicit; the absence of an output schema is mitigated by the straightforward nature of the 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?
The input schema covers both parameters (directory and recursive) with descriptions, achieving 100% coverage. The description adds no significant semantic value beyond the schema, so a baseline of 3 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 action ('List') and the target ('Godot projects') with a specific location ('in a directory'), making it distinct from sibling tools like get_project_info or export_project. It is specific and not a tautology.
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 guidance is implied: to enumerate projects, use this tool. However, it does not explicitly state when to use it versus alternatives (e.g., get_project_info for details) or provide any exclusions. There is no explicit 'when to use' 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?
The description simply restates the destructive action already declared by destructiveHint=true. It does not add context about error behavior (e.g., what happens if the node is not in the group), idempotency, or any side effects. No additional behavioral disclosure beyond the 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, clear sentence with no filler. It immediately states the action and target, making it efficient 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?
The tool is simple and fully covered by the schema (100% parameter documentation). No output schema is needed since the operation returns nothing significant. The description sufficiently communicates the core operation, though it could mention edge cases like non-existent groups, but this is minor given the tool's simplicity.
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 100%, with all four parameters well-documented in the input schema. The description adds no parameter-specific meaning beyond the schema, which is acceptable given the high schema coverage, meeting the baseline of 3.
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 'Remove a node from one or more groups in a scene' uses a specific verb ('Remove') and clearly identifies the resource (a node) and the target (groups). This clearly distinguishes it from sibling tools like add_to_group and remove_node.
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 use case (removing a node from groups) but does not explicitly state when to use this tool over alternatives like add_to_group or provide any exclusions or prerequisites. It relies on the agent inferring the context from the operation itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description transparently states 'overwrite' and 'Creates parent directories if needed,' but the annotation destructiveHint=false contradicts the overwrite behavior. Overwriting a file is destructive, so this is a serious inconsistency. Per the rule, a description that contradicts annotations scores 1.
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 highly concise: two sentences with no wasted words. It front-loads the core action and adds a practical follow-up hint. Every sentence 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?
The description covers the essential behavior (write/overwrite), side effects (directory creation), and a recommended next step (validate). It omits edge cases like error handling or project existence, but for a simple file-writing tool this is reasonably complete. The annotation contradiction slightly reduces completeness but is already penalized in transparency.
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 100%, so the baseline is 3. The description does not add parameter-specific details beyond noting that parent directories are created (relevant to scriptPath). It does not conflict with the schema but adds minimal semantic value.
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: 'Write or overwrite a GDScript file in a Godot project.' This is a specific verb+resource construction that distinguishes it from siblings like read_script and validate_script. It unambiguously conveys the core action and 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 a clear follow-up instruction: 'Use validate_script afterward to check for syntax errors.' This gives context on recommended usage. However, it does not explicitly mention when not to use this tool or 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=false and destructiveHint=false, so the agent knows this is a mutation that is not destructive. The description adds no additional behavioral context (e.g., whether children are duplicated, whether scene must be loaded). It does not contradict 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, focused sentence that is front-loaded with the primary action. 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 tool with 5 parameters and no output schema, the description covers the core behavior but leaves gaps: no mention of whether child nodes are duplicated, what happens to connections, or any return value. The schema handles param details, but behavioral expectations are incomplete.
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 100%, with every parameter having a description. The tool description adds slight context by noting optionality of newName and parentNodePath, but this is already inferable from the schema (those fields are not in required). Baseline of 3 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's function with a specific verb ('Duplicate') and resource ('node within a scene'), and distinguishes it from related sibling tools like reparent_node and rename_node by mentioning optional new name or parent.
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 (when duplicating a node), but it does not explicitly state when it should not be used or mention alternatives such as reparent_node or rename_node for related operations. Context is clear but not fully developed.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is safe and non-mutating. The description adds scoping context by specifying it reads from a TileMapLayer node in a scene, but it does not go beyond that to describe return format, side effects, or error behavior. It is consistent with annotations, with no contradiction.
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 gets straight to the point with the verb 'Read'. Every word earns its place, and there is no redundant filler or repetition of the tool name.
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, so the description should clarify what the agent can expect in return. It says 'Read existing tile cells' but does not specify the format (e.g., list of cell coordinates, tile IDs). The parameters are well-covered, but the missing return details and lack of any note about prerequisites or failures leave a moderate gap.
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 100%, with each parameter getting a clear description (projectPath, scenePath, nodePath). The tool description adds no additional parameter-level meaning beyond what the schema already provides, meeting the baseline for well-documented 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 'Read existing tile cells from a TileMapLayer node in a scene' uses a specific verb ('Read') and clearly identifies the resource (tile cells in a TileMapLayer node). It distinguishes from sibling write tools such as set_cells by emphasizing 'existing' cells and the read 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 usage: if an agent needs to read tile data from a TileMapLayer node, this is the tool. However, it provides no explicit when-to-use guidance or mention of alternatives, so it falls under 'implied usage' rather than clear contextual direction.
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?
Annotations already indicate readOnlyHint=false, so the description does not need to state this is a write operation. It adds the context that the operation creates a child instance, but does not disclose side effects, reversibility, or prerequisites beyond that. No contradiction with 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 sentence, front-loaded with the core action, and includes a helpful example without extraneous detail. It earns its place 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 mutation tool with six parameters and no output schema, the description is minimal. It does not mention prerequisites (e.g., whether the project must be open), return values, or error conditions. While the schema and example cover much, the added context is thin for the complexity involved.
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 100%, with all parameters documented. The tool description adds little beyond what the schema already provides, such as clarifying the relationship between parent and child scene paths. This matches the baseline for fully covered schemas.
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 scene as a child instance of another scene,' with a concrete example. It uses a specific verb and resource, and distinguishes itself from sibling tools like create_scene or add_node by focusing on instantiating an existing scene as a child.
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 example ('spawn a player scene inside a level') implies a common use case, but there is no explicit guidance on when to prefer this tool over alternatives or any exclusions. It lacks the 'use X instead' clarity seen in high-scoring 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?
The description does not disclose behavioral details such as whether an existing file at scenePath will be overwritten, what permissions are needed, or what happens if the project path is invalid. Annotations are all false, which only signals that this is not a read-only operation, leaving the agent without clarity on 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 exactly two sentences: the first states the core purpose, and the second clarifies the key parameter and default. It is front-loaded, free of filler, and every sentence 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?
For a relatively simple tool with three parameters and a 100% schema description coverage, the description covers the essentials. Its main gap is not explaining return values or what happens if the scene file already exists, but the schema and simplicity keep it mostly 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?
The schema already covers all parameters, but the description adds a valuable default value for rootNodeType ('Node2D') and examples ('Node2D', 'Node3D', 'Control'), providing semantic detail not present in 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 states a specific verb ('Create'), a specific resource ('Godot scene (.tscn) file'), and the scope ('with a root node'). The word 'new' distinguishes it from tools like save_scene or add_node, making its purpose unambiguous relative to 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 the primary use case (creating a new scene file) but provides no explicit guidance about when to use this tool versus alternatives like add_node or save_scene. It does not mention exclusions or alternatives, so usage context is inferred 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?
Annotations already indicate the tool is not read-only and not destructive. The description adds that it works by resaving resources, which implies file modification, and restricts usage to Godot 4.4+, but it does not disclose potential side effects like overwritten files or whether the project must be closed.
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, method, and version constraint. Every word earns its place, with no filler or 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 single-parameter tool with no output schema, the description adequately covers the purpose and method. It could mention error conditions or return behavior, but given the simplicity and existing annotations, it is sufficiently complete for an agent to select and invoke 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 only parameter, projectPath, has full schema documentation in the input schema. The description does not add any additional meaning beyond what the schema provides, so the baseline score of 3 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 action ('update'), the target ('UID references in a Godot project'), and the method ('by resaving resources'). It is specific and distinct from sibling tools like get_uid, and the Godot 4.4+ version constraint adds useful context.
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—when UID references need to be updated in a Godot 4.4+ project—but it does not explicitly mention alternatives or when not to use it. There is no comparison with related sibling tools such as get_uid.
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 provide readOnlyHint=false, destructiveHint=false, idempotentHint=false, so no safety context. The description merely says 'modify' without disclosing whether settings are overwritten, whether values are validated, whether the file is flushed, or any side effects. For a mutation tool, this is a significant 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?
Two sentences, front-loaded with the core purpose, zero waste. The alternative is stated in a second concise sentence.
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 two-parameter tool with no output schema, the description covers purpose and one alternative. However, it omits behavioral details like whether existing settings are merged or replaced, and whether changes persist immediately. This leaves the description somewhat incomplete for a mutation 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 100%: both parameters (settings and projectPath) have clear descriptions, with an example for settings. The description adds category context ('input actions, display, rendering, physics') but no additional syntax or format details beyond the schema, so baseline 3 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 states a clear action: 'Modify project.godot settings' with a specific resource and enumerates categories (input actions, display, rendering, physics). It also explicitly distinguishes from the sibling tool manage_autoloads by directing autoload singletons there, satisfying the differentiation criterion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit when-not/alternative: 'For autoload singletons, prefer manage_autoloads.' This tells the agent when not to use this tool and which sibling to use instead, meeting the highest bar for usage 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?
Annotations are all false, so the description must convey behavioral traits. It notes the tool executes code in the current scene context and requires run_interactive, but it does not disclose potential side effects, state changes, or failure modes beyond the absence of read-only guarantees. 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 two sentences with no filler. It front-loads the primary action, adds a clear differentiator, and states a necessary prerequisite, making every word useful.
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 purpose, differentiation, and a prerequisite, which is sufficient for basic invocation. However, because arbitrary code execution can have significant side effects and there is no output schema, more detail on expected behavior or caveats would improve completeness.
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 100%, so the baseline is 3. The tool description itself does not add parameter-level semantics beyond what the schema already provides, such as the example and use of 'return x'.
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 a multi-line GDScript block at runtime in the current scene context. It also explicitly distinguishes itself from evaluate_expression by mentioning support for variables, loops, and control flow, which separates it from a key sibling tool.
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 direct comparison to evaluate_expression, indicating this tool is suited for complex scripts requiring variables and control flow. It also states a prerequisite (requires run_interactive), which gives practical usage context, though it doesn't explicitly enumerate all when-not-to-use scenarios.
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?
Annotations already indicate the tool is not read-only and not destructive, so the safety profile is partly covered. The description adds that it edits project.godot, but it does not disclose output formats for 'list' or potential side effects of 'add'/'remove' (e.g., whether existing entries are overwritten). This is sufficient 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?
A single, tightly worded sentence that leads with the action verbs and resource. No wasted words, and it is immediately scannable.
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 is adequate for a simple tool with documented parameters, but it lacks an explanation of the 'list' action's return value or any prerequisites/error conditions. Since there is no output schema, a brief note on what list returns would improve completeness, but overall the description covers the core functionality.
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 100%, so the parameters are fully described in the schema. The description does not add extra meaning beyond what the schema already provides. The baseline of 3 applies here since the schema does the heavy lifting.
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 specific verbs 'Add, remove, or list' and clearly identifies the resource ('autoload singletons in project.godot'). This distinguishes it from sibling project-management tools by naming the exact configuration element it targets.
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: use this tool whenever you need to manage autoload singletons in a Godot project. It does not explicitly state exclusions or name alternative tools, but the context is unambiguous and the action set (add/remove/list) covers the primary use cases.
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?
Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds value beyond annotations by specifying the types of issues checked (missing scripts, broken references, orphan nodes), giving a clearer picture of the tool's 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 is front-loaded with the action and resource. It includes useful examples without unnecessary verbosity.
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, so the description should explain what the validation result looks like (e.g., a list of issues, pass/fail). It does not mention the return format, leaving a gap for an AI agent to know what to expect from 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?
Schema coverage is 100% with both projectPath and scenePath already described. The description does not add any additional meaning or syntax details for the parameters, so it meets the baseline without adding extra value.
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 'validate' with the resource 'scene' and lists concrete example issues (missing scripts, broken references, orphan nodes). This clearly distinguishes it from sibling tools like validate_script or get_scene_insights.
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 checking scene integrity, but it does not explicitly state when to use this tool versus alternatives like validate_script or get_scene_insights. 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set readOnlyHint=false, destructiveHint=false, idempotentHint=false. The description adds that it returns a serialized result and requires interactive mode. However, it does not disclose that calling arbitrary methods may have unpredictable side effects, relying on the caller's knowledge of the target method.
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 three sentences long, front-loaded with the core purpose, and every sentence adds value: action, path resolution, result, and prerequisite. No redundant or filler content.
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 tool with 3 parameters and no output schema, the description is sufficiently complete. It covers the action, path resolution, argument handling, return value, and runtime requirement. Minor gaps like error handling are not critical for this tool's 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?
Schema coverage is 100%, with each parameter described. The description reinforces the meaning of nodePath and args but does not add new details beyond the schema, so the baseline of 3 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 invokes a method on a live node in a running interactive Godot project, with concrete path examples. It distinguishes itself from sibling tools like set_node_properties or get_node_properties by focusing on method calls rather than property access.
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 states a prerequisite: the project must be running via run_interactive. It also clarifies that node paths are relative to the current scene. It does not name alternative tools explicitly, but the context is clear enough for an agent to decide 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds valuable behavioral context by revealing that the tool runs headless, which is not indicated in annotations, and by describing the scope of the analysis, giving a clear picture of what the tool inspects.
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 extremely concise—two short sentences that front-load the primary action and list the analyzed components, followed by the headless note. 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description compensates by listing the analysis dimensions (type distribution, signals, sub-scenes, scripts, groups, tree depth), giving a strong hint of the return content. It also notes the headless execution. However, it does not explicitly describe the return format (e.g., a JSON object), which prevents a perfect score.
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 100%, with both parameters (projectPath and scenePath) clearly documented in the schema. The description adds no additional parameter-level details beyond what the schema already provides, so the baseline score of 3 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 ('Analyze') with a clear resource ('a scene's architecture') and enumerates the exact aspects covered (type distribution, signals, sub-scenes, scripts, groups, tree depth). This distinguishes it from sibling tools like get_scene_tree, which likely only returns the raw 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 provides clear context by noting it 'Runs headless (no game needed)', implying it is for static analysis without launching the game. However, it does not explicitly state when to use this tool over alternatives or mention any exclusions, so the usage 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?
Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds a version constraint (Godot 4.4+) but does not disclose return format or error behavior, which would further aid 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: 'Get the UID for a specific file in a Godot project (for Godot 4.4+)'. Every word contributes, with no redundant or filler content.
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 getter with full schema coverage and safety annotations, the description is largely sufficient. It clearly indicates what the tool returns (a UID) and the required parameters, though it omits explicit return format details since no output schema is provided.
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 covers both parameters with clear descriptions (relative file path and project directory). The description adds no additional parameter-level meaning beyond what the schema already provides, so a baseline score 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 states a specific action (Get) and resource (UID for a specific file in a Godot project), with a version qualifier (Godot 4.4+). This clearly distinguishes it from siblings like update_project_uids or get_project_info.
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 when you need the UID for a specific file in a Godot 4.4+ project. It does not explicitly name alternatives or when-not-to-use, but the purpose is well-scoped and 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?
With annotations providing only false hints (readOnly, destructive, etc.), the description must disclose behaviors itself. It does reveal a non-obvious trait: the MCP receiver remains active during pause. But it does not mention side effects, reversibility, or what happens to the game state. This is adequate 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?
Two sentences, front-loaded with the primary action and followed by a key behavioral detail and prerequisite. Every sentence earns its place without redundancy or fluff.
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 adequately covers purpose, a key behavioral nuance, and a requirement. It could mention what happens after unpausing, but overall it is sufficiently complete for an agent to use it effectively.
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 covers the single parameter 'paused' with a clear description. The tool description adds no additional parameter details, so baseline 3 is appropriate given 100% 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 a specific verb ('Pause or unpause') with a clear resource ('a running project'), making the primary action unmistakable. It also distinguishes from sibling tools like stop_project by implying a non-terminal halt. The added detail about the MCP receiver staying active further clarifies the tool's unique role.
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 contextual guidance by stating 'MCP receiver stays active for screenshots, state queries, and property changes while paused,' which suggests use cases where the project should remain responsive. It also notes 'Requires run_interactive,' setting a prerequisite. However, it does not explicitly name alternative tools or exclusions, 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate destructiveHint=true and readOnlyHint=false, so the agent knows this is a destructive write operation. The description adds important context that the operation removes not only the node but also its children, which is behavior beyond the basic annotation.
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 that immediately conveys the core action. It is front-loaded with the verb and resource, with no redundant or filler content. Every word contributes to understanding 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 straightforward deletion tool with three fully documented parameters and clear annotations, the description is sufficient. It conveys the essential behavior (including child deletion) without requiring extensive explanation. It could mention error cases or whether changes persist to disk, but given the schema and annotation support, the description meets the needs for effective selection and 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?
The input schema provides 100% coverage with descriptions for all three parameters (projectPath, scenePath, nodePath). The description does not add any additional parameter-level semantics beyond what the schema already specifies, so the baseline of 3 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 'remove' with a clear resource 'node (and its children)' from a 'scene', making the tool's function unambiguous. It is distinct from sibling tools like add_node, reparent_node, or rename_node, 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 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 to delete a node from a scene) but does not provide explicit guidance on conditions, exclusions, or alternatives. There is no mention of when not to use this tool or how it compares to similar operations like remove_from_group.
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 adds meaningful behavioral context beyond the annotations (which only indicate readOnlyHint=false and destructiveHint=false): it guarantees that properties, children, and connections are preserved. This addresses what is not destroyed and clarifies the non-destructive nature of the rename. It does not contradict any annotation.
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 two short sentences, front-loaded with the action ('Rename') and followed by a concise behavioral guarantee. Every word earns its place, with no redundant or extraneous 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 rename operation with four well-documented parameters and no output schema, the description provides sufficient context for an agent to select and invoke the tool correctly. It covers the core purpose and a key behavioral guarantee, though it does not mention edge cases like name collisions or what happens if the node does not exist.
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 100%, so the schema already documents each parameter (projectPath, scenePath, nodePath, newName) with clear descriptions. The tool description does not add additional detail about parameter formats, constraints, or relationships beyond what is in the schema, so the baseline score of 3 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 the specific verb 'Rename' with a clear resource ('a node in a scene file') and explicitly states the scope: 'keeping all properties, children, and connections intact.' This clearly distinguishes it from sibling operations like remove_node or reparent_node, which would alter 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?
The operation is inherently specific, and the phrase 'keeping all properties, children, and connections intact' implies when it is appropriate (when the goal is purely renaming without structural changes). However, it does not explicitly mention alternatives or exclusions, such as 'use set_node_properties to change other attributes' or 'do not use for reparenting.'
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 does not add much beyond the basic operation. Annotations already indicate it is not read-only (readOnlyHint=false) and not idempotent, so the mutation nature is known. The phrase 'within the same scene' is a useful constraint, but there is no disclosure of side effects like children moving with the node or impact on references.
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 perfectly conveys the tool's function without unnecessary words. It is front-loaded and 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?
For a simple mutation tool with fully described parameters and no output schema, the description is adequate. It mentions the key constraint of being within the same scene, which is important context. It doesn't explain return values, but that's not required given the simple nature of the 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?
The input schema has 100% description coverage, with all four parameters well-documented (e.g., nodePath and newParentPath examples). The description adds no additional meaning about parameters, so the baseline score of 3 applies.
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 ('Move a node to a different parent') and the scope ('within the same scene'), which distinguishes it from sibling tools like rename_node or remove_node. The verb and resource are specific, 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 description provides clear context for when to use the tool: when you need to change a node's parent within a scene. It does not explicitly mention alternatives or exclusions, but the purpose is self-evident enough to guide selection among the many node-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?
The annotations provide no safety profile (readOnlyHint, destructiveHint false). The description discloses the copy behavior via newPath, but does not explicitly state whether saving without newPath overwrites the existing scene or what happens to the current scene state. This leaves some ambiguity 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?
Two sentences, front-loaded with the main purpose and followed by usage guidance. No redundant filler, every sentence 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?
For a straightforward save tool with full schema coverage and no output schema, the description provides purpose, usage, and copy behavior. It is slightly incomplete in not detailing overwrite behavior, but overall adequate for the tool's simplicity.
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 covers 100% of parameters with descriptions. The description reiterates newPath's purpose (creating a copy), but does not add new meaning beyond the schema. The copy context is already in the schema, so baseline 3 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 saves a scene file, with an optional new path to create a copy. It distinguishes itself from sibling editing tools by noting that most editing tools save automatically, so this tool is primarily for saving copies.
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?
Explicitly says to use this primarily for saving copies, and that most editing tools save automatically, implying you don't need to save after typical edits. However, it does not name specific alternative tools, so the guidance is clear but not fully enumerating 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?
Annotations already indicate non-read-only and non-destructive. The description adds the run_interactive requirement, giving useful behavioral context. It does not detail side effects, timing, or error states, but for a simple event-send tool 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?
Two sentences, no fluff. It front-loads the purpose and immediately gives an alternative preference and prerequisite. Every sentence 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?
For a simple send tool with no output schema, the description covers purpose, usage guideline, and prerequisite. It lacks only an explicit mention of return value or status, but this is a minor gap given the tool's simplicity.
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 covers 100% of parameters with detailed descriptions, including button name categories and defaults for device and pressed. The description adds no additional parameter semantics beyond what the schema provides.
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 sends a gamepad button event to a running project, listing examples (A, B, X, Y, shoulders, dpad, start). This distinguishes it from siblings like send_joypad_motion (axis), send_key (keyboard), and send_input (input actions).
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 explicit guidance 'For input actions, prefer send_input' and notes 'Requires run_interactive' as a prerequisite. However, it does not explicitly contrast with send_joypad_motion, though the button vs. axis distinction is implied by the tool 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?
The description adds 'Requires run_interactive' and clarifies no clicking occurs, which is useful context beyond the sparse annotations. However, it doesn't describe return values, failure modes, or whether the movement is instant, leaving a moderate 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 three short sentences, all informative and directly relevant. It is front-loaded with the core action and includes use cases and a prerequisite 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?
For a simple two-parameter tool with a clear purpose and use cases, this is nearly complete. It covers prerequisites and intended scenarios. The only minor omission is what occurs if run_interactive is not active, but this is a shared tool context.
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 100%, with x and y both described as 'viewport pixels.' The description adds no additional parameter meaning beyond what the schema already provides, so baseline 3 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 action: 'Move the mouse cursor to specific coordinates without clicking.' This is a specific verb+resource and distinguishes from clicking tools, which is important given siblings like send_mouse_click and send_mouse_drag.
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 explicit use cases ('hover effects, aiming, and cursor tracking') and a prerequisite ('Requires run_interactive'). It implies exclusions by saying 'without clicking,' but does not explicitly name alternatives like send_mouse_click.
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?
Annotations provide no safety cues (all false), so the description carries the burden. It discloses the prerequisite that an existing AnimationPlayer is required and points to create_animation_player otherwise. However, it does not mention side effects like overwriting animations with the same name, scene saving behavior, or error conditions, which would matter 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?
Two concise sentences, front-loaded with the core action and target. The alternative pointer to create_animation_player is valuable and does not add fluff. No wordy or redundant content.
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?
Tool has 7 parameters with nested track/keyframe structures, and no output schema. The schema is thorough, and the description gives essential prerequisite context, but it lacks return/error behavior and detailed side-effect information. Minimally adequate for invocation, but not deeply 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 100%, so the schema already documents all parameters. The description adds only high-level context (tracks, keyframes, existing node) already reflected in schema properties. Baseline 3 is appropriate since no extra parameter syntax or meaning is provided.
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 uses a specific verb+resource: 'Add an animation with tracks and keyframes to an existing AnimationPlayer node.' It clearly differentiates from sibling 'create_animation_player' by focusing on adding to an existing node and mentioning the alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool (on existing AnimationPlayer) and when not (to create the player itself) with direct alternative: 'To create the AnimationPlayer itself, use create_animation_player first.' This gives clear usage boundaries.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context by stating it returns the full source code as text, clarifying the output format beyond what annotations provide.
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 action (read), the target (GDScript file), the context (Godot project), and the return type (full source code as text). No superfluous words or repetition.
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 read operation, the description is complete: it names the resource, the scope, and the output format. The tool has no output schema, but the description explicitly states what is returned, and the read-only annotations cover side-effect concerns. No additional context is needed.
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 100%, with both parameters adequately described in the schema. The description adds no further detail about parameter meaning or formatting, so it does not go beyond the baseline for full 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 a specific verb ('Read') and resource ('GDScript file from a Godot project'), clearly distinguishing it from sibling tools like write_script, validate_script, and execute_script. It specifies the scope (Godot project) and the output (full source code as text).
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 usage: read a script file when you need its contents. However, it does not explicitly mention when to use it over alternatives or provide exclusions, so it stops at implied usage rather than clear 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?
Annotations already indicate readOnlyHint=false and destructiveHint=false, so the mutation nature is clear. The description adds a behavioral detail about defaulting to root when parentNodePath is omitted, but does not disclose other potential side effects (e.g., whether the file is auto-saved, existing node behavior, or prerequisites). 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 two sentences with no redundancy. It immediately states purpose, gives a useful default, and points to an alternative. Every word earns its place, perfectly 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 mutation tool with no output schema, the description covers the essential context: what it does, the default parameter behavior, and a relevant alternative. It could mention return behavior or side effects, but given the moderate complexity and schema richness, it is sufficiently complete for an agent to select and invoke 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?
Schema coverage is 100%, giving a baseline of 3. The description adds meaningful param semantics by explaining the default behavior for parentNodePath when omitted, which is not in the schema. This extra context justifies a score above baseline.
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 child node) and the resource (a scene file on disk), and distinguishes from a sibling tool by explicitly pointing to instantiate_scene for sub-scene instances. This meets the 'specific verb+resource' criterion and adds distinguishing 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 description provides a clear alternative usage ('For sub-scene instances, use instantiate_scene') and implies the primary use case (adding nodes to scene files). However, it does not explicitly mention when not to use the tool beyond that one sibling, so it lacks exhaustive 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?
Annotations already indicate this is a mutating operation (readOnlyHint=false), and the description adds the optional animations behavior. However, it does not disclose deeper behavioral details such as what happens if the node already exists, whether the scene file is saved, or prerequisites like project/scene validity.
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?
Two concise sentences with the primary action front-loaded and no redundant filler. Every clause contributes meaning, including the alternative tool pointer.
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 schema coverage and the explicit sibling differentiation, the description is sufficiently complete for a creation tool. It could optionally mention side effects like saving the scene or handling existing nodes, but those are not critical given the schema and annotations.
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 covers 100% of parameters, so the baseline is 3. The description adds only minimal extra context by calling animations 'optional pre-configured animations', which aligns with the schema but does not elaborate on structure or defaults beyond what the schema already provides.
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 it creates an AnimationPlayer node in a scene with optional pre-configured animations. It explicitly distinguishes itself from add_animation, which is for adding animations to an existing player.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when not to use this tool by directing users to add_animation for existing players. This gives clear contextual differentiation among sibling 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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the safety profile is known. The description adds that the source is a running Godot project and that errors_only and tail filters are supported. However, it does not disclose failure behaviors (e.g., if no project is running) or the exact structure of returned output. Given annotation coverage, 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 three short sentences, front-loaded with the core action, and every sentence carries useful information (purpose, filters, alternative). 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 tool is simple with no required parameters and no output schema. The description covers purpose, source, filters, and points to an alternative for structured errors. It does not discuss behavior when no project is running, but for this complexity level, it is nearly 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 has 100% description coverage for both tail and errorsOnly, clearly explaining their meaning. The tool description mentions these filters but does not add information beyond the schema. Thus the description adds no extra parameter value; baseline 3 applies.
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 console output (stdout/stderr) from a running Godot project. It specifies the resource and scope, and distinguishes itself from the sibling get_runtime_errors by pointing to that tool for structured errors.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly directs users to get_runtime_errors for structured errors with stack traces, establishing a clear when-not and alternative. The mention of 'running Godot project' implies the prerequisite context. This is explicit enough for a simple read 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?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is known. The description adds the prerequisite of run_interactive and clarifies optional filtering, which adds useful behavioral context beyond the annotations. It does not describe return format, but that is not a major gap for this 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 three short sentences that are all essential: purpose, optional filtering, and prerequisite. It is front-loaded with the main action and contains no filler or 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 single-optional-parameter read tool with good annotations, the description covers the core aspects: what it does, the optional filter, and the prerequisite. It doesn't define return values or error behavior, but given the simplicity of the tool and the annotations, it 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 schema fully documents the 'metrics' parameter (optional array of strings, default all). The description repeats this with 'Optionally filter to specific metrics,' adding no additional meaning. Since schema description coverage is 100%, baseline 3 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 performance metrics (FPS, draw calls, memory, node count) from a running project, with an optional filter. This is a specific verb+resource+scope that distinguishes it from sibling tools like get_debug_output or get_scene_insights.
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 mentions 'Requires run_interactive,' which is a clear prerequisite and context for when to use this tool. It implies use when the project is running and the user needs performance metrics, but it does not explicitly name alternatives or provide exclusions, hence not 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?
Discloses stateful 'since the last call' behavior and return content (structured entries with error type, source, stack traces). Adds prerequisite of run_interactive. Annotations already cover read-only/destructive hints, and description does not contradict them.
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?
Two sentences, front-loaded with the core purpose, concise and free of filler. Every sentence 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?
With one optional parameter and no output schema, the description covers the return structure and prerequisites well. It doesn't explicitly describe the consuming behavior of the default clear=true, but the schema's parameter description fills that gap.
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, 'clear', has full schema description coverage (100%). The description adds no additional parameter detail, but the schema already clearly explains the default behavior and peek option, so baseline 3 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?
Description uses a specific verb ('Retrieve') and clearly identifies the resource: runtime errors, warnings, and backtraces since the last call. This distinguishes it from sibling get_debug_output by focusing on structured runtime errors with stack traces.
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?
States explicit prerequisites ('Requires Godot 4.5+ and run_interactive'), giving clear context for when the tool can be used. However, it does not explicitly mention alternatives or when not to use it, 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses behavior beyond the annotations: it clears the buffer by default and mentions the return fields. It also notes a dependency on run_interactive. No contradiction with annotations; it adds useful 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 concise, with two clear sentences. It is front-loaded with the core action and includes essential return and side-effect information without unnecessary detail.
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, the description covers purpose, return values, side effect, and a prerequisite. It could mention empty-buffer behavior, but annotations and schema cover safety, making it 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 schema fully documents the 'clear' parameter with its default and effect. The description restates the default behavior but does not add semantic meaning beyond what the schema already provides, so a baseline score of 3 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 identifies the tool's purpose: retrieving buffered signal events. It specifies the source (subscribe_signals) and the return content (signal name, arguments, timestamp), which distinguishes it from siblings like subscribe_signals or wait_for_signal.
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 states a prerequisite (requires run_interactive) and implies typical usage after subscribing to signals. However, it does not explicitly mention alternatives or exclusions, such as using wait_for_signal for a single signal instead.
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?
Annotations already declare readOnlyHint and idempotentHint, so the safety profile is known. The description adds useful behavioral context that it reads project.godot and works without a running game, which goes beyond the annotation metadata.
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 two sentences with no redundant information. It front-loads the purpose and immediately adds a practical usage tip, making it highly 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-only tool with one parameter, the description covers the action, purpose, and a key operational constraint. It doesn't detail the return format, but the phrase 'list all input actions' adequately implies a list of action names, which is sufficient given the tool's low 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 schema already provides a complete description of projectPath (100% coverage), so the baseline is 3. The description's mention of project.godot adds minimal semantic value beyond the schema, which already indicates a Godot project directory.
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 primary function with a specific verb and resource: 'List all input actions defined in a project's project.godot (the InputMap).' It also situates the tool relative to a sibling by mentioning it's useful before using send_input, which differentiates it from other project-management 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 gives a clear usage context ('Useful before using send_input') and a key constraint ('No running game required'). It doesn't explicitly state when not to use it or name alternative tools, but the guidance is sufficient for the agent to select it appropriately.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds behavioral context by noting the GUT installation requirement and the return format (pass/fail summary and console output), which is useful beyond the 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 two sentences, front-loaded with the core purpose and then adding necessary prerequisites and expected output. Every sentence earns its place without 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 the tool's moderate complexity, the strong schema descriptions, and the annotations, the description provides enough context. It clearly states the output and prerequisite, and the absence of an output schema is compensated by the summary mention. Minor gaps like timeout behavior are covered by parameters.
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 100%, so all parameters are well-documented. The description does not add parameter-specific details beyond what the schema provides, but it does not need to; baseline 3 is appropriate given the high 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 a specific verb ('Run') and resource ('GUT tests') with the method ('via headless Godot'), clearly distinguishing it from sibling tools like run_project or run_interactive. It also explains what GUT is, eliminating ambiguity.
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 states the prerequisite (GUT installed) and the headless nature, implying it is meant for unit testing rather than general project running. It does not explicitly name alternatives or exclusions, but the context is clear enough for an agent to choose correctly.
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 annotations provide no positive safety hints (readOnlyHint, openWorldHint, idempotentHint, and destructiveHint are all false), so the description carries the burden. It adds behavioral context by breaking down the gesture into 'press, move, release' and noting the 'Requires run_interactive' dependency. However, it does not disclose potential side effects, coordinate system, or whether the operation blocks, leaving 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 two sentences with no redundancy. It packs the action, a recommended alternative, and a prerequisite into a minimal, front-loaded format. Every element 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?
Given the full schema coverage and simple operation, the description is sufficient for correct invocation. It names the operation, alternative, and requirement. Lacking coordination or side-effect details, but these are not critical for a mouse drag tool with a complete schema, and no output schema exists to explain.
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?
Input schema coverage is 100%, so parameters are already well-documented. The description's phrase 'from one position to another' reinforces the from/to coordinates but does not add meaning beyond the schema for steps or button. Baseline 3 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's function: 'Send a mouse drag (press, move, release) from one position to another.' It uses a specific verb and resource, and explicitly distinguishes from send_mouse_click, a sibling tool, 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance by naming an alternative: 'For simple clicks, use send_mouse_click.' It also states a prerequisite, 'Requires run_interactive,' which helps the agent determine when this tool is appropriate.
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?
Annotations already cover safety (readOnlyHint, idempotentHint, destructiveHint), and the description adds useful behavioral context: it explicitly states headless mode and that no running game is required. This goes beyond the annotations by explaining operational prerequisites.
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 two short, impactful sentences. The main verb and resource are front-loaded, and the second sentence adds necessary clarification 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?
The description captures the tool's core purpose and operational mode, which is sufficient for a simple validation tool. However, without an output schema, it does not indicate what the result looks like (e.g., error list vs. success message), a minor gap.
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 fully describes both parameters (scriptPath and projectPath) with clear examples and relative path hints. The description does not add additional parameter semantics, so the baseline of 3 for high schema coverage applies.
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's action ('Validate a GDScript file'), the specific purpose ('for syntax errors'), and mode ('using Godot's parser in headless mode'). It also distinguishes from siblings like read_script or write_script by specifying validation and the lack of a running game.
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 'No running game needed' provides clear context for when this tool is appropriate (static validation without launching a project). However, it does not explicitly name alternative tools or exclusion cases, so it falls short of full guideline criteria.
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?
Beyond the annotations (read-only, idempotent), the description discloses blocking behavior, timeout semantics, return value, and the run_interactive prerequisite. It doesn't cover edge cases like missing node paths or signals already emitted, but the added context is valuable and non-contradictory.
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?
Three sentences, no fluff. The first sentence front-loads the action, the second states a use case, and the third provides return behavior and a prerequisite. Every sentence 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?
For a simple 3-parameter tool with no output schema and safe annotations, the description covers purpose, use case, return value, and prerequisite. It lacks edge-case behavior (e.g., missed signals) and doesn't distinguish from wait_for_node, but overall it is sufficiently complete 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds minimal parameter meaning beyond the schema, though it does provide example signal names ('animation_finished', 'died') that align with schema examples. No additional syntax or format details are provided.
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 ('Block') and resource ('signal emitted on a node'), with a clear scope and examples. It distinguishes itself from siblings like wait_for_node and subscribe_signals by focusing on blocking until a signal fires.
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 ('Useful for sequencing test steps') and a necessary prerequisite ('The project must be running via run_interactive'). However, it does not explicitly contrast with sibling tools like wait_for_node or get_signal_events, so it lacks explicit exclusions or 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?
Annotations indicate readOnlyHint=false, so the agent knows this is a write operation, and the description adds that it modifies a file 'on disk'. However, it does not disclose potential side effects like overwriting existing connections or whether the scene must be saved. It provides basic context but not deep 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?
Two sentences, front-loaded with the main action, and the alternative guidance is appended without redundancy. Every word contributes value, 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?
Despite having six required parameters and no output schema, the description fully covers the tool's purpose, its static-file context, and the alternative for runtime use. The schema handles parameter details, and the description is sufficient for an agent to understand when and how to invoke 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?
Schema description coverage is 100%, so all six parameters are individually documented with clear descriptions. The tool description itself does not add extra meaning beyond what the schema already provides. Baseline 3 is appropriate because the schema carries the semantic load.
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 specifies the resource ('a signal from one node to a method on another node in a scene file (.tscn) on disk'). It clearly distinguishes the tool from runtime monitoring tools by explicitly naming alternatives, which helps an agent select it correctly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly contrasts this tool with runtime signal monitoring by stating 'For runtime signal monitoring, use subscribe_signals or send_key_sequence.' This gives clear when-to-use and when-not-to-use guidance, going beyond implicit 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, fully covering the safety profile. The description adds minimal behavioral context with the word 'installed', implying it reads the local environment rather than a remote source, but it does not specify 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?
The description is a single, concise sentence with no wasted words. Every word contributes to the tool's purpose, and it is immediately understandable.
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?
Given the tool's simplicity (no parameters, no output schema, safe annotations), the description fully covers what an agent needs to know. The lack of return format details is acceptable for a trivial version query.
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 takes zero parameters, so the description cannot add parameter-level meaning. The baseline for 0 parameters is 4, and the description is sufficient for a parameterless operation.
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 'Get the installed Godot version' uses a specific verb ('Get') and a clear resource ('installed Godot version'). It fully distinguishes this tool from all sibling tools, none of which retrieve version information.
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 tool's purpose is self-evident: to retrieve the installed Godot version. Since no sibling tool offers this capability, explicit usage guidance is unnecessary. The context is clear, though no exclusions or alternative tools are mentioned.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the description need not repeat those. It adds useful context: the tool runs for a specified duration, captures a screenshot, then stops, and requires a display server. This goes beyond the annotations without contradicting them.
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?
Two sentences with no fluff. The first sentence states the core action and stopping behavior; the second differentiates from siblings and adds the display server prerequisite. Every phrase contributes.
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?
The description, combined with the rich annotations and 100% schema coverage, is fully complete for this tool's complexity. It covers purpose, runtime behavior, prerequisites, and sibling differentiation. No return schema is needed as the tool is screenshot-focused and the output path is in the parameters.
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 100%; all parameters already have descriptive comments. The description does not add additional parameter-level meaning beyond what the schema provides (e.g., duration, outputPath, scene). It satisfies the baseline for full schema coverage but offers no extra semantic value.
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 the action clearly: 'Run the project for a duration, capture a screenshot, then stop.' It also differentiates from siblings by explicitly contrasting with capture_screenshot ('Runs the full game') and game_screenshot ('without needing run_interactive'). This provides a specific verb, resource, and 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 context for when to use this tool vs alternatives: it explicitly states it runs the full game unlike capture_screenshot, and does not require run_interactive unlike game_screenshot. It also notes the prerequisite of a display server. However, it does not explicitly say 'use this instead of X when Y' or provide exclusions beyond these comparisons.
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?
Annotations cover read-only/destructive/idempotent flags, and the description adds valuable context about process behavior and performance: it runs in a single Godot process versus separate processes per operation. This goes beyond the annotations, though it does not cover failure semantics or side effects, hence a 4 rather than 5.
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 two sentences, front-loaded with the core purpose, and every sentence earns its place by providing either functional intent or usage context. No filler 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?
Given the moderate complexity of a batch operation and the rich schema with nested operation definitions, the description plus schema is sufficient for an agent to understand invocation. It lacks details about error handling or atomicity, but the performance guideline and clear purpose make it nearly 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 100% for both projectPath and operations, so the structured fields already provide full parameter documentation. The description itself adds no parameter-specific guidance, so the baseline of 3 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 executes multiple scene operations in a single Godot process invocation, distinguishing it from individual scene-operation tools. The verb 'execute' plus the resource 'scene operations' makes 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit usage guideline: 'Use for 3+ operations,' and justifies it by noting performance gains over separate process spawns. This gives the agent clear criteria for when to choose this tool over individual 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?
Annotations already declare readOnlyHint=true and idempotentHint=true, which the description does not contradict. The description adds valuable context by enumerating the exact categories available, which helps the agent understand the tool's scope. It does not detail edge cases, but for a simple read-only listing tool, 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 sentence that immediately states the action and resource, followed by a colon-separated list of categories. Every word earns its place; there is no waste or 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 discovery tool with high schema coverage, strong annotations, and no output schema, the description covers the essentials: the action, the resource, and the valid categories. It does not describe return format, but that is easily inferred for a listing tool and is not critical.
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 100% for the single optional parameter, and the schema description already explains the 'category' parameter. The tool description adds meaning by listing the valid category names explicitly, effectively providing an inline enum set, which exceeds the baseline of 3.
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 'available tools' and specifies the dimension 'by category'. It clearly distinguishes this introspection tool from the many action-oriented sibling tools (e.g., stop_project, export_project) by serving as a discovery/meta tool.
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 the tool: to see what tools exist in a given category. It provides a full list of valid categories, giving context for filtering. However, it does not explicitly state when not to use it or mention alternatives, though no direct alternatives exist.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds valuable context beyond annotations: the expression runs in the context of the current scene and requires the project to be running via run_interactive. It does not discuss error handling or potential side effects of arbitrary expressions, but the annotation bar is low and the added context earns a 4.
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 four sentences long, front-loaded with the core purpose, and every sentence earns its place: function, context/examples, use cases, and prerequisite. 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 simple one-parameter tool with annotations covering safety and no output schema, the description is reasonably complete. It covers the purpose, usage context, execution context, and the critical prerequisite of run_interactive. It could mention error behavior or result formatting, but these are not essential for this tool type.
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 100% coverage with clear examples for the expression parameter. The description adds meaning beyond the schema by explaining the execution context (current scene) and the runtime prerequisite, which helps the agent understand how to construct valid expressions. This exceeds the baseline 3.
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 an arbitrary GDScript expression at runtime and returns the result, with concrete examples. It distinguishes itself from siblings like call_method (method call) and execute_script (script execution) by focusing on arbitrary expressions evaluated in the current scene 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 description provides clear usage context: useful for debugging, querying state, and one-off calculations. It also states the prerequisite that the project must be running via run_interactive, giving a specific when-to-use condition. However, it does not explicitly name alternatives or exclusion cases, so it isn't a full 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context: it operates on the live runtime scene tree and includes dynamically spawned nodes, and notes the run_interactive prerequisite. It doesn't describe return format or pagination, but that's not critical beyond 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?
Two sentences, front-loaded with the primary purpose. The second sentence provides an alternative and a prerequisite. Every sentence earns its place with zero 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 search tool with two optional parameters, the description covers purpose, runtime context, alternative, and prerequisite. There is no output schema, but the return value (matching nodes) is implied. A minor gap is not specifying what information is returned for each match, but overall it's 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?
Schema description coverage is 100%: both 'pattern' and 'typeFilter' have clear descriptions, including defaults and subclass behavior via is_class(). The tool description doesn't need to add more, and it only reinforces the parameter usage at a high level. Baseline 3 applies.
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 ('Search') and resource ('live runtime scene tree'), clearly stating it matches by name pattern and/or type. It also distinguishes from the sibling tool get_scene_tree by explicitly mentioning static .tscn analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a direct alternative: 'For static .tscn analysis, use get_scene_tree.' It also states a prerequisite: 'Requires run_interactive.' This clearly guides when to use this tool versus alternatives.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds value by disclosing that the tool runs headless without requiring a running game, which is a non-obvious behavioral trait. It does not mention edge cases or failure modes, but it goes beyond the 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?
Two sentences, front-loaded with the main purpose, and every word earns its place. It efficiently communicates scope, parameter type, and execution mode without any fluff.
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 moderate complexity and absence of an output schema, the description adequately covers the analysis capabilities (methods, signals, dependencies, exports) and the headless execution context. It does not detail the return format, but the listed items provide a clear expectation of what insights are returned.
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 is fully described (100% coverage), providing clear definitions for scriptPath and projectPath. The description adds extra semantic clarity by explicitly warning 'Takes a scriptPath, not a nodePath,' which prevents a common mistake and enriches understanding 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 specific verbs and resources: 'Analyze a GDScript file' with concrete actions (classify methods, identify signals, map dependencies, list exports). It also explicitly distinguishes from node-based tools by stating 'Takes a scriptPath, not a nodePath,' which clearly separates it from sibling tools like get_node_properties or get_scene_insights.
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 usage context by noting that it operates on a script path, not a node path, and runs headless (no game needed). This helps the agent understand when to use it (static analysis) versus launching a game. However, it does not explicitly name alternative tools or provide when-not-to-use guidance, 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?
Annotations already indicate read-only, idempotent, and non-destructive behavior, so the description adds value by detailing what it returns (all non-default properties or specific ones if listed) and by specifying it operates on saved scene files. This goes beyond the annotations without contradicting them.
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 extremely concise, consisting of two sentences that lead with the core action. Every sentence contributes useful information without any 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 simple read tool with no output schema, the description adequately explains the return behavior (all or specific properties) and distinguishes from runtime access. It could optionally mention the return format, but given the simplicity and annotations, it is sufficiently 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?
The schema covers 100% of parameters, so the baseline is 3. The description adds meaningful context for the 'properties' parameter by explaining the behavior when omitted (all non-default) versus when provided (specific ones), which enhances understanding beyond the schema's brief field 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 reads properties from a node in a saved scene file on disk, using the specific verb 'Read' and mentioning the resource type. It also differentiates from sibling tools by explicitly noting that runtime properties should be handled by evaluate_expression.
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 reads static properties from .tscn files, not runtime state. It explicitly names an alternative tool (evaluate_expression) for runtime properties, but does not enumerate all other alternatives like set_node_properties for writing, which is implicitly clear from the name.
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 meaningful behavioral context beyond annotations: it injects an MCP input receiver, enables capabilities like send_key_sequence and game_state, and communicates via TCP. It doesn't detail side effects or cleanup, but it adds valuable transparency for a run 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?
Three sentences, front-loaded with the core action, followed by capabilities and usage guidance. Every sentence earns its place with no filler or 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 the simple two-parameter schema and no output schema, the description provides enough context to select and invoke the tool: it states the purpose, lists enabled features, and gives an alternative. It could mention lifecycle details or prerequisites, but it is largely complete for an AI agent.
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 100% description coverage for its parameters (projectPath and scene), so the description isn't required to repeat them. The description adds no parameter-specific meaning, but the schema handles semantics adequately.
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 a specific verb and resource: 'Run a Godot project with MCP input receiver injected.' It clearly states the tool's function and differentiates it from siblings by saying 'Use instead of run_project for interactive testing.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly provides usage guidance with 'Use instead of run_project for interactive testing,' naming the alternative and the context in which to choose this tool. This tells the agent when to prefer run_interactive over run_project.
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?
Annotations are all false, providing no positive hints. The description adds context by specifying non-interactive behavior and console output capture, and clarifies what it does not do. While it doesn't disclose potential side effects, it's adequate for a run 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?
Two sentences, directly to the point. Every word adds value; no fluff. Front-loaded with the action 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?
The tool is simple, and the description covers the core behavior and output (console output). It distinguishes from run_interactive and mentions non-interactive mode. No output schema, but the description indicates what to expect.
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 covers 100% of parameters with descriptions, and the description text doesn't add additional parameter meaning beyond that. Baseline of 3 is appropriate since the schema does the heavy lifting.
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 runs a Godot project non-interactively and captures console output, using a specific verb and resource. It distinguishes from sibling tools like run_interactive by explicitly noting what this tool does not do.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'No input, screenshots, or state queries — use run_interactive for those,' providing clear guidance on when to use this tool versus the alternative. This meets the highest standard for usage direction.
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?
Beyond the annotations (readOnly, openWorld, idempotent, non-destructive), the description discloses that this is a network call to a public REST API, implying latency and external dependency. It also explains the return behavior (matching assets with asset_id for install_asset), adding useful 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 two sentences, front-loaded with the primary purpose and followed by a relevant integration note. Every sentence adds value with no redundancy or filler.
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 lack of an output schema, the description partially compensates by hinting at the return value (asset_id for install_asset) and the network call nature. However, it doesn't describe the full return format or pagination behavior, which are important for a search tool with 9 parameters.
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 100%, with all 9 parameters already described in detail. The description's mention of the returned asset_id does not add parameter-level semantics beyond what the schema provides, so the baseline of 3 applies.
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 ('Search') and resource ('Godot Asset Library'), clearly stating it returns addons and project templates. It also distinguishes its purpose by linking the returned asset_id to install_asset, providing context beyond the tool name.
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 establishes the context for use: searching the public Asset Library and returning IDs for installation via install_asset. It doesn't explicitly exclude any alternative tools, but the reference to install_asset and the read-only network call provide clear 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?
The description adds behavioral context by stating it 'simulates analog input with float precision,' implying the event is synthetic. It also mentions the run_interactive dependency. While it doesn't detail side effects on the running game, this goes beyond the minimal annotations (readOnlyHint false, destructiveHint false).
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 that front-load the main purpose and include the key alternative and prerequisite. Every sentence earns its place with no filler.
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 complete schema coverage and minimal annotations, the description provides the essential context: what it does, when to use it (or not), and a critical prerequisite. It could mention return behavior, but the lack of an output schema makes that less critical.
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 100% with detailed descriptions for all parameters. The description adds only the 'float precision' nuance, which is marginal since the schema already specifies value ranges. It doesn't significantly enhance understanding 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 the tool's function: sending a gamepad analog stick or trigger axis event with float precision. It distinguishes itself from sibling tools like send_joypad_button (button events) and send_input (input actions), 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states 'For input actions, prefer send_input,' providing a clear alternative for a different use case. It also notes the prerequisite 'Requires run_interactive,' giving concrete guidance on when this tool is applicable.
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 adds behavioral detail not present in annotations, namely that the click is a 'press+release', and discloses the run_interactive requirement. However, it does not clarify whether the pointer is moved to the coordinates first or mention potential side effects, which is a minor gap given the annotations provide no safety hints.
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 three sentences, each earning its place: the core action, alternatives, and a prerequisite. No filler or redundancy, and key information is front-loaded in the first sentence.
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 (4 params, 2 required, no output schema), the description covers the essential context: what it does, when to use it, and what is required. Parameter details are handled by the schema, so the description is nearly complete. A minor omission is the lack of clarification about pointer movement 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?
Schema coverage is 100%, so the baseline is 3. The description only paraphrases 'coordinates' and does not add extra meaning about the button or doubleClick parameters, which are already well-documented in 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 'Send a mouse click (press+release) at specific coordinates', specifying the action, target, and scope. It also distinguishes itself from sibling tools by explicitly naming send_mouse_motion and send_mouse_drag, 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: 'For cursor movement, use send_mouse_motion. For dragging, use send_mouse_drag.' It also notes the prerequisite 'Requires run_interactive', giving clear when-to-use and when-not-to-use context with specific alternative 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?
The description discloses key behavioral traits: it modifies the scene file on disk and changes are permanent. This goes beyond the sparse annotations (all false hints) and adds context about persistence and file mutation. It does not discuss potential side effects like overwriting existing properties, but the explicit 'permanently' and 'on disk' provide meaningful 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 extremely concise: two sentences, with the first stating the core purpose and the second giving the alternative. Every word earns its place, and the main information is front-loaded.
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 straightforward mutation tool with no output schema, the description covers the essential context: what it does, where it acts (disk), and when not to use it. It lacks details on return values or error handling, but these are not critical for a set operation and the tool is simple enough (4 required params, full schema descriptions) to be considered adequately 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 provides full descriptions for all four parameters, so baseline is 3. The tool description does not add any additional parameter-level detail beyond what the schema already documents, such as value formats or examples.
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: 'Set properties on a node in a saved scene file (.tscn) on disk permanently.' This specifies the verb (Set), resource (properties on a node in a scene file), and scope (on disk permanently). It also distinguishes from the sibling tool set_property by pointing to the alternative for live runtime changes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage guidance is explicit: 'For live runtime changes, use set_property instead.' This tells the agent exactly when to use this tool vs. the alternative, making the decision process straightforward.
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?
Annotations are all false, offering minimal safety profile, but the description adds meaningful context: persistent monitoring, retrieval via get_signal_events, and the run_interactive prerequisite. It does not disclose unsubscribe behavior or lifecycle, but the persistent nature is clearly 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?
Three concise sentences, front-loaded with the core purpose. Each sentence adds functional value (purpose, retrieval, alternative/prerequisite), with no filler.
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 main workflow: how to subscribe, how to retrieve events, when to use an alternative, and a prerequisite. However, it doesn't describe any return value or unsubscription process, which could be useful but is not critical given the tool's relative simplicity and schema coverage.
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?
Input schema has descriptions for both params (100% coverage), so the baseline is met. The description adds no additional parameter semantics beyond what the schema provides.
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 'Subscribe to signals on a node for persistent monitoring,' identifying the specific action and resource. It distinguishes from siblings by contrasting with send_key_sequence and referencing get_signal_events for retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'For single-sequence monitoring, prefer send_key_sequence with collectSignals,' providing an alternative for a different use case. Also states 'Requires run_interactive,' giving a prerequisite. This is strong guidance for when to use this 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?
Annotations already declare read-only and idempotent. The description adds context about static rendering and the display server requirement, which goes beyond annotations. It does not contradict annotations and adds useful 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?
Three concise sentences, each serving a purpose: describing the action, distinguishing from alternatives, and stating a key requirement. No wasted words.
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?
Given the rich schema and annotations, the description covers purpose, usage, and an important environmental requirement. No output schema exists, so return values need not be explained. The tool is simple enough that this description is sufficient.
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 100%, so the baseline is 3. The description does not add additional parameter-level semantics beyond what the schema already provides. It mentions 'scene file' and 'viewport' but these are generic and not parameter-specific.
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 renders a scene file statically and saves the viewport as a PNG. It explicitly differentiates from live capture alternatives by saying 'No running game needed' and naming game_screenshot and run_and_capture.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use vs alternatives: 'For live game captures, use game_screenshot or run_and_capture.' Also notes a prerequisite ('Requires a display server') and that no running game is needed, giving clear context for choosing this 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?
Annotations already cover readOnly, idempotent, and non-destructive behavior. The description adds valuable behavioral context: 'Slowest verification path' (performance) and 'Requires run_interactive' (prerequisite), which go beyond annotation 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?
Every sentence serves a distinct purpose: purpose, usage condition, alternatives, inline capture guidance, and prerequisite. It is concise despite covering multiple aspects, with no filler words.
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 single-parameter tool with no output schema, the description is complete: it explains what the tool does, when to use it, alternatives, and a prerequisite. The agent has enough information to select and invoke it 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?
Schema description coverage is 100% for the single optional parameter outputPath, so the baseline is 3. The description does not add parameter-level detail beyond what the schema provides, but it doesn't need to.
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 and resource: 'Capture a screenshot from a running interactive project.' It distinguishes itself from sibling tools by explicitly contrasting with game_state, evaluate_expression, get_runtime_errors, and send_key_sequence for inline captures.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: 'use only when visual appearance itself matters', and names specific alternatives for other cases. It also states a clear prerequisite: 'Requires run_interactive.'
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is covered. The description adds meaningful behavior beyond these: it reads from disk (not a running scene), returns data as JSON, and emphasizes no running game is required. This gives the agent a clearer picture of the tool's operational behavior without contradicting the 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 two sentences, front-loaded with the core function ('Read a scene's node tree...') and then a concise alternative. No filler words or repetition; every sentence earns its place.
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?
The tool is simple (read a file and return JSON), and the description covers the essential aspects: what is read, where it comes from (disk), the output format (JSON), and the contents of the JSON (names, types, properties, hierarchy). The alternative use case is addressed, and the schema/annotations handle parameter and safety details, so nothing essential is missing.
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 fully describes both parameters (projectPath and scenePath), achieving 100% schema coverage. The description does not add extra parameter-level detail, but that is unnecessary because the schema already provides clear meaning. The baseline of 3 applies since the description contributes nothing 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 'Read' and identifies the resource as 'a scene's node tree from a .tscn file on disk', with a clear list of what is returned (names, types, properties, hierarchy). It also explicitly distinguishes from the sibling tool get_scene_insights by stating the alternative for architecture analysis, 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states 'No running game required', establishing a clear context for when to use this tool (file-based inspection without a live project). It also provides a direct when-not instruction by saying 'For architecture analysis, use get_scene_insights', which guides the agent to another sibling tool for a specific alternative use case.
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?
Annotations are all false, offering minimal safety context. The description compensates by clarifying the tool launches the editor GUI rather than the game, adding a meaningful behavioral distinction. It does not disclose whether the call blocks or returns immediately, 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?
Two concise sentences that front-load the primary action and immediately follow with a clarifying exclusion. Every word contributes to understanding without 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 simple one-parameter tool with no output schema, the description covers the core purpose, exclusions, and alternatives. It is complete in context and requires no additional explanation to use 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?
Schema coverage is 100%, with projectPath already described as 'Path to the Godot project directory.' The description adds only the general reference to 'a project' and does not provide additional parameter-specific detail, which is acceptable given full 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?
Uses a specific verb 'launch' with a clear resource: 'the Godot editor GUI for a project.' It explicitly distinguishes itself from run_project and run_interactive by stating it does not run the game, making the purpose unambiguous relative to siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-not-to-use guidance: 'Does not run the game' and names exact alternative tools: 'use run_project or run_interactive for that.' This is a clear directive for 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?
Annotations already indicate destructiveHint=true; the description adds context by explaining the tool 'resets game state' and requires the project to be running via run_interactive. This goes beyond the raw annotation without contradicting it.
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 three concise sentences: the action, the use case, and the prerequisite. Every sentence adds value 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 simple tool with no parameters and no output schema, the description fully covers what it does, when to use it, and the necessary precondition. No critical information is missing.
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 correctly does not attempt to describe nonexistent 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 states a specific verb 'reload' with a clear resource ('current scene') and context ('running interactive Godot project'). It clearly distinguishes from scene-editing siblings by focusing on runtime reload.
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 a clear use case ('resetting game state during test loops') and a prerequisite ('must be running via run_interactive'). It does not explicitly name alternatives or when-not conditions beyond the prerequisite, so not a full 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?
The description adds valuable behavioral context beyond annotations: 'Returns delivery confirmation only, not the effect' and 'Requires run_interactive'. It does not contradict annotations (all false), and the return-value caveat is important since there is 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?
Three sentences, front-loaded with the core purpose, then return semantics and the alternative. Every clause earns its place, including the parenthetical 'no shell sleeps needed', which reinforces why send_key_sequence is preferred for multi-step.
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-input tool, the description covers purpose, prerequisite, return behavior, and the main alternative. With no output schema and well-covered parameters, nothing critical is missing for an agent to select and invoke the tool 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?
Schema description coverage is 100%, so baseline is 3. The description adds 'InputMap action' context and examples for the action parameter, but the pressed parameter behavior is already fully described in the schema. Minimal extra value beyond the structured 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 'Send a single Godot InputMap action... to a running interactive project', giving a specific verb, resource, and target. It distinguishes itself from send_key_sequence by noting the alternative for multi-step testing, and from other input tools by specifying 'InputMap action'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'for multi-step testing prefer send_key_sequence' and describes what that tool offers (batching, waits, checkpoints). It also states the prerequisite 'Requires run_interactive', giving clear context for when this tool is appropriate.
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 adds meaningful behavioral context beyond annotations: 'Changes are immediate but NOT saved to disk' discloses the ephemeral nature, and 'Requires run_interactive' identifies a precondition. While annotations indicate non-read-only, the description clarifies the exact scope of the side effect.
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 two sentences long, front-loaded with the primary action, and every word adds value. It avoids redundancy and clearly communicates the core purpose in a compact form.
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 setter tool, the description is complete: it explains the action, the ephemeral behavior, the prerequisite, and the alternative for permanent changes. The schema fully documents parameters, and no output schema is needed for a void operation. The distinction from set_node_properties covers the main contextual gap.
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 already provides full descriptions for all three parameters with 100% coverage. The description adds no additional parameter-specific semantics, so a baseline score of 3 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's function: 'Set a property on a live node at runtime.' It uses a specific verb and resource, and distinguishes itself from the sibling tool set_node_properties by emphasizing the runtime-only nature of the change.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: mention of 'use set_node_properties for permanent changes' names the alternative tool and clarifies when this tool is appropriate (temporary runtime changes). It also states the prerequisite 'Requires run_interactive,' giving context for invocation.
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 destructiveHint annotation already signals this is a mutating operation; the description adds context that it only affects the running project and not the editor, which is a behavioral nuance beyond the annotation's basic safety 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?
Two concise sentences with the primary action in the first and a clarifying boundary in the second. No wasted words, fully front-loaded.
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 zero-parameter tool with no output schema, the description is complete. It specifies what is stopped and what is not affected, providing enough context 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the description needs no parameter details. The baseline for no-parameter tools is 4, and the description stays silent on parameters as expected.
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' and identifies the resource as the 'currently running Godot project', clearly distinguishing from launch_editor. The clarification about not affecting the editor further differentiates it from 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?
It implicitly states when to use by clarifying that the editor is unaffected, which hints at the alternative of using launch_editor. However, it does not explicitly name alternatives like run_project or pause_game, so it falls short of a full when/when-not list.
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?
The description discloses blocking behavior (waits until found or timeout), return semantics (boolean whether found or timed out), and a runtime prerequisite (must be running via run_interactive). This goes well beyond the annotations, which only indicate read-only, idempotent, and non-destructive. No contradiction with 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 three sentences, front-loaded with the primary action, and every sentence adds value. It includes a purpose, a motivating use case, a return-value note, and a prerequisite without any fluff or repetition.
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 two-parameter tool with no output schema, the description covers the essential behavior (blocking wait, return value), the prerequisite for use (run_interactive), and a practical use case. The schema and annotations fill in parameter details and safety traits, leaving no significant 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?
The input schema fully describes both parameters (nodePath and timeout) with examples and default values, so the description adds little beyond the schema. The description repeats the example node path format but does not introduce new semantics. With 100% schema coverage, a baseline of 3 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 action ('Block until a node appears in the scene tree') with a specific resource (scene tree node). It distinguishes itself from siblings like wait_for_signal by focusing on node appearance, and includes a concrete example ('Player/Sword' after equip). The verb 'block' and target 'node' make 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 explicitly notes it is 'useful for waiting on dynamically spawned nodes' and gives a typical use case. It also states a prerequisite: 'The project must be running via run_interactive.' However, it does not explicitly mention when not to use it or name alternative tools (e.g., wait_for_signal for signals), though the context strongly implies the intended scenarios.
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?
Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description reveals important behaviors: automatic resolution/verification of assetId, default stripping of a wrapping folder, overwriting of existing files, deferred import, and rejection of path-traversal entries. These are non-obvious and critical for safe usage, adding significant value beyond the structured metadata.
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?
Four well-structured sentences, each carrying distinct value: purpose, source methods, extraction and overwriting, and security check. No filler or redundancy; front-loaded with the core action.
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 7 parameters, no output schema, and moderate annotations, the description covers security, file system effects, import behavior, and both usage paths. It is sufficient for an agent to invoke the tool correctly and anticipate side effects.
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?
Although schema coverage is 100%, the description enriches key parameters: it explains that assetId resolves download URL and sha256, that downloadUrl is a direct .zip link with no hash verification, and that subdirectory/stripTopLevel control extraction. This goes beyond the schema's basic type/description and clarifies trade-offs.
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 begins with a clear verb+resource pair: 'Download an asset from the Godot Asset Library and extract it into a project.' It precisely identifies the action and destination, and distinctly separates this from sibling tools like search_assets (which only searches) or export_project (which exports).
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 explains how to use the tool via assetId or downloadUrl, and implies it is for installing assets/addons. It does not explicitly name alternatives or exclusion criteria, but the context is clear enough that an agent can decide 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?
The description adds context beyond the annotations by explaining that it supports any Godot-recognized key name, including modifiers, and that it sends a single key event. It also communicates the behavioral difference from send_key_sequence (server-side processing in one round-trip). However, it does not mention error handling or side effects, which would elevate transparency further.
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 and well-structured: it starts with the core action, then provides an alternative recommendation, and ends with a prerequisite. Each sentence earns its place with no redundant information.
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 input-sending tool with 100% schema coverage and no output schema, the description is complete. It covers the tool's purpose, usage context, prerequisite, and alternative for multiple keys, sufficiently enabling an agent to decide when and how 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 already covers all 6 parameters with 100% description coverage. The description adds value by clarifying the key naming convention ('Supports any key name recognized by Godot') and confirming modifier key support, which goes beyond the generic 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 function: 'Send a single keyboard key event to a running interactive Godot project.' It uses a specific verb and resource, and it distinguishes itself from the sibling tool send_key_sequence by noting that for multiple keys, send_key_sequence should be preferred.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool versus send_key_sequence, stating 'For sending multiple keys, prefer send_key_sequence.' It also specifies a prerequisite: 'The project must be running via run_interactive.' This clearly defines the applicable context.
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?
Annotations are all false, providing no safety or behavioral hints, so the description must carry the disclosure burden. The description adds meaningful context: it's the primary testing tool, it uses inline checkpoints for waits/state/screenshots, and it collects signals. However, it does not explicitly discuss possible side effects (e.g., game state mutation) or error handling, leaving 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 is compact, front-loaded with the tool's role, and every sentence adds value. It packs a lot of information (inline checkpoints, replacement of loops, requirement) into two sentences without 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?
The schema is rich and the description is comprehensive. The collectSignals parameter in the schema already explains that signal events are returned in the response, so the description doesn't need to repeat that. Combined with the clear purpose and usage guidance, the tool is well-defined for an agent to select and invoke 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?
Schema description coverage is 100%, so baseline is 3. The description enhances the schema by summarizing the purpose of inline checkpoints and how they integrate into a single sequence, which is not apparent from the schema alone. It also gives a concrete example in the keys parameter description, adding practical clarity 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 'Primary gameplay testing tool' and explicitly says it sends multiple raw keys and/or InputMap actions in one round-trip with inline checkpoints. It also distinguishes itself from sibling tools send_input/send_key loops, making the tool's purpose and scope unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly mentions that this tool replaces send_input/send_key loops with shell sleeps and separate verification calls, clearly indicating when to use it over alternatives. It also specifies a prerequisite ('Requires run_interactive'), giving the agent actionable guidance on when this tool is applicable.
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?
Adds operational context beyond annotations: describes 'fast' performance, requires run_interactive, and discloses conditional return of Player position. Annotations (readOnly, idempotent, non-destructive) are complemented, not contradicted.
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?
Three tightly packed sentences with front-loaded purpose, followed by alternatives and a prerequisite. No filler; every clause adds useful information.
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?
Given no output schema, the description adequately covers return values (scene name, autoload vars, Player position), usage context, prerequisites, and fallback alternatives. It fully equips an agent to decide when and how to invoke 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?
Tool has zero parameters, so baseline is 4 per rubric. The description adds value by outlining what the tool returns, though it naturally cannot add parameter-level detail since none exist.
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 tool returns scene name, autoload variables, and Player position, with a specific verb ('returns') and resource. Explicitly differentiates from game_screenshot by noting it is preferred for gameplay logic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: preferred over game_screenshot for gameplay logic, and directs users to evaluate_expression or get_node_properties for state not exposed via autoloads. Also mentions inline state capturing via send_key_sequence and the prerequisite run_interactive.
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 MCP server](https://glama.ai/mcp/servers/Vollkorn-Games/godot-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Vollkorn-Games/godot-mcp)

Score Badge

Copy to your README.md:

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

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/Vollkorn-Games/godot-mcp'

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