Godot AI

Overview Schema Related Servers Score Discussions

Server Quality Checklist

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

Latest release: v3.1.5
Disambiguation5/5
Each tool covers a distinct Godot domain (node tree, API docs, input mapping, filesystem, autoload, runtime, testing, audio, tilemap) with no functional overlap. An agent can clearly distinguish between them.
Naming Consistency4/5
Most tools follow a consistent '<domain>_manage' pattern (node_manage, api_manage, etc.), with only 'test_run' deviating slightly. Within each tool, ops use a consistent verb_noun style (e.g., get_children, add_action).
Tool Count5/5
9 tools is well-scoped for a Godot editor assistant, covering core areas like node management, input, filesystem, testing, and audio without being overwhelming.
Completeness4/5
The tool set covers a broad range of Godot editor functionalities. Minor gaps exist (e.g., explicit scene creation/opening, resource editing), but the core workflows for project editing are well-supported.
Average 4.5/5 across 9 of 9 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 277 of 283 community issues answered or closed in the last 6 months
- 253 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.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. While 'save to disk' implies writing, it does not disclose whether the file is overwritten, what prerequisites exist (e.g., an active scene), or what failure modes might occur. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action and resource. There is zero filler or redundant information, making it an excellent example of concise writing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, with one optional parameter and an output schema that presumably covers return behavior. However, the description omits important behavioral context such as prerequisites (e.g., an open scene) and whether the operation overwrites the existing file. This is adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides a complete description for session_id, achieving 100% schema coverage. The tool description adds no parameter-level detail, but the schema handles it, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (save), the resource (currently edited scene), and the destination (to disk). While it does not explicitly differentiate from sibling tools like scene_manage, the verb and resource are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The purpose implies when to use this tool (persisting the current scene), but the description provides no explicit guidance on prerequisites, alternatives, or exclusions. For example, it does not mention that a scene must be open or how it differs from scene_manage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behaviors. It mentions that play and stop are editor preview playback and not undoable, but it does not address other behavioral aspects like destructive actions, permissions, or side effects of player_create or player_set_stream.
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 well-structured with a brief purpose line followed by bulleted operations. It is moderately concise; the canonical call shape explanation adds clarity but could be shortened. Overall, it communicates effectively without excessive verbosity.
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 (multiple ops with diverse parameters), the description covers all operations and their parameters. An output schema exists but is not elaborated; the description only mentions return value for player_set_stream. For most use cases, completeness is adequate.
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 only defines abstract parameters (op, params, session_id). The description adds detailed semantics for each op, including required parameters (e.g., parent_path for player_create), default values (name='AudioStreamPlayer'), and enums (type: '1d'|'2d'|'3d'). This fully compensates for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool manages audio via AudioStreamPlayer nodes, listing all operations (player_create, player_set_stream, etc.). It distinguishes from sibling tools like node_manage or api_manage by focusing exclusively on audio management.
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 does not explicitly state when to use this tool versus alternatives. Usage is implied by the tool's specific role, but no when-not-to-use guidance or comparison with siblings is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavior disclosure. It explicitly mentions overwrite behavior, filesystem scan triggering, and the sidecar listing in data.cleanup.rm. This is substantial, though it omits permission/session 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 three sentences, front-loaded with a clear purpose, and every sentence contributes behavior or side-effect information. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity and the presence of an output schema, the description is complete enough: it covers core functionality, overwrite semantics, and side effects. Minor gaps exist around session targeting and alternative tool guidance, but these are not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for all three parameters, including descriptions for path, content, and session_id. The description adds no parameter-specific detail beyond this, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a .gd file on disk, explicitly naming the resource type and the action. It also distinguishes from siblings like script_patch by focusing on creation rather than patching.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for creating new GDScript source files, but it does not explicitly state when to prefer this over alternatives like script_patch or script_manage. There are no clear exclusions or when-not-to-use notes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does disclose core behavior (creates, adds to parent, instantiates scene) and the mutual exclusivity rule. However, it omits potential side effects like modifying the scene file, needing to save, or error conditions. More transparency would be beneficial for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and contains no filler. It efficiently covers both modes of operation and the key interaction rule. A model of conciseness.
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 6-parameter tool with an output schema present, the description is reasonably complete. It explains the two modes and the parent relationship. It could mention error handling or save requirements, but the core behavior and parameter semantics are adequately covered, and the output schema handles return values.
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?
All six parameters are fully described in the schema (100% coverage), so the baseline is 3. The description adds valuable parameter semantics by explaining that type and scene_path are mutually exclusive and that scene_path takes precedence, which is not stated in the schema. This pushes the score 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 a specific verb+resource: 'Create (spawn) a new node in the scene tree.' It clearly distinguishes itself from sibling tools like node_find and node_set_property by focusing on creation, and further clarifies the two modes of operation (type vs. scene instantiation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: when you need to create a new node or instantiate a PackedScene. It also offers a usage caveat about type/scene_path mutual exclusivity. However, it does not explicitly name alternatives or state 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?
With no annotations, the description carries the full burden. It discloses that the return is a paginated flat list with specific fields (name, type, path, child count), that it walks to a specified depth, and that it operates on the active scene. This gives good behavioral insight, though it doesn't explicitly state read-only or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a resource form line, with the core purpose stated first. Every sentence 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema and fully documented parameters, the description covers the key behavioral aspects (pagination, depth, flat list, active scene). It doesn't mention error handling or explicit read-only safety, but those are less critical for a get-style tool with an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds context by explaining the result is a paginated flat list and that depth controls walk depth, but this largely restates what the schema already provides. It does not significantly extend parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get the scene tree hierarchy from the open scene' with a specific verb and resource, and clearly distinguishes from sibling tools like node_find by focusing on the full hierarchy rather than searching. The resource form adds further specificity.
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 says 'prefer for active-session reads', providing clear context on when to use the resource form. However, it does not explicitly name alternative tools or state when not to use it, so exclusions are missing.
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?
In the absence of annotations, the description appropriately discloses the key destructive behavior ('Replaces any existing script') and assures undoability. This goes beyond minimal and covers the most impactful side effects, though it omits details like permission requirements or session 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 concise sentences. It front-loads the primary action and immediately states the crucial caveat, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool, the description covers the core purpose, the replacement behavior, and undoability. An output schema exists, so return details are likely covered elsewhere. It might benefit from mentioning node existence validation, but overall it is sufficiently complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with detailed parameter descriptions and examples. The description does not add any extra parameter-level semantics beyond what the schema already provides, so it earns the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('attach') and identifies the resource ('script' to a 'node'), making the tool's purpose unmistakable. It clearly distinguishes from sibling tools like script_create or script_patch by focusing on the act of 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?
The context is clear: this tool is for attaching a script to a node. The phrase 'Replaces any existing script' hints that it can also be used to swap scripts. However, it does not explicitly mention alternatives or exclusion cases, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description covers behavioral details: default sections, pagination behavior (offset/limit per section), and that 'all' excludes inheritors. However, it does not explicitly state the tool is read-only or non-destructive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with purpose upfront, followed by operation details and call shape. Some redundancy (e.g., repeating default sections) but every sentence adds value. Slightly verbose but still efficient for the information density.
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 complexity (multiple operations, pagination, output schema exists), the description covers purpose, parameters, usage patterns, and pagination advice comprehensively. No significant gaps for a read-only documentation inspector.
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 thoroughly explains the op, params structure, sections argument details (defaults, 'all', comma-separated list), pagination parameters, and flat parameter compatibility. Adds significant meaning beyond the minimal 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?
Clearly states the tool inspects Godot API documentation-shaped metadata from ClassDB, with examples like 'what properties does X have' and specific operations. Distinguishes from sibling tools like node_manage that handle runtime objects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides detailed call examples and pagination advice, but does not explicitly state when to use this tool vs alternatives (e.g., node_manage for runtime node inspection). Usage context is implied through purpose but lacks direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It appropriately discloses that pagination is in effect and that filters are combined with AND, which are important semantics not present in the schema. It does not mention side effects or error conditions, but the read-only nature of 'Find' is reasonably implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using two short sentences to convey purpose and core constraints. It is front-loaded with the action and resource, and every sentence adds value.
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 moderate complexity and the presence of a detailed output schema, the description adequately covers the key usage constraints (required filter, AND semantics, pagination) and purpose. It is complete enough for an agent to select and invoke this tool correctly, especially with the rich input schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description does mention the three filter types (name, type, group) and pagination, but these are already fully documented in the input schema. It adds no extra nuance about parameter values 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 uses a specific verb 'Find' and identifies the resource 'nodes in the scene tree' with filters by name, type, or group. This clearly distinguishes it from siblings like scene_get_hierarchy, which lists the hierarchy, and node_get_properties, which inspects a specific node's properties.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states the requirement 'At least one filter must be provided' and explains that filters AND together, giving clear usage constraints. It also mentions pagination, implying use of limit/offset for large results. However, it does not name alternative tools or specify when not to use this tool, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a read-only operation through the verb 'list' and lists the exact metadata fields returned. It also discloses the server-global 'exclude_domains' behavior, adding context beyond a simple list call. It stops short of explicitly stating 'no side effects', but the listing semantics are clear.
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 organized with a short opening, a resource form note, a bulleted op section, and a protocol note. It is front-loaded with the core purpose. There is minor redundancy ('Session listing' vs. 'List every connected Godot editor'), but the overall structure is efficient and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (only a 'list' op) and the presence of an output schema, the description is largely complete. It details the response metadata and server-level 'exclude_domains' information, and it explains the calling convention. It could be more explicit about whether session_id is relevant for list(), but overall it covers what an agent needs to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is 0%, so the description must compensate. It explains the canonical call shape ('{"op": "<verb>", "params": {...}}') and clarifies that flat op parameters are accepted as an alias, while 'op' and 'session_id' remain top-level. This adds meaning beyond the raw schema by describing how parameters are structured and transmitted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 'Session listing' and then explicitly states 'List every connected Godot editor with metadata', giving a specific verb+resource. It clearly distinguishes this session listing tool from siblings like session_activate by focusing solely on the list operation, which the input schema enforces via the 'list' const.
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: to list all connected editors. It also offers an explicit usage preference: 'Resource form: godot://sessions — prefer for resource-aware clients.' While it doesn't explicitly discuss alternatives or exclusions, the context is clear and the single allowed operation makes usage unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses important traits: delete is undoable, play/stop are editor previews not saved with the scene, set_autoplay with empty name clears autoplay, validate returns broken_count and per-track issues, and target_paths are converted to relative track paths. It does not address error conditions or prerequisites such as session/active scene, but it is far more transparent than most.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Although long, the description is densely packed and organized by operation with a consistent one-line signature followed by brief explanations. It starts with a high-level summary and ends with the canonical call shape. Every line earns its place, and the bulleted layout makes scanning easy.
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 complexity (15 operations) and a generic input schema, the description is remarkably complete: it covers all operations, parameter details, target-path resolution, preset behaviors, and call-shape conventions. An output schema exists, so return-value documentation is not required. Minor details like overwrite semantics and error handling are not spelled out, but the description is sufficient to invoke all operations 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 description coverage is 0%, so the description is the only source of parameter semantics. It fully compensates by documenting every operation's parameters, including track_path format ('NodeName:property'), keyframe structures, interpolation enum values, tweens spec, and all preset arguments. This is essential for invoking the tool correctly and is done thoroughly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's scope with 'AnimationPlayer authoring' and then enumerates 15 specific operations from player_create to preset_pulse. It identifies the resource (AnimationPlayer clips/tracks) and differentiates from sibling animation_create by focusing on player-level manipulation rather than creation of animation resources, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: all operations are for AnimationPlayer authoring, and each op's signature implies when it should be used (e.g., create_simple for high-level multi-track builds, preset_fade for one-call fades). However, it does not explicitly state exclusions or compare against alternative tools like animation_create or node_set_property, 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?
No annotations exist, so description carries full burden. Thoroughly discloses behavioral traits: delete is undoable but cannot delete scene root, duplicate cannot duplicate root, rename has collision rules, reparent cannot move into descendants, scene_file guard behavior, and canonical call shape.
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?
Well-structured with sections (resource forms, ops, canonical call shape) and each sentence adds value. Slightly lengthy due to the number of operations, but appropriate for the complexity. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all important aspects: operations, parameters, return structures (for get_children), guard mechanisms. Missing explicit return formats for some ops, but output schema likely provides that. Good for a multipurpose tool.
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?
Input schema coverage is 0%, but description explicitly defines parameters for each operation (e.g., path, scene_file, new_name, index, new_parent, group). Adds meaning beyond schema by explaining parameter purposes and constraints like sibling-name collision rules for rename.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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's for node tree manipulation with a comprehensive list of operations (delete, duplicate, rename, reorder, reparent, groups, hierarchy reads). Differentiates from sibling tools (e.g., api_manage, input_map_manage) by focusing on node tree actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides implicit usage guidance by detailing each operation and the scene_file guard, but does not explicitly contrast with sibling tools or state when to use this tool vs alternatives. Includes preference for resource forms for active-session reads, which is helpful but not a clear when/when-not statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses that the tool only re-fetches the most recent payload, does not re-execute tests, and that verbose=True expands individual result details. This clearly signals a non-mutating inspection operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: purpose, resource form, operation list, and call shape are each clearly separated. Every sentence contributes operational value, and the purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema covers return structure, so the description does not need to detail responses. It adequately covers purpose, usage, and core parameter semantics for a one-op tool. The only noticeable omission is session_id semantics, but this is a minor gap given the overall 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?
The schema has 0% description coverage, so the description compensates by explaining the core parameters. It documents the canonical call shape, constrains op to results_get, and describes the verbose flag within params. However, session_id is only mentioned as top-level without explaining its meaning, leaving a small gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Test result inspection (re-fetches the most recent test_run payload)', using a specific verb and resource. It clearly distinguishes this from the sibling test_run by emphasizing 'no re-execution' and positioning it as a read-oriented tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It says 'prefer for active-session reads', giving clear context for when to use this tool. It also notes that it returns 'full results from the last run, no re-execution', implying it is the right choice when results are needed without rerunning tests. It does not explicitly list exclusions or alternatives, but the guidance is still useful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that operations target TileMapLayer nodes by scene-relative path, that write ops are undoable, and includes important remapping notes. It lacks details on error behavior or permissions, but the provided info is substantial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections, but somewhat verbose, especially the IMPORTANT note and canonical shape explanation. It could be trimmed without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all operations, their parameters, return values, and a key nuance (source-ID remapping). Given that an output schema exists, the return value details are appropriate. No apparent gaps.
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 add meaning. It explains each op's parameters (path, source_id, atlas_col, atlas_row, map_x, map_y, etc.) and their roles, plus the canonical call shape. This fully compensates for the sparse schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it's for TileMap/TileMapLayer authoring with specific operations (set tiles, fill rects, clear, read cells). It distinguishes from sibling tools like node_manage and filesystem_manage by its tilemap focus.
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 detailed context for each operation, including parameters and behavior. It also warns about source-ID remapping and canonical call shape. However, it does not explicitly state when to avoid this tool or when alternatives are preferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It explicitly states that the tool 'Writes / removes client config files' and details each op's effect, including the destructive nature of 'remove'. It also hints at error states via the 'error' status in status(). It does not mention permissions or backup behavior, but the core side effects are 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 well-structured with a concise intro, a bulleted Ops list, and a clear canonical call shape. Every sentence adds meaningful information, with no redundancy or filler. The use of code formatting and list structure makes it easy to scan.
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 moderate complexity, the description covers the essential behavior: supported clients, ops, call shape, and compatibility. An output schema exists, so the lack of return-value details is not a gap. The description is sufficient for an agent to correctly select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It effectively explains the 'op' enum via the Ops list, describes the 'params' object shape (including that 'client' is an id from status()), and clarifies the flat-parameters compatibility alias and top-level 'session_id'. This is strong parameter semantics despite no 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 states a specific verb ('Configure') and resource ('AI clients... Godot AI MCP server'), and enumerates supported clients. The 'Ops' section further clarifies the distinct actions (status, configure, remove), making it easily distinguishable from sibling tools like editor_manage or scene_manage.
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 that the tool is for managing client config files and provides usage context for each op (status, configure, remove). It does not explicitly name alternatives or exclusions, but the purpose is so specific that usage intent is unambiguous. The canonical call shape and compatibility alias are also helpful guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the disclosure burden. It reveals that all write ops are undoable via EditorUndoRedoManager, and that sibling CSG shapes auto-combine—useful behavioral context beyond the basic operation. It could mention error cases, but current disclosures are solid.
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 well-structured with a one-liner summary, a detailed explanatory paragraph, and clearly formatted op bullets. It is slightly longer than necessary but every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers operation semantics, parameter details, return values, undo behavior, grouping constraints, and property handling. Given the tool's two-OP scope, this is fully sufficient for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is generic (op/params/session_id) with 0% coverage of inner parameters. The description fully documents both ops: parameter names, defaults, enums, and return values, providing complete semantic 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 opens with 'CSG authoring' and clearly states it creates boolean shapes and sets their operations. It specifies resource types (box, sphere, cylinder, etc.) and differentiates from sibling tools like node_create by focusing on CSG-specific 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 explains the use case (carving holes/caves/tunnels in the editor) and gives guidance on grouping with CSGCombiner3D. It also directs users to node_set_property/material_manage for post-creation edits, but does not explicitly state when not 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses side effects: it kills the server in plugin-managed mode, drops the WebSocket transport, and can raise PLUGIN_DISCONNECTED on timeout. It also explains recovery steps and response shape differences, going well beyond basic expectations.
Agents need to know what a tool does to the world before 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 core purpose, then uses bolded mode sections and bullet-like details to convey complex transport behavior efficiently. Every sentence carries necessary operational information without fluff.
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 dangerous side effects and no annotations, the description covers both execution modes, return payloads, timeout behavior, error code, and recovery diagnostics. It is sufficiently complete given the optional single parameter and existing output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single optional session_id parameter, so baseline is 3. The description does not add additional parameter context, but the schema already states it targets a Godot session and defaults to active session.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 'Reload the Godot editor plugin' — a specific verb and resource. It further clarifies the mechanism ('Disables and re-enables the plugin on the next frame'), clearly differentiating it from sibling editor management tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides detailed context for both launch modes and expected response behavior, including reconnect guidance and timeout diagnostics. However, it does not explicitly name alternatives or state when not to use this tool relative to siblings like editor_manage or session_manage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description compensates well by disclosing stop()'s idempotent behavior ('succeeds with was_running=false'), strict parameter validation ('only the registered keys are accepted'), and the requirement that session_id be a sibling of op/params. It doesn't cover all possible side effects but gives meaningful behavioral insight.
Agents need to know what a tool does to the world before 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 well-organized with a bulleted list, code formatting, and a compact call shape example. Every sentence contributes unique value, and the structure makes the content easy to scan without unnecessary verbosity.
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 has an output schema, so the description need not cover return values. It thoroughly documents all operations and constraints, including idempotency and validation rules. However, it could be more explicit about error conditions or how settings_set interacts with a running project, leaving a minor gap.
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 description coverage is 0%, but the description fully compensates by explaining each operation's parameters: stop takes none, settings_get expects a key with a concrete example, settings_set takes key and value. It also clarifies the canonical call shape and parameter nesting rules, adding substantial meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence 'Project run/stop and project.godot settings' clearly defines the tool's scope. It then enumerates three concrete operations (stop, settings_get, settings_set) with specific one-line descriptions, effectively distinguishing it from sibling tools like project_run or game_manage.
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 actionable guidance by noting 'prefer for active-session reads' regarding resource forms, warning against passing extra params, and explaining session_id placement for multi-editor setups. While it does not exhaustively compare to every alternative, it provides clear do/don't rules.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses operation-specific behavior (e.g., root_name defaults to filename basename, get_roots flags the edited scene) and the canonical call shape with flat-op compatibility. It doesn't mention side effects like file overwrite behavior, but it is substantially 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 well-structured and front-loaded: a one-line summary, a resource-form hint, a bulleted list of operations with parameters, and a call-shape note. Every sentence adds value and there is no redundant content, making it both efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's multi-operation complexity and the presence of an output schema, the description is largely complete. It covers the input structure, operations, defaults, and compatibility alias. Minor missing edge cases (e.g., behavior when no scene is open for save_as) prevent a perfect score.
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 description coverage is 0% and the schema has a generic 'params' object, so the description is the only source of parameter meaning. It fully explains each operation's parameters (create with path, root_type, root_name; save_as with path; get_roots with no params) and the default behavior for root_name, compensating completely.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Scene authoring (create, save_as, list open roots)', which clearly states the tool's verb and resource. It distinguishes from siblings by enumerating three specific operations and noting the resource form for active-session reads, making its scope unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a clear usage context: for authoring scenes (create, save_as, get_roots) and explicitly recommends the resource form ('godot://scene/current' and 'godot://scene/hierarchy') for active-session reads. However, it doesn't name alternative sibling tools or provide explicit 'when not to use' guidance, so it stops short of full differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavior. It notes that detach is undoable, reveals what read returns (source, line count, file size), and explains the canonical call shape and compatibility alias. It does not mention permissions or error behavior, but the provided details are useful and non-contradictory.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear opening, a bulleted list of ops, and a code block for call shape. Every sentence contributes useful information, and the front-loaded purpose statement makes the tool's intent immediately clear.
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 presence of an output schema, the description covers what is needed: operation semantics, resource path format, canonical invocation, and compatibility alias. It is complete for a dispatch-style tool with three ops, and the output schema likely handles return-value documentation.
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. It explains the op enum, the params object, and session_id placement, and shows path as a parameter for each operation through signatures like read(path). This adds meaning beyond the bare schema, though it could be more explicit about required parameter fields per op.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as managing .gd scripts via three specific operations (read, detach, find_symbols), using specific verbs and resources. It effectively distinguishes itself from sibling tools like script_create, script_patch, and script_attach by focusing on read/detach/outline rather than creation or modification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context on when to use the resource form (prefer for active-session reads) and lists the available operations with their purpose. It does not explicitly mention when not to use this tool versus alternatives, but the op-level descriptions and the resource form guidance give adequate usage direction for most cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It explains precedence rules ("An exact id match always wins"), substring resolution requirements ("must resolve to exactly one session"), and error behavior ("returns an error listing the candidates"). This goes beyond the schema by detailing matching logic and failure modes, but does not cover broader effects like session persistence or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: the first sentence states the purpose, followed by a compact paragraph on matching rules. Every sentence contributes meaningful information—no filler, no repetition of schema content. The structure aids 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?
For a one-parameter setter tool with a simple state-changing operation, the description covers essential context: what it does, how to identify the session, and error behavior. An output schema exists, so return values are presumably documented there. The description is complete enough for an agent to invoke correctly without additional information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage for the single parameter, describing format and examples. The description adds further meaning by enumerating the fields matched by a substring hint (short name, project_path, session_id) and the precedence rule for exact IDs. This augmentation clarifies edge cases not fully documented in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb and resource: "Set the active Godot editor session for subsequent tool calls." It also distinguishes itself from siblings like session_manage by focusing on state setting rather than session management/list operations. The matching semantics further clarify its role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: before subsequent calls to target a specific session. It specifies the input format and matching behavior, but does not explicitly mention alternatives or exclusions (e.g., when to prefer session_manage). It is clear context without explicit negative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It adds meaningful detail: connect/disconnect are undoable, list filters out editor-internal connections by default but can surface them, and the response includes editor_connection_count. This goes beyond bare operation names, though it does not discuss permissions or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with a brief intro, three bullet-pointed operations, and a compact call-shape note. Every sentence provides useful information, and the structure makes the multi-op behavior easy to parse without unnecessary verbosity.
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 all operations, their parameter semantics, and key behaviors like undoability and default filtering. Since an output schema exists, return-value specifics are not required. It could briefly mention error conditions or signal name requirements, but the provided information is sufficient for most use cases.
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 description coverage is 0%, so the description must compensate fully, and it does. It names and explains each relevant parameter (path, include_editor, signal, target, method) within the operation snippets and clarifies the canonical call shape with op and params. This adds substantial meaning beyond the generic 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 identifies signals as Godot's event/observer mechanism and enumerates the three operations: list, connect, and disconnect. This is a specific verb+resource statement that clearly distinguishes this tool from the broader sibling set.
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?
Each operation is described with its intended use case: listing signals with optional editor-internal inclusion, connecting a signal to a target method, and disconnecting an existing connection. It does not explicitly name alternatives or exclusions among sibling tools, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains cascading behavior when applying a theme, that an empty theme_path clears, and includes overwrite semantics for create. It also clarifies parameter formats for color values, which adds useful context beyond what the schema provides.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy but well-structured, using a bulleted list of operations that makes it scannable. Every sentence adds value, though the density of options might be slightly overwhelming, but it remains appropriately sized for a tool with six distinct operations.
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 complexity of the tool with six operations and many optional parameters, the description is thorough. It covers all operations, parameter shapes, session targeting, and even a note on compatibility, making it complete for an agent to select and invoke correctly. The output schema exists, so return value details are not required.
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 description coverage is 0%, and the description fully compensates by detailing each operation's parameters, including supported value formats like colors, integers, and stylebox options. It also explains optional parameters for set_stylebox_flat and the compatibility alias for flat op parameters, providing rich meaning 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 clearly states it is for Theme authoring in Godot, a stylesheet-like resource for Controls. It lists specific operations (create, set_color, set_constant, set_font_size, set_stylebox_flat, apply) with distinct verbs and resources, making it easy to differentiate from sibling tools like ui_manage or resource_manage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the canonical call shape (op plus params dict) and notes the session_id wrapper for targeting a specific editor. It implies when to use the tool (theme editing) but does not explicitly mention alternatives or when not to use it, so it falls short of perfect 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?
With no annotations, the description fully discloses important behaviors: it creates in the default library, auto-creates AnimationPlayer if the path doesn't resolve (with parent requirement), and explains the root_node-relative track path handling. These are critical side effects and context not inferable from the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a tight, well-structured paragraph. It opens with the primary action, then the follow-up steps, and then crucial path semantics. No redundant or vague sentences exist.
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 6 parameters and an output schema, the description covers the main workflow, prerequisites (parent exists), and side effects. It does not explicitly describe failure behavior for existing clips when overwrite is false, but the overall context is sufficient for an agent to select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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. The description adds value beyond the schema by explaining the default library context, the auto-creation behavior tied to player_path, and the root_node relative path handling, which are not detailed in the parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the verb (Create), object (Animation clip), and context (inside an AnimationPlayer's default library). It differentiates from sibling tools like animation_manage by specifying that this creates the clip, not the tracks, and even directs users to proper follow-up operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides strong usage context by stating that after creating the clip, tracks are added via animation_manage ops. It also notes the auto-creation behavior for non-existent paths, though it could be more explicit about when not to use this tool compared to others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses behavioral details such as make_current unmarking previous cameras in one undo, class-aware configure behavior, Vector2 coercion, empty path resolution for get, and the flat-parameter compatibility alias. This is more than a minimal description, though it omits some edge-case side effects like invalid path handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a one-line summary, then bullet-pointed operations with signatures. Each bullet adds distinct operational detail or a caveat (e.g., 'Pass only the edges to change'). There is no fluff or repetition, and the information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's multi-operation complexity, the description is complete: it covers all eight operations, their parameters, edge cases like empty path for get, and the call shape. An output schema is indicated as present, so return values need not be explained. The description fully equips an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only defines op as an enum, params as a free-form object, and session_id, providing almost no parameter information. The description compensates fully by listing each operation's parameters with names, types, defaults, optional markers, and special semantics (e.g., drag_margins fractions, overrides merging). This is essential for correct use.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with 'Camera2D / Camera3D authoring' and enumerates eight specific operations with signatures, making the tool's purpose explicit. It also differentiates from sibling tools by stating that transforms belong to node_set_property, not here.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear negative guidance: transforms should be set via node_set_property, not camera_manage. Also explains the canonical call shape and compatibility alias for parameter passing. However, it does not explicitly state when to prefer camera_manage over the many sibling scene/camera-related tools beyond this one exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It thoroughly discloses behavior: default response size (50-150 entries), the meaning of count/total_count, handling of unknown fields, inclusion of null-valued properties, and script serialization details. This goes far beyond basic transparency.
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 purpose, then progressively adds detail. It is longer than minimal but every sentence adds value, with clear paragraph breaks for readability. 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?
The description covers edge cases (null values, unknown fields, script paths), response semantics, and performance considerations. While an output schema exists, the description still adds essential context that the schema alone would not provide, making it 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?
Schema coverage is 100%, so baseline is 3. The description adds meaningful semantics beyond the schema by explaining how the fields parameter affects the response, the relationship between count and total_count, and the unknown_fields behavior, enriching parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Get properties of a node,' using a specific verb and resource. It clearly differentiates from sibling tools like node_set_property (set) and node_find (search), making the tool's purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context for when to use this tool ('prefer for active-session reads') and offers performance guidance on using the fields filter. It does not explicitly exclude alternatives, but the mention of hot reads and filtering implies practical usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description carries the full burden. It discloses atomicity ('Atomically build'), validation ('Validates everything before mutating'), error conditions ('which errors'), and compatibility aliases for parameters. Could not mention return values, but an output schema exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Clearly structured with a one-line summary followed by bulleted ops with signatures and examples. Every sentence provides necessary detail (e.g., margin=0, theme_override_constants example) with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covering four distinct operations with constraints, pitfalls, and integration notes, the description is thorough for a UI authoring tool. It addresses canonical call shape and session_id handling, and the output schema likely covers return specifics. Minimal gaps for its complexity.
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's params object is generic (0% coverage), so the description fully compensates by documenting each operation's parameters with names, types, defaults, enums, and examples. For instance, set_anchor_preset lists all preset values and resize_mode options.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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: 'UI / Control authoring (HUD, menus, layouts, vector decoration).' It enumerates four distinct operations (set_anchor_preset, set_text, build_layout, draw_recipe) with concrete details, distinguishing it clearly from sibling tools like node_manage or scene_manage.
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 strong contextual guidance for specific operations, e.g., the note that CanvasLayer is not a Control and to apply presets to a Control child, and the warning about theme_override_constants vs direct properties. It does not explicitly name alternative tools, but the UI-specific scope is 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?
No annotations are provided, so the description fully carries the burden. It discloses persistence to project.godot, that remove does not delete files, and the canonical call shape with flat op parameters. This is comprehensive.
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 well-structured with bullet points for operations and clear front-loading of purpose. It is slightly verbose but efficient; every sentence adds value.
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 multi-operation complexity and absence of annotations, the description covers all necessary input contexts. An output schema exists, so the lack of output details is acceptable.
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 description coverage, the description details each operation's parameters (name, path, singleton) and the overall call structure (op, params, session_id), adding 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 clearly states that the tool manages 'autoload (global singleton) management', and lists the specific operations: list, add, remove. It distinguishes from siblings like node_manage and api_manage through the context of autoloads.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage contexts for each operation (list, add, remove) and explains the effect (persists to project.godot). It does not explicitly state when not to use, but the sibling tools imply different areas.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does an excellent job. It discloses execution stops at first error, rollback semantics, sequential processing, requirement to use underlying plugin command names, path notation relative to the edited scene root, and the restriction against nested batch_execute calls. This goes beyond what any annotation schema would typically provide.
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 adds necessary detail about format, behavior, and use cases. It is well-structured with a clear opening, a formatted example, and topic-specific sentences. While it could be slightly tightened, it remains efficient and informative without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the presence of an output schema (which handles return values), the description is complete: it covers input item structure, valid command names, execution ordering, failure handling, rollback semantics, path conventions, and a concrete example. No critical gaps are apparent for an agent to use this 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?
Although the schema covers all three parameters (100% coverage), the description adds substantial meaning: it specifies the precise structure of each commands array item (`{"command": "<plugin_command>", "params": {...}}`), enumerates example command names, explains the rollback effect of the `undo` parameter, and clarifies path semantics relative to the scene root. This is far beyond the schema's minimal parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Execute a list of editor sub-commands in order, stopping on first error,' which is a specific verb+resource with an explicit behavioral constraint. It distinguishes itself from sibling single-operation tools by focusing on batch composition and sequencing.
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 this to compose multi-step edits (create node + set property + attach script) into a single tool call,' providing a clear use case. It also notes that `batch_execute` itself cannot be a sub-command and explains the undo/rollback behavior, which guides correct usage, though it doesn't explicitly name alternative single-command 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?
With no annotations, the description fully carries the burden. It discloses a side effect (refreshes server's readiness cache), explains when that side effect is useful, and details special game_status.status values including 'break' and the need to call project_manage(op="stop").
Agents need to know what a tool does to the world before 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 multi-paragraph but tightly organized: purpose, alternative invocation, side effect, response-field clarifications, and special statuses. Each section earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity—state retrieval, cache synchronization, response interpretation, and special break behavior—the description covers all needed context. Since an output schema exists, return format details are not required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter session_id is already fully described in the schema ('Optional Godot session to target. Empty = active session.'). The description adds no additional parameter-level meaning, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Get current Godot editor state' and enumerates specific contents (version, readiness, open scene, play state). This clearly differentiates it from sibling management/mutation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states 'prefer for active-session reads', notes the alternative editor_manage(op="state") for clients wanting a single tool, and gives a concrete recovery scenario after EDITOR_NOT_READY. This is strong when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so admirably. It discloses buffer sizes (500/2000), retention across runs, run_id semantics, stale_run_id behavior, editor cursor mechanics (since_cursor supersedes offset), boot-time parse errors not captured, editor_errors_hint logic, and the effect of include_details. This is exceptionally transparent.
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 every section earns its place: source breakdowns, buffer sizes, run/cursor handling, and edge cases are all relevant. It is well-structured with clear labels. A slight deduction for length; it could potentially be tightened without losing critical details, but it avoids fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex with 7 parameters, multiple sources, and an output schema, but the description covers all aspects: sources, return fields (run_id, current_run_id, game_status, dropped_count, etc.), edge cases (boot-time errors, plugin-enable timing), and tail patterns. It is fully complete for a tool of this complexity, even with an output schema present.
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 the schema already provides 100% coverage with descriptions for all 7 parameters, the tool description goes far beyond the schema. It explains the intricate relationships between parameters, such as since_run_id reading prior runs, current_run_id vs run_id, since_cursor superseding offset, and the meaning of include_details. This adds substantial semantic value beyond the schema's field-level 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 opens with a specific verb and resource: 'Read recent log lines from the Godot editor, plugin, or running game.' It immediately distinguishes the tool by enumerating four sources (plugin, game, editor, all) and their purposes, which clearly separates it from sibling tools that manage scenes, scripts, nodes, etc.
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 offers concrete guidance on when to use each source, e.g., 'Use when the editor Output or Debugger Errors panel shows red/yellow rows but other sources turned up nothing' for the editor source. It also explains polling patterns for game and editor logs. However, it doesn't explicitly state when *not* to use this tool or name alternative tools, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description fully carries the transparency burden, and it does so excellently. Each op lists its side effects: save to disk, assign to node, inline material creation, error when file exists unless overwrite=True, and one undo action for apply_to_node. The compatibility alias for flat parameters is also disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but extremely well-structured: it opens with the tool's scope, then uses bullet-pointed op signatures, and closes with a note on call shape. Every sentence carries necessary information for a multi-op tool, though a couple of lines could be tightened without losing value.
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 complexity (eight operations, many parameter combinations) and the generic schema, the description leaves no critical gaps. It covers all ops, their parameters, error semantics, resource-form usage, and edge cases. Since an output schema exists, the lack of return-value descriptions is appropriate.
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 only exposes op, params, and session_id with 0% coverage of actual parameters. The description compensates comprehensively by providing full pseudo-signatures for every operation, including defaults, enum values, and domain-specific rules like texture properties accepting res:// paths and enum-valued params accepting names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a material authoring and management tool, listing specific material types (StandardMaterial3D, ORMMaterial3D, ShaderMaterial, CanvasItemMaterial) and eight concrete operations. It uses strong verbs like create, set_param, get, list, assign, apply_to_node, and apply_preset, making the tool's purpose very distinct from the vague 'material_manage' name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides detailed per-operation guidance, including parameter signatures, valid types, and behavior like overwrite errors and undo grouping. It also notes the canonical call shape and a compatibility alias. However, it does not explicitly compare this tool to siblings like resource_manage, so alternatives are not discussed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description takes full responsibility for disclosing behavior. It does this thoroughly: mentions that all write ops create nodes and sub-resources in a single undo action, that restart is runtime-only and not undoable, and that unknown override keys return INVALID_PARAMS rather than being silently dropped. It also details auto-creation of ProcessMaterial and QuadMesh, which is crucial for understanding side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every sentence carries specific technical content. It is well-structured with bullet points per operation, making it easy to scan. While it could be trimmed slightly (e.g., repeating 'auto-creates ProcessMaterial' for GPU emitters), the density of useful information justifies its length. It is front-loaded with the core purpose and then elaborates appropriately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all operations, parameter semantics, error behavior, response reporting ('response reports applied_main / applied_process / applied_draw'), and cross-type constraints (GPU vs CPU, 2D vs 3D). It handles edge cases like overrides routing and invalid keys. Given the tool's complexity and the minimal schema, this description is exceptionally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is minimal (op, params, session_id) with 0% schema description coverage. The description compensates magnificently by explaining every operation's parameters in detail, including property names, types, defaults, and per-type variations (e.g., 'GPU gravity requires {x, y, z} even for gpu_2d'). It also explains the canonical call shape and flat-op compatibility alias, providing meaning far 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 'Particle systems (GPUParticles2D/3D, CPUParticles2D/3D)', immediately identifying the specific resource. It then enumerates all operations (create, set_main, set_process, etc.) with a clear verb for each, making it unambiguous what the tool does and distinguishing it from sibling manage tools like animation_manage or material_manage.
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 particle emitters need to be created, configured, or restarted. It provides context for particle-specific behavior (e.g., GPU vs CPU, 2D vs 3D) and even notes edge cases like 'GPU gravity is a Vector3' and 'cpu_* types reject draw overrides.' However, it does not explicitly state 'use this instead of X' or provide exclusions versus sibling tools, so it falls slightly short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does this thoroughly: notes read-only operations ('get_info'), undoable operations ('assign', 'create'), pagination and filtering requirements for 'search', auto-creation behavior for 'curve_set_points' and 'physics_shape_autofit', and error candidate paths in 'error.data.candidates'. This is rich behavioral context beyond what schema alone could provide.
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 well-structured: a summary sentence, a bulleted list of operations with parameters and explanations, and a canonical call shape note. Each line earns its place for a multi-operation tool. Slight verbosity in repeated 'path+property' patterns, but not excessive given 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?
The description is complete for a tool with 10 operations and no annotations. It covers all operation behaviors, parameter semantics, output/error signals (e.g., candidate paths), and even the canonical call shape. The output schema exists and is generic, so the description rightfully focuses on operation-specific semantics, making this fully adequate.
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 description coverage is 0%, so the description is the sole source of parameter meaning. It compensates exhaustively by explaining each parameter inline per operation, including format examples like 'sky may be bool or a procedural sky dict' and distinct shape_type forms for 2D/3D. This fully compensates for the generic 'params' object in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Resource (asset) search, inspection, assignment, and creation.' It then enumerates each operation with its purpose, distinguishing itself from sibling tools like node_manage or scene_manage by focusing on Resource subclasses. The scope is clear and detailed.
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 and per-operation guidance, including a note 'For specific families (Curve, Environment, etc.) prefer the dedicated ops.' This helps the agent choose among internal operations, but it does not explicitly contrast this tool with sibling tools like material_manage or animation_manage, so some cross-tool guidance is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavior, and it excels. It states failure conditions ('Fails on multiple matches unless replace_all=True; fails on zero matches'), exact matching semantics ('Exact byte match (whitespace significant)'), side effects ('Triggers filesystem scan'), and undo limitations ('Not undoable via Ctrl+Z'). This is comprehensive and 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 concise and well-organized. Each sentence delivers essential information: first the overall purpose, then the matching behavior, failure modes, exactness, and side effects. No fluff or redundancy; it earns a perfect score 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?
For a tool with 5 parameters, no annotations, and an output schema, the description covers all necessary operational aspects: exact replacement behavior, failure conditions, replace_all option, side effects, and undoability. It does not need to describe return values because an output schema exists. It is fully complete given the tool's 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?
Schema coverage is 100%, so a baseline of 3 applies. The description adds value by clarifying the matching semantics ('Exact byte match (whitespace significant)') and reinforcing the uniqueness of old_text unless replace_all. This goes beyond the schema's 'Exact substring' phrasing, thus warranting 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 specific verb and resource: 'Anchor-based string-replace edit on a .gd file.' This clearly distinguishes it from sibling tools like script_create or script_manage by specifying the exact operation (string replacement) and the target file type. The behavior is unambiguous and sets expectations precisely.
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 strong context for when to use the tool: for exact, controlled string-replacements on .gd files, with explicit notes about failure on multiple/zero matches and the replace_all option. It does not explicitly name alternatives or state 'when-not-to-use,' but the clarity of behavior implies appropriate usage, so it earns a 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description fully carries behavioral disclosure. It reveals the 300s timeout, partial result handling via TEST_RUN_TIMEOUT, ability to retrieve full partials via test_manage, session safety between tests, risk of long blocking tests, and the response including edited_scene and scene_warning.
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 well-structured, starting with the core action, then parameter details, then constraints and response info. It is somewhat lengthy but every sentence provides value; could be slightly shorter without losing clarity.
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 shown, the description covers timeout, partial results, usage restrictions, and response fields. It provides enough detail for an agent to invoke and interpret results correctly, including edge cases like scene warnings.
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 100% with descriptions for all 5 parameters. The description adds meaningful context beyond defaults and schemas, such as explaining the purpose of verbose (compact vs verbose), suite filtering, test name substring matching, and exclusion capability.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool runs GDScript test suites in the Godot editor, detailing discovery of test files, execution, and summary output. It is clearly distinct from sibling tools like node_manage or scene_open.
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, including that it is not allowed inside batch_execute. It describes verbose mode and session targeting, but does not explicitly mention when alternatives might be preferred (though siblings are unrelated management tools, making this the sole test tool).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and excels. It discloses behavior such as 'quit() gracefully quit the Godot editor on next frame', logs_clear returning cleared_count, the opt-in nature of clearing debugger errors, and the subtle 'await only progresses while the game window is focused'. It also explains all game_eval error codes in detail. No contradictions with annotations exist (none provided).
Agents need to know what a tool does to the world before 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 elegantly structured: a summary line, resource-form note, bulleted operation list with details, and call-shape explanation. Every sentence earns its place; the length is justified by the multiple operations and error cases covered. It front-loads the core purpose and follows with specifics.
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 has six operations, no annotations, no parameter descriptions in schema, and only a sparse input schema, the description is impressively complete. It covers return values for logs_clear, all game_eval error conditions, and operational nuances. The presence of an output schema covers basic return structures, so the description need not repeat those; no critical gaps remain.
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 description coverage is 0%, so the description fully compensates by documenting each operation's parameters inline (selection_set(paths), monitors_get(monitors=None), logs_clear(clear_debugger_errors=False), game_eval(code)). It also clarifies the canonical call shape ({'op': '<verb>', 'params': {...}}) and the flat-parameter alias, which adds meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Editor selection, performance monitors, quit, log clearing, game eval' and then enumerates specific operations with verbs (state(), selection_get(), selection_set(), etc.), making the tool's purpose crystal clear. It distinguishes from siblings like editor_state (which likely reads state only) and logs_read (separate tool) by covering management actions beyond simple reads.
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 recommends 'Resource forms (prefer for active-session reads)' for state/selection/performance, guiding when to use the alternative resource-based access. For game_eval, it details when to retry (EVAL_GAME_NOT_READY) and when not to (EVAL_HUNG). However, it does not explicitly compare to each sibling tool, so it lacks full exclusionary 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?
With no annotations, the description carries full behavioral disclosure. It reveals that write operations are undoable via EditorUndoRedoManager, explains item=-1 erase semantics and orientation range 0..24, and specifies return structures for every operation. This is exemplary transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a summary, a 'Ops:' bulleted list, and a closing canonical call-shape note. Each sentence adds value, and the bullet format makes complex multi-operation details easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all five sub-operations with parameters and returns, the call shape, scene targeting, and undo behavior. Given the tool's complexity and lack of annotations, this is fully complete for agent invocation.
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 description coverage is 0%, but the description fully compensates by documenting every operation's parameters (path, item, map coordinates, rect dimensions, orientation) and giving semantic details like valid item discovery and orientation index meaning. It adds far more meaning than the sparse 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 opens with 'GridMap authoring (set items, fill 3D regions, clear, read cells + library items)', naming specific verbs and a concrete resource (GridMap nodes). It distinguishes itself from sibling 2D tile/tileset tools by explicitly focusing on 3D GridMap operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states that all operations target GridMap nodes in the currently edited scene by scene-relative path, and it recommends using gridmap_list_library_items before placing cells. It doesn't explicitly exclude alternative tools, but the '3D analogue of tileset atlas inspection' note gives contextual differentiation from sibling 2D 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?
With no annotations provided, the description carries the full burden and does so thoroughly. It discloses idempotency, waits briefly for the helper, defines all status values (not_live, no_helper, stopped, break), explains the implications of a break state, and advises on recovery. Autosave side effects are also mentioned. This is exceptionally transparent behavior disclosure.
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 every sentence adds essential information. It is well-structured with paragraphs for modes, idempotency, and response statuses. While the status explanation is detailed, it's necessary for correct interpretation. No fluff, but the length pushes the boundary of conciseness; still, it 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?
Given the tool's complexity (multiple modes, statuses, helper interaction, error states), the description is comprehensive. It covers edge cases like no helper autoload, break during boot with script errors, and late transitions via editor_state. The output schema exists, so return values are structured, but the description explains their semantics fully. This is a complete picture for an AI agent.
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 each parameter already has a description. The description adds extra context by explaining the meaning of mode values (e.g., custom requires scene), the autosave use case for smoke tests, and the role of session_id (though not explicitly named, the schema covers it). This adds value beyond the schema without redundancy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Run (play) the Godot project from the editor.' It then lists specific modes (main, current, custom) and distinguishes from the sibling tool project_manage by explaining when to stop the project first. This is a specific verb+resource that stands out from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidance is provided: when to use each mode, how to switch scenes (call project_manage(op="stop") first), and the optional autosave behavior for smoke tests. The description also explains what happens if the project is already running, guiding the agent on whether to stop first. This clearly differentiates when to use project_run vs alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the behavioral burden. It discloses that force_reload discards unsaved in-memory edits, that the reply is sent only after the switch lands, and describes the two non-success paths (switched:false with settle timeout or not_waited) with a recommendation to re-check editor_state. This is exemplary.
Agents need to know what a tool does to the world before 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 efficiently structured. The first sentence gives the purpose, the second paragraph explains edge cases and force_reload, and the third covers reply timing and safe write conditions. Every sentence contributes to decision-making, with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with moderate parameters and significant behavioral nuance, the description covers all critical aspects: synchronous vs asynchronous behavior, timeout semantics, discard behavior, and follow-up safety. An output schema exists, so return values are handled elsewhere. This is fully complete 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.
Parameters5/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 adds substantial meaning: it gives a concrete path example (res://main.tscn), explains the no-op default, and details the force_reload parameter's destructive semantics (discarding unsaved edits). It also clarifies the interaction between path, force_reload, and settle behavior, going 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 a specific verb and resource: 'Open an existing scene file (.tscn) in the editor.' This clearly identifies the tool's function and distinguishes it from siblings like scene_save or scene_manage. The .tscn extension and 'existing scene file' add precision.
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 strong contextual guidance: explains the no-op behavior when the path is already the current scene, instructs when to use force_reload, and clarifies the reply timing and settle semantics. It does not explicitly name alternative tools or state when-not-to-use, but the context is unambiguous and actionable, missing only a direct comparison to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and exceeds expectations. Each op explicitly states 'Read-only — does not modify any resource or project file' and the image op adds 'reads the texture directly from the resource without any UI interaction.' It documents error codes, return formats, and the max_size scaling behavior. This is exemplary behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but meticulously structured with bullet points, consistent formatting, and a clear top-level summary. Each sentence earns its place—the repeated error code lists are justified for self-contained ops. The front-loaded 'TileSet management — atlas inspection tools' immediately orients the reader.
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 two-op dispatcher, the description is comprehensive: it covers purpose, parameters, return values, error codes, the canonical call shape, and usage guidance. The output schema isn't shown, but the return structures are documented in text. The tool's complexity is fully addressed.
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 is generic with 0% parameter description coverage, but the description fully compensates by documenting every operation-specific parameter: names (tileset_path, source_id, max_size), types, required status, and defaults. It also explains return structures and error codes. This provides complete semantic 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 identifies the tool as 'TileSet management — atlas inspection tools' and enumerates two specific operations with precise verbs: 'Return all occupied atlas tile positions' and 'Return the atlas sprite-sheet texture'. This distinguishes it from sibling tools like tilemap_manage and editor_screenshot by focusing on read-only TileSet atlas inspection.
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 an explicit usage recommendation: 'To visually inspect what tiles look like, use tileset_get_atlas_image instead of editor screenshots. It reads the texture directly from the resource — no UI interaction or editor state required.' This directly contrasts with a sibling tool. It also repeatedly states read-only behavior, implying when to use. However, it does not explicitly mention when not to use the tool or alternatives for the tiles query.
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?
No annotations are provided, so the description carries full transparency burden. It thoroughly discloses side effects: persistence to project.godot, idempotency of ensure operations, removal even of non-loaded actions, rejection of out-of-range deadzone with VALUE_OUT_OF_RANGE, and default parameter 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 well-structured with bulleted operations and nested sub-bullets, front-loading the main purpose. However, it is quite lengthy; some details (e.g., keycode examples) could be slightly trimmed without loss of clarity. Still, the structure aids readability.
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 complexity (6 operations with varied parameters), the description covers all necessary aspects: purpose, each operation's behavior, parameter constraints, persistence model, and a canonical call shape. An output schema exists, so return value descriptions are not required. Minor omissions (like error details for other scenarios) are acceptable given the thoroughness.
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 description coverage is 0%, so the description must compensate. It does so exhaustively: for each operation, it lists and explains all parameters (e.g., include_builtin, deadzone range, keycode format, button indices). The description adds meaning far beyond the minimal input 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 that the tool manages InputMap actions and bindings (keyboard, mouse, gamepad) persisted to project.godot. It explicitly lists six operations, making the purpose concrete and distinguishable from sibling tools like node_manage or audio_manage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance, e.g., 'prefer for active-session reads' for the resource form, and distinguishes between operations like add_action and ensure_action for creation vs idempotent creation. It also clarifies the default behavior of list() and suggests typical deadzone values.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and excels: it documents error shapes (EDITOR_NOT_READY, NODE_NOT_FOUND, GAME_HELPER_TIMEOUT), the stale_frame note for backgrounded games, camera selection fallback for cinematic, and return behaviors like include_image and AABB metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a lead sentence, a guidance paragraph, a bulleted source list, and a closing note on parameters. Each section earns its place; the length is justified by the tool's four modes and ten 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?
Given no output schema, the description explains what callers receive (MCP ImageContent, AABB metadata, error data) and covers edge cases (no scene, no 3D content, no Camera3D, game not running, backgrounded game). It is fully actionable.
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 adds significant meaning: it explains that view_target takes comma-separated Node3D paths and reframes the editor camera, that coverage=True captures perspective + orthographic top-down references alongside AABB, and clarifies the behavior of include_image and default source.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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: 'Capture a screenshot of the Godot editor viewport or running game.' It clearly delineates four sources and is distinct from any sibling tool, so purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit source-selection guidance: default 'viewport' requires Node3D content, 'viewport_2d' for 2D scenes, 'cinematic' requires a Camera3D, and 'game' requires a running project. It also gives exclusionary constraints, e.g., 'viewport_2d' is 'Not compatible with view_target/coverage/elevation/azimuth/fov.' and advises switching to 'cinematic' under specific conditions.
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?
No annotations are present, so the description carries full behavioral disclosure. It reveals side effects (write_text creates/overwrites and includes data.cleanup.rm for new files), caveats (reimport on non-imported paths reports skipped_non_imported and does not prove script validity), and concurrency behavior (scan is single-flight).
Agents need to know what a tool does to the world before 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 structured as a bulleted list of ops with code formatting, making it scannable. Each paragraph provides essential details without redundancy, and even the longer reimport/scan entries contain only pertinent caveats and cross-references.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool exposes five distinct operations with different input/output behavior; the description covers all of them, including return fields, edge cases, and invocation shape. It also accounts for integration with sibling tools (script_patch, script_create, resource_manage) and global class_name registration, making it complete for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only provides an opaque 'params' object, so the description is the sole source of parameter meaning. It lists each op's parameters with defaults and constraints, e.g., 'search(name="", type="", path="", offset=0, limit=100)' and 'At least one filter must be set'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The opening line 'Project filesystem access via the Godot editor's EditorFileSystem' clearly identifies the tool's domain. Each listed op (read_text, write_text, reimport, scan, search) uses a specific verb and resource, and the description distinguishes the tool from sibling tools by focusing on filesystem operations rather than scene/script/project management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly contrasts this tool with alternatives: for scripts it says 'Use script_patch/script_create to save a script and receive fresh diagnostics' and for assets awaiting first import it says 'or scan...'. It also explains when scan is needed after adding class_name scripts, and notes write_text only does single-file updates, not a full scan.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden of behavioral disclosure. It reveals important traits: 'A present but malformed position is rejected rather than silently falling back to the cursor,' 'Action-based input is focus-independent, so it works on a backgrounded game window,' and 'Cannot run inside batch_execute.' It also describes replies, state reads, and the effect of each op on the running game.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but appropriately structured: a one-line summary, a prerequisite note, then a consistent bulleted list of ops with syntax and parameter details. The canonical call shape paragraph adds useful invocation context without redundancy. Every sentence provides valuable information; nothing is wasted.
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 nine sub-operations, a minimal schema, and no annotations, this description is remarkably complete. It covers prerequisites, parameter semantics, timing and ordering constraints, return metadata (e.g., 'Includes path, type, text where present'), and usage exclusions. An agent can confidently select the right op and invoke it correctly without additional information.
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 only defines an `op` enum and a generic `params` object with additionalProperties true, offering zero parameter descriptions. The description compensates fully by detailing every parameter for each operation, including types, defaults, and constraints such as get_scene_tree's root_path behavior, input_mouse's position format and malformed-value handling, and input_sequence's step ordering requirement.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 'Runtime game inspection and input simulation,' which is a specific verb+resource statement that clearly distinguishes this tool from sibling tools like editor_manage or scene_manage. It then enumerates nine distinct operations with clear names and one-line purposes, leaving no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states the prerequisite: 'Start the project first with project_run and poll editor_state until game_capture_ready=true.' It also provides usage guidance within the tool, e.g., 'Use this instead of separate input_action calls whenever timing matters' and 'Cannot run inside batch_execute,' which tells the agent when to use this tool and when not to.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and delivers detailed behavioral context: type coercion rules for Vector2/3, Color, NodePath, Resource, StringName, and Array/Dictionary, plus behavior for null/empty values. It also discloses a common failure mode (PROPERTY_NOT_ON_CLASS) and provides concrete examples of correct property names.
Agents need to know what a tool does to the world before 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 well-structured with a clear opening, followed by a verification note and a bulleted list of type coercions. Every sentence earns its place, and the length is justified by the complexity of type handling. It is front-loaded with the core purpose.
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 complexity (type coercion, resource handling, error modes) and the presence of an output schema, the description is remarkably complete. It explains not only what the tool does but also the nuances of value conversion, common pitfalls, and when to use complementary tools.
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 coverage is 100%, the description adds significant meaning beyond the schema by explaining how 'value' is interpreted for different types, how resources are handled, and how to clear properties. It enriches the 'property' parameter with the verify-first guidance, adding practical semantics not present in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Set a property on a node', a specific verb+resource statement that clearly distinguishes it from siblings like node_create, node_get_properties, and node_manage. It unambiguously states 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs users to verify the property name with node_get_properties (or the godot:// endpoint) before writing, and warns against guessing. Also mentions resource_manage for more control over resource creation, providing clear guidance on when to use this tool vs alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

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

Score Badge

Copy to your README.md:

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

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/hi-godot/godot-ai'

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