Beckett — MCP for Godot

Overview Schema Related Servers Score Discussions

Server Quality Checklist

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

Latest release: v1.12.1
Disambiguation4/5
Most tools have clearly distinct purposes, but there are a few overlapping pairs like read_file/read_script and logs_read/game_logs. Descriptions clarify the differences, yet these similar utilities could still cause initial confusion for an agent.
Naming Consistency4/5
The naming predominantly follows a verb_noun pattern (get_scene_tree, create_node, call_method), but there are exceptions like logs_read, runtime_get_property, game_logs, and doctor that break the pattern, introducing minor inconsistency.
Tool Count3/5
54 tools is a large number, but the server covers a broad domain including scene editing, runtime debugging, scripting, and project settings. The count is justified for a comprehensive Godot MCP, though some overlapping file/log utilities could be consolidated.
Completeness5/5
The toolset provides near-comprehensive lifecycle coverage for scenes, nodes, scripts, resources, properties, signals, and project settings, plus runtime inspection and debugging. Minor gaps like file deletion and direct runtime property setting exist, but the domain is otherwise thoroughly covered.
Average 4.2/5 across 54 of 54 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 1 community issues answered or closed in the last 6 months
- 37 commits in the last 12 weeks
- Last stable release on August 11, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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.
This repository includes a glama.json configuration file.
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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it destructive, and the description adds 'undoable', which is a behavioral trait not covered by annotations. This helps the agent understand the operation is reversible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, but it omits critical parameter semantics. While concise, it sacrifices completeness for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple deletion tool with one parameter and no output schema, the description should at least specify the expected format of 'target' and potential side effects on child nodes. It is underwhelming.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'target' has no description in the schema or the tool description. With 0% schema description coverage, the description fails to explain what value the parameter expects (e.g., node path, name).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Remove a node from the open scene') and the undoability. It differentiates from siblings like create_node, duplicate_node, rename_node, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as reparent_node or duplicate_node. It lacks context for prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and destructiveHint=false, and the description adds the res:// scope. However, it does not disclose return format, error behavior, or encoding. The description aligns 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 one concise sentence, front-loading the verb and resource. Zero 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 simple read tool, the description is minimal but lacks explicit return value and usage context. Given no output schema, the agent must infer the return content. The description is adequate for basic use but 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?
The schema provides only a 'path' string with no description. The description clarifies that the path is relative to res://, which compensates partially, but it does not specify path format or any constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads a script/text file and specifies the source location as res://. This is specific and distinguishes it from similar sibling tools like read_file.
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 instead of alternatives like read_file, search_files, or write_script. The description only states the function without any context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description aligns with annotations (destructiveHint=true) by stating it saves to a path, implying file creation. However, it does not disclose whether existing files are overwritten, permission requirements, or error states. With annotations already indicating destructiveness, the description adds minimal behavioral context beyond reinforcing the creation action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single 20-word sentence that conveys the main action and optional feature. It is front-loaded with the key verb and resource. No unnecessary words, but could be more structured (e.g., separate optional parameters). Still, it earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 params, no output schema), the description covers the core function. However, it lacks details on overwrite behavior, error handling, and return value. Compared to sibling 'set_resource', it should clarify that it creates new files. The description is adequate but not fully comprehensive.
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 only 33% of parameters (path has description). The description compensates by mentioning 'class' and 'path' implicitly, and adds that properties is an optional dict for initial values. It also clarifies that path should end in .tres/.res, which is useful semantic detail not in the schema. While not exhaustive, it adds value beyond the schema for 2 of 3 params.
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 (create), the resource type (Resource of given class), and the destination (res:// path ending in .tres). This distinguishes it from siblings like 'set_resource' which likely updates existing resources. The verb+resource+destination pattern is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'set_resource', 'write_file', or 'instance_scene'. It does not specify prerequisites, error conditions, or scenarios where this tool should be avoided. The description lacks any usage context beyond the basic operation.
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 destructive behavior (destructiveHint=true). The description adds valuable context: path-traversal guarding and the side effect of refreshing the editor filesystem, which goes beyond the raw annotation 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 a single, efficient sentence that front-loads the core action and includes key constraints and side effects. Every part earns its place with 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?
For a simple two-parameter file-writing tool with no output schema, the description covers the essential context: target locations, safety behavior, and a side effect. It could mention that it overwrites existing files, but this is implied by 'write' and the destructiveHint annotation.
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 only parameter names (path, content) with no descriptions. The description partially compensates by specifying the allowed locations (res://, user://) and the path-traversal guard, adding meaning to 'path'. It does not describe 'content', but that is fairly self-explanatory.
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 writes a text file under res:// or user://, which is a specific verb and resource. It does not explicitly distinguish from the sibling write_script, but the mention of 'text file' versus script implies a difference.
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 like write_script. The description focuses on what it does rather than when to choose it over other file-writing siblings.
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 'undoable' which communicates revertibility, a useful behavioral detail. It also states 'previously connected' which sets a precondition. This adds context beyond the readOnlyHint=false and destructiveHint=false 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 with no extraneous words, earning a high score for structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 required parameters and no output schema, this description is too thin. It does not explain parameter roles, what 'undoable' means precisely, or what happens if the signal isn't connected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions cover 0% of parameters, and the description offers no parameter semantics. The parameter names (from, to, signal, method) provide weak hints but are undefined, so the agent must infer meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Disconnect' and the resource 'signal', making the tool's action clear. The qualifier 'previously connected' sets scope and distinguishes it as the inverse of connect_signal among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'previously connected' implies the tool should be used when undoing a signal connection, but it does not explicitly name alternatives or exclusions, leaving the usage guidance implicit.
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 declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, indicating a mutation that is not destructive. The description adds the useful behavioral detail that the operation is 'undoable', which goes beyond the annotations. It does not discuss edge cases like invalid indices, but the undoable note adds meaningful context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that immediately states the action and scope, with no filler. It is 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?
For a tool with two required parameters and no output schema, the description is sparse. It omits parameter format details, index semantics, and any error/return behavior. Given the low schema coverage and lack of annotations beyond the basics, more detail is needed for reliable usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must clarify the meaning of 'target' and 'to_index'. It does not specify that target is likely a node path/name, nor does it explain whether to_index is zero-based or what happens on out-of-range values. This leaves the parameters under-explained.
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 ('Reorder') and identifies the resource ('a node within its parent') and the operation's focus ('to a new child index'). This clearly distinguishes it from the sibling reparent_node, which moves a node to a different 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 phrase 'within its parent' implies the tool is for reordering siblings, not reparenting, but it does not explicitly say when to use this tool versus reparent_node or other node operations. No exclusions or alternatives are mentioned, only an implied scope.
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 context beyond annotations by noting the operation is undoable, which is a safety-relevant behavior not captured by the annotations. It also scopes the action to the open scene, providing operational context. No contradiction exists with 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, compact sentence that immediately front-loads the core action and context. Every word contributes value with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the simple mutation and the 'undoable' note provide some context, the description omits how to identify nodes, what happens if the new parent is invalid, and alternative conditions that could affect invocation. For a tool with no output schema and sparse annotations, this leaves noticeable 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 description implies that 'target' is the node being moved and 'new_parent' is the destination, adding some meaning beyond the bare string types in the schema. However, it does not specify how to reference nodes (e.g., NodePath, name, or ID), and with 0% schema coverage, this lack of operational detail leaves room for incorrect usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Move', the resource 'node', and the specific operation 'under a new parent' in the open scene, effectively distinguishing it from siblings like move_node which likely handles transforms. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool vs alternatives like move_node, rename_node, or delete_node. It does not mention any preconditions, exclusions, or explicit contexts where reparent_node is preferred, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations show readOnlyHint=false (modifying) and destructiveHint=false, but description adds the critical 'undoable' trait, which is not in annotations. This extra context helps the agent understand the reversible nature of the operation, going 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?
A single, well-structured sentence that is immediately informative. Every word adds value; no redundant or extraneous 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?
The tool is simple with 2 required params and no output schema. The description covers the core semantics but omits details like what happens if the node doesn't exist, if the script is already attached, or error conditions. Adequate but not thorough for a modifying action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must compensate. It clarifies that 'path' expects a res:// URL, which is helpful, but does not explain 'target' (likely a node path) or any constraints. The partial compensation is insufficient given both parameters are required and undocumented in 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 action (attach), the resource (script with res:// path), the target (node in open scene), and an important characteristic (undoable). It distinguishes itself from sibling tools like write_script or validate_script 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 when to use (to attach a script to a node) but provides no explicit guidance on when not to use or alternatives among the many sibling tools. The context is clear but lacks 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 (readOnlyHint=false, destructiveHint=false) indicate a non-read, non-destructive operation. The description adds 'undoable' context, enhancing transparency. However, it does not disclose potential side effects such as validation or node existence requirements, leaving some behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that front-load the core action and critical context (undoable, node path format). Every word serves a purpose without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the persistence and undoability, and hints at parameter format, but omits details about signal and method parameters, return values, and error conditions. For a 4-parameter tool with no output schema, this leaves moderate gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only explains 'from' and 'to' as node path/name, but provides no semantics for 'signal' or 'method'. This is insufficient for an agent to understand all parameter roles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Connect a node's signal to a method on another node'. It specifies the verb (connect) and the resources (node's signal, method on another node), distinguishing it from siblings like disconnect_signal and call_method.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for persistent connections with 'persisted into the scene (undoable)' and clarifies that from/to are node paths/names. It does not explicitly contrast with alternatives like disconnect_signal or call_method, but the context is clear enough for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false, but the description adds the important behavioral trait 'undoable', which is beyond the annotations. It also clarifies the operation is not destructive despite being a write.
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 with two short sentences. Information is front-loaded, with no redundant or unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (3 params, no output schema), the description meets basic needs but lacks details on error scenarios (e.g., invalid class), duplicate name handling, or return value. It does not fully compensate for the missing output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds limited value beyond the input schema: it reiterates the parent default but does not explain the 'name' parameter or provide additional syntax/format guidance for 'type' (though schema gives an example). Schema description coverage is high but still missing details for 'name'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create' and resource 'node', with specific context: 'of the given class', 'add it to the open scene', and 'undoable'. This distinguishes it from sibling tools like delete_node or duplicate_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 explains the 'parent' parameter's default behavior but does not provide explicit when-to-use, when-not-to-use, or alternatives among siblings, such as instance_scene or other creation methods.
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 and destructiveHint=false, confirming a safe read. The description adds that it returns signatures of properties and methods, which is useful but does not heavily elaborate beyond what is obvious from the name and 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, zero filler. The first sentence clearly states the action and output, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description could explain the return format (e.g., JSON structure). It mentions 'with signatures' but does not describe the structure, leaving some ambiguity for a complex 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 50%; the 'inherited' parameter has a description. The description implies 'class' is the class name (e.g., 'Node2D') but does not specify format or provide examples, partially compensating but not fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'a class's properties and methods (with signatures)', and explicitly connects to sibling tools 'set_property' and 'call_method'. It distinguishes itself from siblings like 'find_classes' by positioning itself as the discovery key for full domain coverage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: before calling 'set_property' or 'call_method'. However, it does not explicitly state when not to use it or mention alternatives like 'find_classes' for just listing class names.
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 'undoable' which is not conveyed by the annotations (readOnlyHint=false, destructiveHint=false). This provides useful behavioral nuance about reversibility. 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 that is front-loaded with the verb and contains no filler. 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With three parameters, no output schema, and sparse annotations, the description is too brief. It omits prerequisite details beyond 'open scene', how parent and name are used, and error/edge-case behavior. The tool is under-specified for an agent to use reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only 'scene' is described). The description does not explain the 'name' or 'parent' parameters, and the 'scene' hint in the description largely repeats the schema. It fails to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (instantiate), the resource (a packed scene with res://*.tscn), and the target (as a child in the open scene). This distinguishes it from siblings like open_scene or create_node.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'in the open scene' implies the prerequisite of an open scene, providing clear context. However, it does not explicitly mention alternatives or when not to use this tool, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 meaningful behavioral context by specifying that sampling occurs 'over several frames' and that it returns a 'sample series', which is not evident from annotations alone. 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, front-loaded sentence that begins with the verb 'Sample' and includes the key purpose. It is concise, with no redundant words, and every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, four parameters with no descriptions, and no mention of failure conditions, return format details, or how the sample series is structured. The description is minimal and leaves significant gaps for an agent attempting to invoke this tool correctly, especially without parameter explanation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage for all four parameters, so the description must compensate. It only vaguely references 'a node's property' and 'over several frames' without explicitly defining path, property, samples, or interval_ms. The numeric parameters and their units are left entirely implicit, which is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool samples a node's property over multiple frames in the running game, with a specific purpose of detecting movement or changes. This verb+resource+context structure distinguishes it from siblings like runtime_get_property, which reads a single value, and render_probe, which deals with rendering.
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 it ('detect movement/changes') and clearly conveys its temporal sampling nature, but it does not explicitly mention alternatives or situations where it should not be used. This gives clear context without exclusions, matching a score of 4.
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 readOnlyHint=false and destructiveHint=false. The description adds 'undoable,' a behavioral trait not captured in annotations, clarifying that the mutation is reversible. 'In the open scene' further scopes the operation. This provides valuable context beyond the structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence, efficiently conveying the purpose and a key behavioral trait. It is front-loaded with the action and resource, with no wasted words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two parameters and no output schema, the description provides the essential information: what it does, where (open scene), and a behavioral note (undoable). The missing parameter details are a minor gap, but overall the description is sufficient for an agent to understand and invoke the tool correctly in most cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the parameters 'target' and 'name.' While their names are somewhat self-explanatory, the description adds no explicit semantics or usage details. It relies entirely on the parameter names, which is insufficient given the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Rename a node in the open scene.' It identifies the verb (rename), resource (node), and scope (open scene), distinguishing it from sibling tools like move_node or delete_node. The 'undoable' qualifier adds specificity without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context 'in the open scene' implies when to use the tool, but no explicit alternatives or exclusions are given. It does not mention when not to use it or compare to similar operations like reparent_node or duplicate_node. This is adequate but not comprehensive.
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 non-destructive. The description adds useful behavior beyond annotations: search scoped to res://, regex support via regex=true, and output format as file:line matches. This provides meaningful context about how the tool behaves.
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 short sentences, front-loaded with the verb and resource, no redundant wording. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so the description must explain return values. It mentions 'file:line matches' but lacks specifics on exact data structure, max parameter behavior, and edge cases like no matches. Adequate for a simple search tool, but with gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only ext described). The description clarifies query as a substring or regex pattern and explains regex=true toggles regex mode, but max is left unexplained and ext is not elaborated beyond the schema. Partial compensation for low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it searches file contents under res:// for a substring or regex, and returns file:line matches. This is a specific verb+resource+scope and distinguishes from siblings like read_file (reads entire files) and find_nodes (searches scene tree).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when/when-not guidance for selecting this tool over alternatives like find_classes or find_methods. The purpose is clear, so usage is implied, but no exclusions or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds that it works on the 'RUNNING game' and has a timeout, but it does not explain timeout behavior (e.g., error vs. return) or how path resolution works. The added context is modest but not unseen in 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 concise sentences with no redundancy. The primary purpose is front-loaded, and the usage hint is separated clearly. Every word contributes to understanding.
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 blocking read-only tool with annotations covering safety, the description covers core purpose and usage. It lacks details on timeout behavior and return value, but these are not critical for a synchronization primitive. It is adequately complete for guiding selection and basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'path/name' for the path parameter and 'timeout' for timeout_ms, but does not explain the format of path (e.g., absolute scene path vs. name) or the unit/default for timeout_ms. This is insufficient for an agent to construct correct parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool blocks until a node appears in the running game or times out. This specific verb ('Block') plus resource ('node') and outcome ('appears... or timeout') distinguishes it from siblings like wait_until, which is likely a generic wait.
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 says 'Use after play_scene to sync before driving', providing clear context for when to use it. It does not explicitly list alternatives or exclusions, but the stated use case is unambiguous enough for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes core behavior: copying files, setting/opening main_scene, and the force parameter for overwrites. The annotations (destructiveHint: false) are mildly contradicted by the ability to overwrite files, but the description clarifies that overwriting requires explicit force. Missing details on error handling or return values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise (two main sentences) and front-loads the primary action. The extra sentence about generic templates is somewhat redundant but not overly verbose. Could be slightly tighter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (file copying, main_scene handling, overriding), the description covers the essential aspects but omits details like return values, error scenarios, or what happens if the template lacks files. No output schema further increases the need for clarity.
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%, and the description adds context: for 'template' it gives an example ('platformer-2d') and explains that calling without it lists available templates. For 'force', it describes the default behavior. This adds meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: instantiate a bundled or project template into res://, copying files and optionally setting/opening a main_scene. It distinguishes this tool from siblings by its unique purpose of template instantiation; no other sibling tool serves this function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: 'Call with no template to list what's available.' Also explains that project templates override bundled ones. However, it does not specify when not to use this tool or compare it directly to alternatives, though the context makes it clear this is the only template-related tool.
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, covering the safety profile. The description adds the behavioral constraint that paths are restricted to res:// directories, which is useful. It does not mention sorting, recursion, or hidden files, but for a read-only list operation this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that front-loads the action and resource. Every word contributes meaning, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 listing tool with one parameter and no output schema, the description provides the essential facts: what is listed (entries) and where (res:// directory). While it doesn't state return format or recursion, these are less critical for such a well-scoped operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does by indicating the 'path' parameter should be a res:// directory, giving meaning to the otherwise bare string parameter. However, it does not explicitly map the parameter name to this semantics or address the optional/required nature.
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 'List entries (dirs + files) of a res:// directory' uses a specific verb 'List' and clearly identifies the resource and scope (res:// directory, dirs + files). This distinguishes it from sibling tools like search_files or read_file, 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 clearly implies when to use the tool: whenever an agent needs to enumerate directory contents under res://. No explicit exclusions or alternatives are stated, but the context is sufficiently clear for a straightforward listing operation.
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 safety profile is known. The description adds the scoping constraint of res:// or user:// paths, which is useful, but does not elaborate on error handling or return behavior. This is adequate given 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 concise sentence with no filler. It front-loads the action and resource, and every word contributes meaning.
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 read operation with one parameter and strong annotations, the description covers the essential information: what it reads and from where. No output schema exists, but the tool's simplicity means the description is sufficient for an agent to select and 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 provides no description for the 'path' parameter (0% coverage), so the description must compensate. The phrase 'by res:// (or user://) path' clarifies the expected format, which is essential for correct invocation. It does not explain whether the path is case-sensitive or how to reference files outside these schemes, but the key semantic 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?
The description clearly states the tool reads a text file, using the specific verb 'Read' and identifying the resource type ('text file') and path scheme ('res:// or user://'). This distinguishes it from sibling tools like read_script or logs_read.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for reading text files from Godot's res:// or user:// paths, but it does not explicitly contrast it with alternatives such as search_files or read_script. There are no exclusions or explicit when-not-to-use conditions, so the guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive behavior (destructiveHint=true). The description adds that the change persists to project.godot, which is key context beyond the annotations. It also clarifies parameter aliases (setting/name). 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 two sentences: the first states the action and persistence, the second explains parameter usage with an example. No fluff, front-loaded, and every sentence contributes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, and the description covers its purpose and main parameter. However, the input schema lists only 'value' as required, yet the description implies a path must be provided without explicitly stating that 'setting' or 'name' is necessary. This could lead the agent to invoke the tool without the required path. There is no output schema, so return behavior is not described.
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 has no descriptions (0% coverage). The description compensates by explaining that the property path goes in 'setting' and that 'name' is accepted, with an example mapping path to value. It does not explicitly describe the 'value' parameter, but the example implies its role. This is meaningful guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Set a ProjectSettings value and persist project.godot.' It also provides a concrete example with a property path. This distinguishes it from siblings like get_project_setting (read) and set_property (generic setter).
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 setting persistent project settings, but it does not explicitly contrast with alternative tools such as set_property or get_project_setting. There is no 'when not to use' guidance. The example helps, but selection criteria are not 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 indicate the tool is not read-only and not destructive, and the description clearly states it stops the play session, aligning with that. However, little additional context is provided about side effects, permissions, or error conditions, leaving the description to carry minimal 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?
The description is a single, short sentence that gets straight to the point. No unnecessary words or 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 action tool with no parameters and no output schema, the description fully captures the tool's purpose. Combined with the sibling list, the usage context is clear and no other details seem necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema has no properties, so there is nothing to explain. The baseline for zero parameters is 4, and the description correctly avoids inventing parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Stop') and resource ('the running play session'), clearly distinguishing it from siblings like play_scene and get_play_state. It unambiguously states the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to end a play session, but it does not explicitly mention when to use it relative to alternatives or provide any exclusions. There's no guidance on scenarios like when no play session is running.
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?
Adds meaningful behavioral details beyond annotations: the operation is undoable, duplicates children recursively, and keeps the same parent. Annotations only indicate it is not read-only and not destructive, so this extra context is valuable for agent prediction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One efficient sentence with all key information: action, recursive behavior, parent placement, undoability, and optional name. No fluff, front-loaded with the core 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?
The description covers the essential behavior: same-parent duplication, children included, undoable, and optional naming. Minor gaps remain: no mention of default naming if 'name' is omitted, and no return value info, but these are not critical for a straightforward duplication operation.
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 schema description coverage, the description clarifies both parameters: 'name' is the optional copy name, and 'target' is the node to duplicate (implied by 'Duplicate a node'). While target format is not explicit, the meaning is clear enough for a two-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Duplicate') and resource ('a node (with its children) under the same parent'). It clearly distinguishes from sibling tools like create_node (new node), move_node, and reparent_node by specifying same-parent duplication and child inheritance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: use this tool when you need to copy an existing node and its subtree in the same location. However, it does not explicitly mention alternatives or when not to use it, leaving the agent to infer from sibling names.
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 claims read-only behavior but also discloses that clear=true empties the buffer after reading. This is a side effect that contradicts the readOnlyHint annotation. Although the description is transparent about the side effect, the annotation is misleading, and the inconsistency warrants a low score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-organized: a lead sentence states the tool's core function, followed by the primary use case, then a compact parameter reference. Every sentence adds value, and the structure makes it easy to scan. 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 four parameters, no output schema, and the need to differentiate from a sibling tool, the description is complete. It covers real-time behavior, content types, defaults, clear side effect, and alternative tool. The agent has all necessary information to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description thoroughly explains all four parameters beyond the schema. It defines legal values for level (error, warning, all), default for limit (100), filter as substring, and clear's side effect. This compensates for the low schema coverage (25%) and adds meaning to each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads the running game's captured output from the runtime channel, specifying the types of output (errors with stack traces, push_error/push_warning, print). It explicitly distinguishes itself from logs_read (file-based), 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 tells when to use this tool: for real-time runtime output that logs_read can't reliably cover, framing it as the 'play->see-error->fix signal'. It also names the alternative (logs_read) and describes parameter usage for level, limit, filter, and clear, which guides selection and invocation.
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, and the description aligns with this by saying 'Read'. The description adds the detail about property path syntax but does not disclose additional behavioral traits such as return format or error behavior. With annotations present, this is acceptable but not outstanding.
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 communicates the core purpose and the key parameter usage without wasted words. It front-loads the primary 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?
Given the tool's simplicity (2 params, no output schema), the description provides sufficient information for basic usage: what the tool reads and how to pass the property path. It could be enhanced by describing the return value, but the read operation's intent is clear enough for this context.
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 0%, so the description is the only source of parameter meaning. It clarifies that 'setting' is the property path and 'name' is an accepted alias, which meaningfully compensates for the schema's lack of descriptions. However, it does not enumerate all possible values or explain why both fields exist beyond the alias statement.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Read a ProjectSettings value by its property path'. It specifies the resource (ProjectSettings) and the operation (read), and distinguishes it from the sibling 'set_project_setting' by using 'Read'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context on how to use the tool, including the property path format and that 'setting' is the primary parameter with 'name' as an accepted alias. It does not explicitly mention when not to use it or point to alternatives, but the read/write distinction from siblings is implicit in 'Read'.
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, establishing this as a safe read operation. The description adds behavioral context by detailing the output structure ('target node + method'), going beyond what annotations provide. It does not mention any side effects, which is consistent with the read-only hint.
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 conveys the core purpose and output details without unnecessary words. It is well-structured and immediately understandable.
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 parameter and no output schema, the description is mostly complete: it states what is listed (signals) and the output structure (connections with target node and method). Minor ambiguity remains about whether all signals are returned or only ones with connections, but overall it is sufficient 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?
With 0% schema description coverage, the description must compensate for the parameter 'target'. It implies that 'target' refers to the node whose signals are listed, but it does not specify the expected format (e.g., node path, name) or provide explicit parameter guidance. This partial compensation is not fully sufficient for a parameter with no schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('a node's signals and their current connections'), clearly distinguishing this tool from siblings like connect_signal, disconnect_signal, and call_method. It precisely states what the tool does without 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 implies usage context ('List a node's signals') without explicitly stating alternatives or exclusions. The purpose is clear enough to know when to use it, but no direct comparison to sibling inspection tools is provided, so it doesn't fully meet the 'alternatives' criterion.
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 the behavioral detail that it makes the scene the edited scene, which goes beyond the annotations. However, it does not mention potential side effects like handling unsaved changes, which is a mild gap for an operation that changes editor state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the action, the parameter format, and the outcome in a concise manner. Every word contributes, with no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one parameter, no output schema, simple action), the description covers the essential aspects: what it does, how the path is specified, and the result. It could mention error behavior, but for a straightforward editor command, this is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only provides the parameter name 'path' with a string type and no description (0% coverage). The description compensates by specifying the format as a res:// path, which adds meaningful semantics beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Open') and resource ('scene'), and explicitly identifies the res:// path format and the editor context. The parenthetical clarifies that it sets the edited scene, distinguishing it from sibling tools like instance_scene or play_scene.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies usage for editing a scene in the editor, distinguishing it from playing or instancing. It provides context that this tool is for making a scene the current edited one, though it does not explicitly state when not to use it or name 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 readOnlyHint=false and destructiveHint=false, so the agent knows this is a mutating but non-destructive operation. The description adds the save-as context but doesn't disclose further behaviors like overwrite behavior or error conditions, which is acceptable given the simple nature of the 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 short sentences deliver both the primary function and the parameter usage with zero redundancy. The description is perfectly sized for the tool's simplicity.
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 one optional parameter and no output schema, the description explains what the tool does and how to use the parameter. It doesn't describe return values or edge cases, but these are not essential for such a simple operation, making the description complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate, and it does by explaining that 'path' is the res:// destination for save-as. This gives the parameter meaningful context beyond just a type, though it doesn't explicitly state that the parameter is optional.
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 'Save' with the resource 'the scene currently open in the editor', clearly distinguishing it from sibling tools like open_scene, play_scene, and instance_scene. It also explicitly mentions the save-as behavior, which differentiates it from a plain save.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly states when to use the optional 'path' parameter for save-as, implying that omitting it performs a regular save to the current scene path. It doesn't explicitly name alternatives or exclusions, but the context is clear and sufficient for basic usage.
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 declare readOnlyHint=false and destructiveHint=true, so the agent already knows this is a mutating operation. The description adds valuable context by noting the operation is 'undoable' and detailing value coercion for vectors. This goes beyond the annotations and helps anticipate 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 two sentences with no filler. The first sentence states the purpose immediately, and the second provides essential coercion detail. Every word earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with three required parameters and no output schema, the description covers the core aspects: what it does, undoability, and value coercion. It lacks explicit return-value information, but with no output schema that is acceptable. It is sufficient for an agent to select and invoke the tool correctly, though 'resolved object' could be more explicitly defined.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only describes 'value' as any JSON value, leaving target and property undocumented. The description partially compensates by explaining that the target is a resolved object and providing coercion rules for values. However, it does not clarify the expected format of the property parameter, leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set' and the resource 'property on a resolved object', which identifies a specific operation. It distinguishes from sibling tools like set_project_setting or set_resource by focusing on object properties. The phrase 'resolved object' is specific enough for the Godot 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 context is clear: use this tool when you need to set a property on a resolved object. It doesn't explicitly name alternatives or exclusions, but the mention of 'resolved object' and value coercion implies the intended use case. This is strong implied guidance, though not as explicit as naming 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?
Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description adds the behavioral note that the operation is 'undoable' and clarifies that it can either load an existing resource or mint a new inline sub-resource. This provides useful context beyond the structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose, followed by parameter guidance and examples in just two sentences. Every sentence earns its place, with 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?
Given no output schema, the description covers key aspects: the two distinct modes, examples, and the undoability. It is complete enough for an agent to select and invoke the tool correctly, though it could be slightly more explicit about mutual exclusivity or required parameter formats.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description compensates for the 50% schema coverage by explaining the relationship between 'resource' and 'class' (OR) and providing concrete examples. It implicitly clarifies that 'target' is a node and 'property' is a property name, though not explicitly, which adds value 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 'Assign a resource to a node's property' with specific verb and resource, and differentiates from siblings like set_property and create_resource by focusing on resource assignment. The examples further clarify the intended use.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context via examples (e.g., setting Sprite2D.texture or RectangleShape2D) and explains the two parameter modes, but it does not explicitly state when to use this tool over alternatives or list exclusions. Usage is implied rather than explicitly contrasted with 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 provide readOnlyHint=true and destructiveHint=false, and the description is consistent with a read-only operation. The description does not add extra behavioral context such as return format or error handling, but given the tool's simplicity, the annotations are sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of seven words, with no redundant information. It is front-loaded and concise, earning full marks for structure.
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?
This is a very simple tool with no parameters, no output schema, and annotations covering its safety. The description fully specifies the tool's function, leaving no gaps in understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the baseline for 0 params is 4. There is no parameter information needed, and the description does not need to compensate for any schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the action 'Return' and the resource 'running Godot engine version info', clearly distinguishing it from sibling tools like get_scene_tree or get_performance_monitors. It is a precise, unambiguous statement of 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates when to use this tool (when you need version information) and given its simplicity, no exclusions or alternatives are necessary. The context is clear enough for an agent to select this tool appropriately.
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?
Annotations already mark the tool as read-only and non-destructive. The description goes far beyond that, detailing the internal checks (visibility chain, world AABB, frustum test, distance vs far plane, layers vs cull_mask, per-surface material and cull mode) and even the winding-order nuance. It also explains the return value structure ('warnings' list or a verdict). This rich behavioral disclosure is exactly what an agent needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but front-loaded with a clear summary sentence. Every sentence adds technical detail that is useful for a diagnostic tool. It is not terse, but the density is justified for the complexity. It could be tightened slightly, but it is well-structured with a logical flow from purpose to use case to outputs.
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 fully covers the return value shape. It also explains the exact failure scenario, lists the diagnostic stages, and provides a usage directive. For a tool with 5 parameters and no output schema, the description carries the full burden and succeeds in making the tool's behavior, inputs (via context), and output comprehensible.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20% (only 'path' has a description). The tool description does not compensate by explaining how to identify the target node via nth, name, class, or under. Since the description never mentions parameters, the agent gets little help in selecting the correct node argument beyond the schema's single path field.
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 'Ask WHY a 3D node is or is not on screen, as data instead of pixels,' which is a specific verb+resource combination. It clearly distinguishes the tool from visual debugging tools like screenshot or ui_snapshot, and none of the sibling tools appear to offer the same visibility-chain diagnostic.
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 explicit when-to-use guidance: 'USE THIS BEFORE tuning lighting, fog, exposure or palette on anything you cannot clearly see.' It also defines the exact scenario the tool addresses (node exists, visible is true, log is clean, still see nothing). It lacks an explicit 'when not to use' statement or named alternative, but the directive is strong and actionable.
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 goes well beyond the annotations (destructiveHint: true) by detailing argument coercion rules, error behavior ('Wrong types or counts return an ERROR (never a silent no-op)'), and return format ('Returns the result as JSON'). This gives the agent a clear picture of how the tool behaves, which is particularly valuable for a generic method invocation 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 efficiently structured: one sentence for the core purpose, one for argument formatting, one for error handling, and one for the return value. Every sentence adds concrete information, and there is no redundant or filler content. It is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 and lack of output schema and parameter descriptions, the description provides a strong foundation: it covers inputs, coercion, error handling, and output. However, it does not fully specify the format for 'target' and 'method' parameters, nor does it mention when the destructive hint might apply in practice. Slight gaps remain, but the description is substantially 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?
With 0% schema description coverage, the description carries the full burden for parameters, and it does so well for 'args' by explaining accepted formats for vectors, colors, and object params. However, 'target' and 'method' are only implicitly described as 'resolved object' and the method name, leaving some ambiguity about their exact format (e.g., whether target is a node path or resource path).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Invoke a method on a resolved object.' This is a specific verb+resource combination that distinguishes it from sibling tools like set_property or runtime_get_property, which handle property access rather than method calls. The scope is well-defined with additional details about argument coercion.
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 on what the tool does, but does not explicitly state when to use it over alternatives or provide exclusions. It implies usage for calling methods on objects, but does not mention scenarios like setting properties or other sibling operations, leaving the decision to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description need not repeat safety. It adds the context of a 'static scan' and enumerates the exact data collected, which helps the agent predict behavior without contradicting 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 that front-loads 'Project overview' and lists the metrics compactly. No fluff or irrelevant details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool without an output schema, the description conveys the breadth of return data. It could be slightly more explicit about the output format (e.g., a structured object), but the listed items make the return value largely predictable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds no parameter-specific semantics, but none are needed since the schema already covers everything (empty properties).
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 provides a project overview with specific metrics (file/script/scene/resource counts, GDScript lines, autoloads, main scene, input-action count, Godot version). It distinguishes itself from sibling tools like get_godot_version by offering a broader 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 phrase 'Project overview' implies a clear use case for a high-level summary, and 'Read-only static scan' indicates safe, non-interactive usage. However, it does not explicitly name alternatives or exclusion criteria, 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds valuable context about the file logging dependency (off by default) and notes that the result will indicate how to enable it, which 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?
The description is concise, with two sentences: the first states purpose and fallback guidance, the second lists parameters. It is front-loaded and every sentence earns its place, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and absence of output schema, the description covers its purpose, fallback context, and the key dependency. It could elaborate on the return format, but the mention that 'the result tells you how' partially compensates, making it reasonably 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 each parameter. The description merely re-lists the parameters with shorthand and mentions the default for 'lines', but does not add significant new semantic meaning 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 the tool 'Tail[s] Godot's log FILE' with a specific verb and resource, and explicitly distinguishes it from the sibling tool 'game_logs' by positioning it as a fallback for runtime logs. This provides strong differentiation.
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 compares with 'game_logs' and advises preferring it for real-time runtime logs, while positioning this tool as a fallback. It also mentions the prerequisite of file logging being enabled, offering clear guidance on 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 non-destructive behavior. The description adds meaningful behavioral details: selectors resolve fresh each call, no need to re-fetch volatile @Node@NN paths, and the resolved path is returned. 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 focused sentences, front-loaded with the core purpose and containing essential addressing details without fluff. Every sentence earns its place, and the structure aids quick comprehension.
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 read-only tool with good annotations and no output schema, the description covers addressing modes, live-resolution behavior, and return value (value + resolved path). It lacks error-handling details but is sufficiently complete for most use cases.
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 0% schema coverage, the description compensates by explaining most parameters: path, class, name, text, nth, and property. It clarifies selector syntax and the default of nth=0. However, it omits any explanation of the 'under' parameter, which remains ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it reads a property of a node in the running game, with specific addressing methods (path or live selector). Distinguishes from sibling tools like set_property (write) and call_method by framing it as a read operation on runtime nodes.
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?
Specifies the running-game context and describes when to use path vs selector addressing, emphasizing that selectors resolve fresh each call. Does not explicitly name alternatives or exclusions, but the context is clear enough for the agent to select this over static/project tools.
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 annotations (readOnlyHint=true), the description discloses critical behavioral traits: it blocks the main thread, has a hard time limit to avoid stalling the editor's pipeline, and returns a retry signal. This is exactly the kind of context needed for an agent to invoke it safely.
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 dense sentences convey purpose, behavior, retry guidance, and allowed values without redundancy. The most important information ('Wait for a condition') is front-loaded, 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?
The tool is simple, with annotations and no output schema. The description covers condition types, blocking semantics, and retry behavior. The only notable omission is the meaning of `timeout_ms`, 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?
The schema has 0% description coverage, so the description must compensate. It fully explains the `condition` parameter with allowed values, but never explains `timeout_ms` or how it relates to the stated ~1.5s limit. Partial compensation earns a 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: 'Wait for a condition,' and enumerates the exact valid condition values. This unambiguously distinguishes it from siblings like wait_for_node, which presumably waits for a node, and get_play_state, which polls state without blocking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit invocation context: it blocks up to ~1.5s and returns 'not yet' if the condition isn't met, instructing the agent to call again. It doesn't explicitly name alternatives, but the condition choices and behavior make intended usage clear relative to sibling tools.
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?
Annotations already state readOnlyHint=true and destructiveHint=false. The description adds valuable context beyond that, including the effort dial ceiling, the silent trimming via a committed project.godot line, per-client config freshness, and runtime-bridge liveness. This is rich behavioral disclosure that helps the agent understand what the tool checks and potential gotchas.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph, but every clause contributes meaningful information—purpose, report categories, and usage timing. It is slightly long but not wasteful. The structure front-loads the purpose and ends with actionable guidance.
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?
There is no output schema, so the description carries the burden of explaining the return value. It enumerates the report contents extensively (edition, effort dial vs ceiling, tool counts, dock-disabled, server/port/auth, config freshness, bridge liveness). However, it does not specify the exact output format or data types, which would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema is trivially fully covered. Baseline 4 applies; the description does not need to explain parameter semantics because there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'Beckett self-diagnosis' with the specific goal of answering 'why can't the agent see or do X?'. It is distinct from sibling diagnostic tools like get_scene_tree or game_logs by aggregating multiple diagnostic dimensions into one call.
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 'Run this FIRST when tools seem missing, counts look wrong, or calls fail unexpectedly.' This gives strong when-to-use guidance, but it does not mention alternatives or when not to use, 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 declare readOnlyHint=true and destructiveHint=false, so no contradiction. The description adds value beyond annotations by clarifying the exact scope (engine classes AND project's own types, including GDScript class_name and C# [GlobalClass]) and explaining the 'base' parameter's behavior. This is useful behavioral context not present in structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action, then scope and parameter detail, ending with a usage pointer. Every sentence 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.
Completeness5/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 3 optional parameters and no output schema, the description covers the core behavior, scope, and even the recommended next step (describe_class). It's sufficient 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for all three parameters, so baseline 3 applies. The description adds semantic value by giving a concrete example for 'base' (base=Node2D) and explaining that the search covers both engine and user-defined types, which clarifies the meaning of 'query' 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 states a specific verb and resource: "Search classes by name substring". It clearly distinguishes from siblings by noting it covers engine classes AND project types, and positions itself as "The discovery entry point", setting it apart from tools like describe_class or find_nodes.
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 explicit usage context: "The discovery entry point — pair with describe_class." This tells the agent when to use this tool and what to follow it with. It doesn't explicitly list alternatives to avoid, but the pairing guidance is clear enough for a search 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 destructiveHint=false, covering safety. The description adds behavioral context beyond annotations: results are invokable via call_method, and the optional class restriction includes inherited members. This extra information is valuable and does not contradict 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 short sentences, front-loaded with the verb and resource, and contains no filler. Every phrase adds value, making it highly concise and well-structured for quick comprehension.
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 (3 params, no output schema, annotations covering safety), the description sufficiently covers purpose, key parameters, and a workflow hint. It explains the optional class restriction and the invokability of results, making the tool's behavior clear enough for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description partially compensates by explaining 'query' as a name substring and 'class' as an optional restriction including inherited. 'max' is not described, but its purpose is intuitive from its name and common usage. The description adds meaning for the two core parameters, though not exhaustive.
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: 'Search methods by name substring' and notes an optional class restriction. It distinguishes itself from sibling tools like find_classes (which searches classes) and call_method (which invokes methods) by focusing on method name search.
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 implicitly indicates usage: find methods by name to later call them, reinforced by 'Any result is invokable via call_method.' While it doesn't explicitly contrast with alternatives, it provides a clear workflow context. No exclusion criteria are given, but the primary use case is evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint true and destructiveHint false, so the safety profile is known. The description adds value by specifying exactly what state is reported (scene playing, channel connected), which is useful behavioral context 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?
A single, front-loaded sentence that communicates the tool's purpose with no wasted words. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no output schema, the description adequately explains the return value's semantics. It tells the agent what information will be reported, making the tool complete for its low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the baseline is 4 per the rubric. The description correctly focuses on output meaning since no parameters exist to explain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Report' and clearly identifies two distinct pieces of information: scene playing state and runtime channel connection state. This precisely distinguishes it from sibling tools like get_scene_tree or play_scene.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a clear use case: when an agent needs to know if a scene is playing or if the runtime channel is connected. It does not explicitly state exclusions or alternatives, but the context is clear enough for straightforward 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 declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral detail about the return content (name/class/script, nested), which goes beyond the annotations and helps set expectations for the response.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that uses a specific verb and resource. Every word adds value, and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, parameterless, read-only tool, the description adequately explains what the tool does and what the output contains (name/class/script, nested). No output schema is present, so the description carries the responsibility for return-value context, and it does so clearly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the baseline is 4. The description clarifies that the tool operates on the currently open scene, which is an implicit context parameter, but since there are no explicit parameters, the schema and description together are fully sufficient.
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 ('Return'), the target resource ('node tree'), and the specific context ('scene currently open in the editor'). It distinguishes from the sibling tool get_remote_tree by specifying 'in the editor', which is a unique qualifier.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: when needing the node tree of the currently open editor scene. It does not explicitly mention alternatives or exclusions, but the 'in the editor' phrasing implicitly separates it from remote/runtime tools like get_remote_tree, so the usage is clear enough.
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, which the description does not contradict. The description adds valuable behavioral context: class matches both native and custom scripts (with the @Node@NN pitfall), name is substring-based, and path/recursive/max have defaults. It could have more explicitly stated the return format, but it does say 'returns their paths'.
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 purpose. The first sentence states the action and result, the second covers the class/name matching nuances, and the third lists parameter defaults. No filler words; 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?
For a read-only search tool with 5 parameters and no output schema, the description is complete. It explains all parameters, gives defaults, highlights a common pitfall (custom class_name nodes), and states the output's intended use with runtime_* tools. The agent has enough context to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must fully explain parameters. It does: 'class' matches native and custom classes, 'name' is a substring, 'path' is the scope root, 'recursive' is boolean, and 'max' caps results with default 100. Every parameter is given meaningful semantics beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Find' with a clear resource: 'LIVE nodes in the RUNNING game'. It states the search criteria (by type and/or name) and the output (paths to feed into runtime_call/runtime_get_property/runtime_set_property). This clearly distinguishes it from static tree tools like get_scene_tree or get_remote_tree.
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 runtime usage by emphasizing 'LIVE nodes' and 'RUNNING game', and it names runtime_* tools as consumers. It also provides a critical usage nuance about custom class_name scripts, warning that is_class alone misses them. However, it does not explicitly mention alternative tools or when not to use this tool, so a 4 is warranted.
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 substantially exceeds the annotations. Annotations only say readOnlyHint=false, openWorldHint=false, destructiveHint=false, but the description discloses critical behavioral traits: ordered execution, halt on first failure, rollback of scene edits only (not file/resource writes), and the meaning of 'ok' per step. It also warns about verifying effects, which is a key non-obvious behavior. 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 compact yet information-dense. It front-loads the core purpose, then details failure/rollback behavior, then gives a concrete use case, and finally adds a crucial verification warning. Every sentence serves a distinct function with no fluff or repetition of obvious schema details.
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 no output schema, the description explains that 'ok per step' only means handler completion and not necessarily success, and instructs to verify with read-back steps. It covers failure semantics, rollback limits, and usage context. For a batch execution tool with this complexity, the description is complete enough for an agent to use it safely and effectively.
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 already covers all parameters (100% coverage). The description adds meaningful nuance beyond the schema, particularly for the 'rollback' parameter: it clarifies that rollback undoes scene edits but not file/resource writes, and it explains the format of 'steps' with an actual example. This goes beyond the schema's default-value notes, earning a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear, specific verb and resource: "Run several tool calls in one request, in order." It immediately distinguishes from siblings (which are individual operations) by framing this as a meta-tool for batching. The purpose is unmistakable and non-tautological.
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 concrete use case: "Use to collapse multi-step authoring (create node → set props → attach script) into one atomic call." It also advises verifications with read-back steps, implying when to use. However, it does not mention when not to use it (e.g., for a single simple call) or name specific alternative tools, so it falls short of full explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only state readOnlyHint=false and destructiveHint=false. The description fills in important behavioral details: it waits for play_started, uses logs_read for errors, retries on_ready writes, and reports failures rather than silently dropping. It doesn't explicitly warn about interrupting an existing play session, but this is minor given the context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than average but each sentence earns its place: scene selection, wait/error behavior, on_ready purpose and persistence, retry/reporting. It is dense but not redundant, and front-loads the core action in the first sentence.
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?
No output schema is present, so the description must explain return/result behavior. It does so by noting the wait_until condition, error logging, and how on_ready write successes/failures are reported. It also covers the 'why' (restore state across restarts) making it self-sufficient for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers scene and on_ready with descriptions, but current has none. The description explains current=true means open scene and omitting scene runs main/current. It also clarifies on_ready structure (path may be name/class selector, same as runtime_set_property) and the retry semantics, adding meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Play a scene in the editor.' It specifies three modes (specific scene, current scene, main scene) and distinguishes the tool from sibling tools like stop_scene and get_play_state by focusing on starting playback.
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 usage context by explaining how on_ready differs from batch_execute, noting the restart boundary that batch_execute cannot cross. This tells the agent when to prefer this tool or its on_ready feature over alternatives. Also explains scene selection rules (omit for main/current, current=true for open scene).
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 destructiveHint annotation, it discloses that GDScript is validated by default and refuses non-compiling code, non-.gd files are written as-is, and validate=false forces writing. These are concrete behavioral traits not inferable from 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?
Three sentences, front-loaded with the main purpose, then relevant caveats and an alternative. Every sentence adds value with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter write tool with annotations and no output schema, this description covers purpose, validation semantics, file-type handling, and an alternative tool. The destructiveHint annotation covers overwrite behavior, leaving no major gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description supplements the schema by explaining the effect of validate (default true, refusal of invalid GDScript) and the distinction between .gd and other file types. Path is documented with an example, and content is self-evident, so coverage is adequate.
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 'Write a GDScript (or other text, e.g. .cs) file under res://', clearly stating the action, target, and scope. It differentiates from siblings like write_file (generic) and attach_script (node attachment).
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 explicitly names build_csharp as the alternative for compile-checking C#, and explains when to set validate=false. It provides context but doesn't explicitly contrast with write_file or attach_script, though the scope 'under res://' helps.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the tool is known to be safe. The description adds meaningful behavioral context: it resolves live nodes during gameplay, reports the scope in the answer, and clarifies that edited-scene and running-game paths share syntax but differ in meaning. This goes well beyond the annotation baseline.
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, but every clause adds value: the first states the core action, the second explains target variants, live resolution, the runtime_get_property relationship, and the scope-reporting behavior. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read-only tool with no output schema, this description is complete: it explains the input format, the resolution logic, the fallback, and the return behavior (JSON properties with scope indication). It gives the agent all necessary information 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.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides only a bare 'target' string with 0% description coverage, so the description carries full responsibility. It thoroughly explains what target can be: a res:// path, a node name/path in the open scene, or a class name with fallback to describe_class. It also explains live-node resolution, fully compensating for the schema's lack of detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Dump a live object's properties as JSON.' It clearly distinguishes itself from sibling tools by defining the target resolution scope (res:// path, node path, class name fallback) and explicitly connecting to runtime_get_property for live-node resolution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool by enumerating accepted target types and noting fallback behavior to describe_class. However, it does not explicitly state when NOT to use this tool or name a preferred alternative for getting class definitions or single properties, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes far beyond the readOnlyHint annotation by disclosing that counters are measured, never estimates, that duration_s polls while the game keeps running, that series=true is token-heavy, and that editor-target sampling is refused because it would stall the editor. These are valuable behavioral traits not present in 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 moderately long but every sentence contributes unique information. It is front-loaded with the core purpose, uses clear formatting (e.g., SAMPLES OVER TIME, stats list), and includes a concrete example (fps.p95) without redundancy. The length is justified by the tool's complexity.
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 four parameters, no output schema, and only read-only annotations, the description is fully complete: it explains return stats ({min,avg,p95,max}), target modes, sampling mechanics, limits, optional raw series, and the editor refusal edge case. An agent can confidently invoke this tool in various scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema descriptions cover all four parameters, the description enriches them significantly: it explains target default behavior (game when a play session is connected), that duration_s is game-only with max 30, the default and minimum interval, and that series=true returns raw samples with token-heavy implications. This adds meaning well 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 opens with 'Profiling: read Performance monitors' followed by an explicit list of metrics (fps, frame time, memory, object/node counts, draw calls, video mem, physics), giving a specific verb and resource. It clearly distinguishes itself from siblings like get_project_statistics and monitor_properties by focusing on engine counters and sampling behavior.
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 states when to use the tool (profiling, game vs editor target) and explicitly describes when not to use it: editor-target over-time sampling is refused because it would block the editor loop. It does not name alternative sibling tools, so it lacks an explicit 'use X instead' comparison, but the context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations already mark it read-only and non-destructive, the description adds valuable behavior beyond that: token-limit risks, default limits for max_nodes and max_children, collapse behavior with an example, and the returned fields including truncated. This gives the agent a realistic expectation of cost and output.
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 dense but every sentence adds value: purpose, critical warning, parameter meanings, defaults, and return shape. The inline warning about token limits is concise and high-impact, and the use of '...' and '=...' makes the parameter list scannable.
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 5 parameters, no output schema, and no required parameters, the description fully covers behavior, defaults, return structure, and safe usage. It even warns about the counterpart tool relationship and token budget, making it complete for an AI agent to use safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema coverage, the description explains all five parameters: path (with accepted forms), depth (levels, -1=all), max_nodes (default 250), max_children (default 50), and collapse (grouping behavior with example). This fully compensates for the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific action ('Dump') and resource ('live scene tree of the RUNNING game') and explicitly names it as the runtime counterpart of get_scene_tree, clearly distinguishing it from that sibling. The scope and intent are immediately obvious.
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 states this is for the RUNNING game and contrasts it with get_scene_tree, providing strong contextual guidance. It doesn't explicitly say 'use get_scene_tree for the editor tree' but the 'runtime counterpart' phrasing makes the recommended usage clear.
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?
Despite annotations declaring readOnlyHint=true and destructiveHint=false, the description adds substantial behavioral detail beyond them: token-cost dials (scale/format/quality), cropping behavior (clamped), and the annotate feature that returns a structured marks legend. It also warns about PNG-only for editor target, which is not in annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-structured, front-loading the core purpose and then using semicolons and clauses to group related details. It is longer than two sentences, yet every clause earns its place by explaining token costs, target differences, and the annotate workflow, making it efficient for a tool with 8 parameters.
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?
With no output schema, the description covers the return behavior: images are inline, and annotate also returns a marks legend. It addresses all eight parameters either in prose or via the schema, and clarifies key edge cases like clamping and PNG-only for editor. Enough detail for an agent to know when and how to 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%, so the baseline is 3, but the description enriches several parameters: scale=0.5 quarters the pixels, jpeg/webp compress far below PNG, region is clamped, and annotate returns a structured legend. It does not mention max_marks in prose, but the schema already documents it, so the added value is enough to push to 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Capture an image the agent can see,' which is a specific verb+resource statement. It clearly distinguishes between game and editor targets and separates itself from sibling tools like ui_snapshot by positioning itself for visual inspection rather than functional state.
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 names an alternative: 'For pure functional state, ui_snapshot is cheaper than any image.' It also provides guidance on when to use annotate=ui for both visual and interactive state, and differentiates game vs editor targets with concrete channel semantics (runtime vs viewport).
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?
Annotations already mark this as read-only and non-destructive. The description goes well beyond that by revealing behavioral details: it walks the whole SceneTree root including autoload HUD layers and popups, computes occluded_by via hit-testing, and offers a hash-based unchanged optimization. It also mentions the introspection state pixels can't tell (disabled, focused, checked, etc.), giving deep context about what to expect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a dense single paragraph with every clause contributing useful information; there is no filler or redundancy. It is longer than a simple tool would warrant, but this tool is genuinely complex. A bulleted structure would improve scannability, but the current paragraph is tightly packed and appropriately sized for the complexity.
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?
With no output schema, the description thoroughly explains the return payload: per-control structure (path, class, text, rect, state flags, honesty flags), top-level information (focus owner, popups, viewport, hash), and the unchanged-UI shortcut. It also covers edge cases like occlusion and scoping, making it sufficiently complete for an agent to understand what it will receive.
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%, but the description adds meaningful usage semantics like 'path= to scope', 'interactive_only=true to slim', and 'since_hash' to detect unchanged UI. However, there is an inconsistency: the description says max_nodes defaults to 400, while the schema says default is 150. This slight factual mismatch prevents a perfect score.
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+resource: 'One-call UI snapshot of the RUNNING game' and enumerates exactly what is captured (visible Controls, state flags, occlusion). It explicitly differentiates from alternatives by stating it replaces the screenshot + find_ui_elements + get_control_rect + runtime_get_property round-trips for functional checks.
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: 'For functional UI checks this replaces... keep screenshot for VISUAL/render bugs.' It also explains scoping options (path=, interactive_only=true, max_nodes) and the since_hash mechanism for unchanged UI, establishing clear usage context and exclusions.
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 important context beyond annotations: isolated build, no effect on editor assembly, requires .NET SDK (already installed), first build restores packages. No contradiction with readOnlyHint=true.
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?
Concise yet comprehensive: purpose, safety, auto-detection, prerequisites, performance, and usage hint all in a few sentences. No unnecessary 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 tool's simplicity (2 optional params, no output schema), the description covers return format, safety, performance, and relative usage to sibling tools, making it fully actionable.
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 covers both parameters fully. Description adds value by noting auto-detection of .csproj and default configuration, but schema already provides 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 it performs a compile-check using dotnet build for C# Godot projects, returning structured diagnostics. It distinguishes itself from write_script which does not cover C#.
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 'Use after editing .cs' and notes that the GDScript compile-gate (write_script) does NOT cover C#, providing clear when-to-use and when-not-to-use guidance.
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=true, destructiveHint=false), the description clarifies that the tool performs no write, explains the validation behavior for class_name, and notes a version-specific fix. This adds substantial context about what the tool does and does not do, with no contradiction to annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the most important information and each sentence adds value. The version-specific note about v1.9 is somewhat detailed, but it prevents a known misunderstanding, so it earns its place despite making the text slightly longer than strictly necessary.
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 validator with no output schema, the description sufficiently explains the return value ('Returns whether it compiles'), all parameter combinations, and the key edge case of class_name duplicates. It is complete enough for an agent to invoke correctly without requiring additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only describes 'path' (50% coverage), leaving 'content' undocumented. The description compensates by explaining that 'content' holds source and 'path' is a res:// path, can be used alone or with content, and that passing both enables cross-file duplicate detection. This adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb-resource pair ('Parse/compile GDScript') and emphasizes 'WITHOUT writing it', which clearly distinguishes it from write_script and other siblings. It also mentions the two input modes (content or path) and the return value, making the tool's purpose 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent to use this tool before write_script to catch hallucinated APIs, providing a clear alternative and usage context. It also gives concrete guidance on when to pass 'path' in addition to 'content' for existing files, covering an important edge case.
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?
Annotations mark this as destructive, and the description correctly aligns by describing an edit operation. It goes beyond annotations by disclosing atomicity ('Atomic + safe') and the guarantee that 'nothing is written if any anchor is missing/ambiguous or (for .gd) the result fails to compile', which is valuable for an agent assessing 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 three sentences: purpose, data format, and safety/usage guidance. Each sentence is information-dense with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with complex nested edit items, the description covers the input format, constraints, failure behavior, and guidance for alternative tools. It does not explain return values, but no output schema exists and the behavior (success/failure) is implied by the atomic guarantee.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides brief descriptions for path, edits, and validate, but the description adds crucial detail: the exact structure of edit items ({find, replace[, all]}, {append}, {prepend}), the 'find must match EXACTLY once unless all:true' constraint, and the compile-check behavior of validate (default true, .gd only). This substantially enriches the schema information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Surgically edit an existing res:// file without rewriting it whole', which specifies a clear verb (edit), resource (res:// file), and scope (existing file, targeted edits). It explicitly contrasts with write_script, distinguishing itself from a 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes 'Prefer this over write_script for small changes', directly telling the agent when to choose this tool over an alternative. It also implies that large rewrites should use write_script, and the atomicity warning gives context for safe usage.
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?
Although annotations are neutral, the description adds rich behavioral context by explaining what each debug mode visually reveals (e.g., 'unshaded = albedo only', 'wireframe = is the geometry even there'). It also shows the workflow of switching then screenshotting, making the tool's behavior transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every sentence serves a purpose: it front-loads the core action, defines each mode with practical implications, and ends with a clear recommendation. No redundant or filler content.
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 fully complete. It covers what the tool does, how to use it, what each mode means, and how it relates to the sibling tool render_probe. The user has everything needed to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Even though schema coverage is 100%, the description goes beyond listing enum values by explaining the diagnostic meaning of each mode (e.g., 'overdraw = transparency cost', 'normal_buffer = flipped or NaN normals'). This adds substantial value for correct parameter selection.
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: 'Switch the RUNNING game's viewport debug draw mode'. It specifies the resource (viewport debug draw) and distinguishes itself from sibling tools by noting that render_probe answers the same question in numbers.
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: 'Reach for this FIRST when the picture is wrong'. It also describes the diagnostic role of each mode and names the alternative (render_probe), offering clear context for choosing this tool over siblings.
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:

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

Score Badge

Copy to your README.md:

[![beckett-godot-mcp MCP server](https://glama.ai/mcp/servers/beckettlab/beckett-godot-mcp/badges/score.svg)](https://glama.ai/mcp/servers/beckettlab/beckett-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/beckettlab/beckett-godot-mcp'

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