WazziCode Godot

Server Quality Checklist

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

Latest release: v3.1.1
Disambiguation3/5
Several tools have overlapping or duplicate functionality: editor_state and editor_manage(op="state") are the same operation, godot_verify and godot_orient both probe health/state, and resource_manage search overlaps with filesystem_manage search. While descriptions are highly detailed, the tool boundaries are not always crisp.
Naming Consistency4/5
The pervasive <domain>_manage convention (scene_manage, resource_manage, project_manage, etc.) provides a strong pattern, but it is mixed with standalone action verbs (scene_open, node_create, script_patch, project_run, editor_screenshot, logs_read, godot_verify, batch_execute). This is a mostly consistent system with a few notable exceptions.
Tool Count2/5
45 tools is excessive for a single server, exceeding the 25+ threshold. Many tools are umbrella managers bundling multiple ops, and some duplicate functionality (editor_state vs editor_manage, scene_manage vs scene_open/scene_save), making the surface feel bloated and harder to navigate.
Completeness4/5
The tool set covers an impressively broad range of Godot editor functionality: scene, node, script, resource, material, animation, particle, camera, audio, UI, tilemap, tests, runtime input, and project settings. Minor gaps like scene file deletion or export management exist but are not critical for core workflows.
Average 4.6/5 across 45 of 45 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 21 commits in the last 12 weeks
- Last stable release on August 21, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full burden of behavioral disclosure. It only says 'save to disk' without stating that this overwrites the existing scene file, whether confirmation is required, what happens if no scene is currently edited, or what the response contains. This is a significant gap for a mutation-like operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise, front-loaded sentence. Every word contributes to the core purpose, and there is no fluff or repetition. For a simple save operation this level of conciseness is ideal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a simple schema with one optional parameter and an output schema, so the description does not need to explain return values. However, the lack of usage context and behavioral caveats leaves the description merely adequate. It is not as complete as it could be for a tool that persists state and may overwrite files.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for the single parameter (session_id), so the schema already explains its meaning and default behavior. The tool description adds no parameter-specific information, but the baseline of 3 is appropriate when the schema adequately documents parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Save the currently edited scene to disk' uses a specific verb (save), a clear resource (scene), and a distinct target/destination (currently edited scene to disk). This clearly differentiates it from siblings like scene_open and scene_manage, which involve opening or managing rather than persisting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided about when to use this tool versus alternatives. There is no mention of prerequisites, when to prefer scene_save over scene_manage or resource_manage, or any exclusions. The context is only implied by the tool's name and the phrase 'currently edited scene.'
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 of behavioral disclosure. It meaningfully discloses that the tool replaces any existing script on the node and is undoable, which is important for a mutating operation. However, it does not detail error conditions, permission requirements, or interaction with session_id, but the disclosed traits are valuable and accurate.
Agents need to know what a tool does to the world before 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 and immediately states the core action. The second sentence adds a crucial caveat (replacement and undoability) without redundant wording. Every word contributes, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a relatively simple tool with a full input schema and an output schema, the description covers the essential purpose and behavioral cautions. It does not discuss return values or error handling, but the presence of an output schema reduces that burden. Missing guidance about alternatives is captured under usage guidelines, so this dimension is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds no parameter-level detail beyond the schema, which already explains path, script_path, and session_id. It does not improve understanding of parameter relationships or formatting, but no degradation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Attach a script to a node in the scene tree.' It clearly distinguishes itself from siblings like script_create (creating a script file) and script_patch (modifying script code) by focusing on the attachment action and its effect on a node.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for attaching scripts to nodes but provides no explicit when/when-not guidance or alternatives. It states the replacement behavior, which serves as a caution, but does not mention other tools like node_set_property that could achieve a similar effect. This is implied usage rather than explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses the returned metadata fields, including the additional exclude_domains field, and describes the call shape and aliases. However, it does not explicitly state whether the operation is read-only, any side effects, authentication requirements, or error behavior. It provides useful output context but leaves some behavioral assumptions implicit.
Agents need to know what a tool does to the world before 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 header, resource form note, operation bullet, and canonical call shape. It uses formatting to front-load the key purpose and keeps each sentence informative. There is no redundant or extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a listing tool, the description is quite complete: it enumerates all returned fields, specifies the resource form, and explains the invocation formats. The presence of an output schema further reduces the need to describe return values. However, it stops short of stating read-only behavior or error conditions, which would be needed for full completeness given the lack of annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains that 'op' is the verb ('list'), 'params' is an optional object, and 'session_id' remains top-level. It also details the canonical call shape and the flat-parameter compatibility alias, which adds meaningful semantic context 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 starts with 'Session listing' and details the list() operation, clearly stating that it lists every connected Godot editor with extensive metadata. It differentiates from sibling tools like session_activate by focusing solely on listing, and includes the resource form for resource-aware clients, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys that this tool is for listing sessions and mentions a preferred resource form for resource-aware clients. However, it does not explicitly state when to use this tool over alternatives like session_activate, nor does it provide exclusions or conditions. The context is clear but lacks 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states the tool performs a read-only re-fetch of the most recent payload and does not re-execute tests, which clarifies its non-destructive nature. It also describes the canonical call shape and compatibility alias, adding useful behavioral context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a brief purpose statement, a resource form, an ops list, and a canonical call shape example. Every section adds value with no redundancy, and the use of bullet formatting aids scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, with a single operation, and the description covers its behavior, parameters, and call shape. An output schema exists, so return values are implicitly covered. However, it does not mention edge cases such as behavior when no test run exists, which would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no property descriptions (0% coverage), so the description must explain parameters. It explains the verbose flag for results_get and describes the params structure via the canonical call shape, including the flat-parameter alias. However, it does not explain the session_id parameter, leaving a gap in full parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool inspects test results by re-fetching the most recent test_run payload. It names the specific operation (results_get), the resource form (godot://test/results), and distinguishes itself from test execution by explicitly noting "no re-execution." This makes it distinct from sibling tools like test_run.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context by recommending "prefer for active-session reads" and noting it avoids re-execution, implying it is for inspecting prior results rather than running tests. However, it does not explicitly name alternatives like test_run for execution, which would make the guidance more complete.
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 it delivers: it discloses fresh probes, stale cache reporting, bounded diagnostic windows, that it does not write project content, that test scripts are responsible for their own side effects, and the exact verdict types. This is highly 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 front-loaded with the core purpose. Each paragraph adds value: purpose/behavior, optional test running with a side-effect warning, and verdict/response semantics. No wasted sentences.
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, the description is sufficiently complete. It explains the orchestration behavior, optional test integration, safety guarantees, and verdict meanings, leaving no major gaps for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are already well-documented. The description adds some context for run_tests (invokes the in-editor runner) and mentions optional filters, but does not substantially enhance parameter understanding beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Verify live Godot health with an explicit, evidence-based verdict.' It uses a specific verb and resource, and distinguishes itself from siblings like test_run by framing itself as an orchestration tool that does not write project content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (e.g., 'Set run_tests=True to also invoke the existing in-editor runner') but does not explicitly contrast it with alternative tools like test_run or state when not to use it. Usage context is present but no clear exclusions or alternatives are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It discloses pagination, flat list structure, depth behavior, and return fields. This is sufficient for read-only 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?
Three short sentences, front-loaded with purpose, then return details, then resource form. Zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, so return values are covered. Description adds pagination and hierarchy walk context, and resource form. Complete for a read tool with 4 well-documented params.
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?
All 4 parameters have complete schema descriptions (100% coverage), so description adds minimal param info. Mentions depth behavior which aligns with schema, but no extra value needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb 'Get' with 'scene tree hierarchy' and 'open scene' clearly identifies the tool. Mentions return content (name, type, path, child count) which distinguishes it from node_find or node_get_properties.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
States 'prefer for active-session reads', giving a clear usage context. Does not explicitly name alternative tools, but implies a preference for hierarchy reads over other scene or node tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool adds the node to the parent and that scene_path overrides type. This is meaningful behavioral detail beyond the obvious mutation. It omits error handling or permission requirements, but the core behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: a one-sentence summary followed by a brief elaboration. Every sentence adds value, with no redundancy or filler. The information is front-loaded for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the primary decision (type vs scene_path) and the core creation behavior. With six optional parameters and an output schema, the description does not need to detail each parameter or return values. However, it could briefly mention prerequisites like an open scene, leaving a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of the parameters, so the baseline is 3. The description adds extra value by explaining the mutual exclusivity between type and scene_path, which is not apparent from the schema alone. This elevates 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 starts with 'Create (spawn) a new node in the scene tree,' a specific verb and resource, and immediately clarifies two modes: creating by type or instantiating a PackedScene. This clearly distinguishes it from sibling tools like node_set_property or node_find, which operate on existing nodes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use this tool: to add a new node to the scene tree, with explicit guidance on the two mutually exclusive modes. However, it does not name alternatives (e.g., 'for modifying an existing node, use node_set_property') or provide when-not-to-use exclusions, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It adds crucial facts: mandatory filter, AND semantics, and pagination. It could mention more about recursion depth or error handling, but the output schema covers return values, so this is solid.
Agents need to know what a tool does to the world before 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: four short sentences with zero filler. The purpose is front-loaded, and each subsequent sentence adds a necessary constraint or behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity and the existence of an output schema, the description covers all critical aspects: filters, mandatory filter, AND logic, and pagination. Minor omissions like recursion depth or sorting order do not significantly hinder use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter described individually. The description adds cross-parameter semantics: at least one filter must be provided and filters AND together, which is not evident from the schema alone. It does not mention session_id, but the schema covers that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Find') and resource ('nodes in the scene tree'), plus search criteria (by name, type, or group). It distinguishes this from sibling tools like scene_get_hierarchy (which gets hierarchy) and node_get_properties (which gets properties).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit usage constraints: at least one filter must be provided, filters combine with AND, and pagination is used. However, it does not explicitly mention alternatives or 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, the description carries the full burden. It discloses that `detach` is 'Undoable' and removes the currently attached script, and specifies the return values for `read` (full source, line count, file size) and `find_symbols` (class_name, extends, functions, signals, @export vars). It does not cover permissions, error handling, or session requirements, but the key side effect (detach) is disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: a one-sentence summary, then a resource form note, a bulleted op list, and a canonical call shape. No sentence is wasted, and it uses markup for scannability.
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 multi-op tool with three operations and an output schema, the description covers the resource form, each op's purpose/return, and the invocation format. It omits edge cases like error behavior and when `session_id` is mandated, but the presence of an output schema fills some return-value gaps. Overall, it is sufficiently complete for an agent to invoke correctly in typical scenarios.
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% for parameter explanations, but the description enriches each op with its expected argument (e.g., `read(path)`, `detach(path)`, `find_symbols(path)`) and shows the canonical call shape. This compensates for the opaque `params` object (additionalProperties: true) but leaves `session_id` unexplained, though the schema provides a default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter 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 explicitly states 'Script (.gd) reading, detachment, and outline,' naming the resource and three distinct operations (read, detach, find_symbols). This clearly distinguishes it from sibling script tools like script_create, script_patch, and script_attach.
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 operational scope by enumerating the three ops and notes a preference for the `godot://script/{path}` resource form for active-session reads. However, it does not explicitly contrast with sibling tools or state when not to use each op, though the op names and behavior make usage contexts self-evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses key matching behavior: exact IDs always win, substring hints must resolve to exactly one session or return an error listing candidates. This goes beyond the schema and clarifies the tool's execution semantics, though it does not mention underlying side effects beyond setting the active session.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states purpose, the second explains matching rules and error behavior. Every sentence provides useful information with no repetition or fluff. The content is front-loaded, making it easy for an agent to extract key facts quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with an output schema and no annotations, the description covers purpose, matching behavior, and error handling. It could explicitly mention that sessions must already exist or direct users to session_manage, but the schema fills in the listing reference. Given the low complexity, the description is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter, so the baseline is 3. The description adds value by explaining matching precedence (exact ID vs substring) and the error case, which enriches the parameter's meaning beyond the schema's description of acceptable input formats. This justifies 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 clearly states a specific action: 'Set the active Godot editor session for subsequent tool calls.' This immediately distinguishes it from sibling tools like session_manage (which likely manages sessions) and other editor operations. The verb 'set' and resource 'active Godot editor session' are explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it: before subsequent calls to affect which session they operate on. However, it does not explicitly contrast with session_manage or mention alternatives. The schema references session_manage for listing sessions, which adds context, but the main description leaves the 'when to use vs alternatives' slightly implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses that no scene instance is created, that 'all' does not include inheritors, and that pagination works per section. It does not mention potential errors or permissions, but for a read-only inspection tool the disclosed behavior 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with resource form, ops, and call-shape sections, and every sentence adds value. It is somewhat lengthy due to detailed parameter explanations, but this is justified given the schema gap. It avoids repetition and stays organized.
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 has an output schema, and the description provides complete operational context: purpose, usage, parameter details, pagination behavior, and call format. It leaves little ambiguity for an agent to select and invoke the tool correctly, even among many siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must fully explain parameters. It does so extensively: sections can be a comma-separated string or list, defaults to ['properties'] only, 'all' excludes inheritors, and offset/limit apply per section. The op signature and call shape are also explained, fully compensating for 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 clearly states the tool inspects Godot API documentation-shaped metadata from the ClassDB, with specific examples like 'what properties does X have' and method signatures. It distinguishes itself from runtime node inspection by noting it works 'without creating a scene instance', making it distinct from sibling tools like node_get_properties.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool, such as 'prefer for active-session reads' and details the resource form. It explains section selection and pagination but does not explicitly name alternative tools or exclusion scenarios, so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description compensates by flagging 'Not undoable' for play/stop, noting 'real editor preview playback', and stating atomicity for player_set_playback. It could go further by disclosing side effects of create/set operations, but the provided behavioral notes are valuable.
Agents need to know what a tool does to the world before 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, using a bulleted list with one-line ops. Every sentence earns its place, and the canonical call-shape note is necessary for a multi-op tool. No fluff 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?
All six operations are documented with parameters and some return info (e.g., duration_seconds for player_set_stream). The description lacks explicit error/edge-case behavior, but the presence of an output schema reduces the need to explain return formats, making this sufficiently 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 top-level schema has zero descriptions, but the description fully specifies each sub-command's parameters, types, defaults, and requirements (e.g., 'at least one of volume_db/pitch_scale/autoplay/bus required'). This adds essential meaning beyond the schema, making it highly effective.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 'Sound effects, music, ambience (AudioStreamPlayer / 2D / 3D)', clearly identifying the tool as audio management. It then enumerates six concrete operations (player_create, player_set_stream, etc.), making the purpose specific and well-distinguished from sibling tools like node_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 provides clear domain context ('sound effects, music, ambience') and operation-level details, such as when to use player_create vs play. However, it does not explicitly compare with alternative tools (e.g., resource_manage for loading streams), so alternatives are not named.
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 clearly discloses that the tool writes/removes client config files, lists the ops, and explains the call shape including compatibility aliases. It does not mention potential side effects like overwriting existing entries or requiring specific permissions, but it covers the main behaviors.
Agents need to know what a tool does to the world before 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 clear sections for ops, call shape, and compatibility. It is concise despite the detail, using bullets and examples effectively. 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 complexity (multiple ops, various clients, call shape flexibility), the description is thorough. It explains the output of status(), the actions of configure/remove, and the compatibility alias. The presence of an output schema means return values need not be detailed, and the description covers the essential usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description compensates by explaining the op enum values and their expected parameters (e.g., 'client' is one of the ids from status()). It also explains the canonical call shape and flat parameters alias. However, it does not detail the 'params' object structure beyond the client field or explain session_id.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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: configuring AI clients to use the MCP server by writing/removing client config files. It lists supported clients and differentiates from sibling tools which focus on scenes, resources, sessions, 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 provides clear context for when to use the tool (to set up AI clients) and details the ops (status, configure, remove) with explanations of each. It does not explicitly state when not to use it or name alternative tools, but the scope is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden of behavioral disclosure. It thoroughly documents that the plugin is disabled/re-enabled on the next frame, that plugin-managed reloads kill the server and drop the WebSocket transport, and that externally launched reloads wait up to 15 seconds and raise PLUGIN_DISCONNECTED on timeout with recovery diagnostics.
Agents need to know what a tool does to the world before 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 brief purpose statement followed by bulleted details for each launch mode. Every sentence provides essential information about behavior, response shapes, and recovery steps, with no wasted words given the operational 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 comprehensively covers the tool's behavior across both plugin-managed and externally launched contexts, including transport drops, session reconnection, timeout errors, and output shapes. Since an output schema exists, detailed return values are optional, but the description goes beyond that by explaining the conditional flows and recovery diagnostics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for the single optional session_id parameter, including its description 'Optional Godot session to target. Empty = active session.' The tool description adds no additional parameter guidance, but per the baseline for high schema coverage, this is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence 'Reload the Godot editor plugin' uses a specific verb and resource, clearly identifying the tool's function. The description further distinguishes it by detailing the reload process and its context-dependent outcomes, setting it apart from sibling tools like editor_manage or session_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 explains when this tool is used (to reload the plugin) and provides explicit follow-up guidance: in plugin-managed mode, reconnect and call session_manage(op='list') to find the new session_id. It does not explicitly state when not to use it or alternative tools for other purposes, but the context is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states the tool is read-only, bounded, and live, and transparently explains that partial component failures are labeled rather than hidden. This goes beyond minimal disclosure and sets accurate expectations for a non-mutating snapshot.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the core purpose and nature, the second enumerates the snapshot components and error handling. Every sentence earns its place, with no wasted words or redundant phrasing.
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 the tool's complexity, the description covers all key aspects: what is returned, the bounded/depth-limited nature, conditional git summary, and failure labeling. An output schema exists, so not explaining return format is acceptable. The description is complete for orienting an agent to the tool's purpose and capabilities.
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?
Both parameters have detailed schema descriptions (100% coverage), so the schema already explains the params. The tool description adds no extra parameter-specific meaning, but given full schema coverage, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly defines the tool as an orientation snapshot for Godot work, listing the exact components it returns (pinned session/project, editor readiness, scene hierarchy, selection, errors/warnings, git summary). This distinguishes it from sibling tools like scene_get_hierarchy or logs_read, which focus on narrower scopes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Orient before Godot work' gives clear usage context as the initial tool to invoke before more specific operations. It does not explicitly name alternatives or exclusions, but the composite snapshot nature implies it serves as a broad overview while siblings provide targeted actions.
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 discloses key behaviors: stop is idempotent and returns was_running=false when not running, extra fields are rejected, session_id must be a sibling, and settings_set persists to project.godot. These go beyond minimal expectations and help the agent understand side effects and edge cases.
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 summary, resource form note, ops list, and call shape section. It is longer than necessary but every sentence adds useful detail; the idempotency and session_id notes are essential for correct invocation.
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 three ops with differing parameter requirements and a generic input schema, the description provides comprehensive per-op semantics, call shape, and behavioral constraints. The presence of an output schema covers return values, so the description does not need to explain them. It is complete for the tool's 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?
Schema description coverage is 0%, so the description must compensate. It explains each op's parameters: stop takes none, settings_get takes a key, settings_set takes key and value, and session_id is separate. The canonical call shape is also defined, making parameter usage unambiguous.
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 lists three operations (stop, settings_get, settings_set) and the resource types (project/info, project/settings). However, the summary line 'Project run/stop' is slightly ambiguous because there is no 'run' op, and the actual scope (stop + settings) is only fully clear after reading the ops list.
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 call-shape guidance (op/params/session_id top-level, no extra params for stop, idempotency) and notes that resource forms are preferred for active-session reads. It does not explicitly differentiate when to use this tool vs siblings like project_run or game_manage for starting a project, but gives clear context for the stop and settings operations.
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 it excels: it discloses idempotency, the wait-for-helper behavior, and provides a detailed breakdown of game_status values including 'not_live', 'no_helper', 'stopped', and 'break' with actionable advice for each. This goes well beyond a basic run command.
Agents need to know what a tool does to the world before 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: a lead sentence, a concise modes list, an idempotency note, and a detailed but necessary explanation of statuses. Every sentence adds value, and the length is justified by the tool's complex runtime states. There is no filler 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?
Given the tool's complexity, the description is remarkably complete. It explains the three modes, idempotent behavior, the check-in wait, all status values, and how to handle failures. The output schema exists, and the description fully covers the return fields, making it self-sufficient for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes all four parameters with 100% coverage, so the description doesn't need to add much. It does note that 'custom' requires the scene parameter, which aligns with the schema. However, the description adds little beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Run (play) the Godot project from the editor.' It clearly distinguishes from siblings like project_manage by focusing on playback, and it elaborates with three distinct modes, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context, including idempotent behavior and an explicit alternative: 'To switch scenes, call project_manage(op="stop") first, then project_run again.' It also recommends polling editor_state for late transitions. While it doesn't explicitly state when not to use the tool, it offers practical guidance for common scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosure. It explicitly discloses that the tool overwrites existing files, triggers a filesystem scan, and changes the cleanup.rm listing depending on new vs. overwrite—details that materially affect how an agent invokes it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight, front-loaded sentences deliver the purpose and key behavioral details without filler. Every clause earns its place: creation, overwrite, filesystem scan, and the cleanup.rm distinction.
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 creation, overwrite behavior, filesystem scan, and sidecar details—everything an agent needs to safely execute. With full schema coverage and an output schema present, no critical information is missing for a file-creation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline applies. The description adds context about overwriting tied to 'path' but doesn't extend beyond the schema's own parameter descriptions; it repeats content semantics already 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 'Create a new GDScript source file (.gd)'—a specific verb+resource that clearly states the tool's function. It differentiates from siblings like script_patch and script_attach by focusing on new file creation and the .gd file type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use the tool (creating new scripts) and notes overwrite behavior, but it doesn't explicitly name alternatives or state when not to use it. Sibling tools like script_patch are implied for editing, but no direct comparison is made.
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 the full burden. It discloses critical behavioral traits: exact byte matching, whitespace sensitivity, failure on multiple/zero matches, filesystem scan trigger, and lack of Ctrl+Z undo. This gives a comprehensive risk profile 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 compact: six short sentences, each carrying distinct information, with the core definition first. No padding 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?
Even without annotations, the description covers purpose, failure behavior, side effects, and undo limitations. An output schema exists, so return values are presumably documented elsewhere. For a 5-parameter tool, this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds some value by tying replace_all to failure behavior and old_text to exact matching, but these are also implied in the schema descriptions. No substantial additional parameter semantics 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 'Anchor-based string-replace edit on a .gd file', clearly stating the verb (edit via string replacement) and resource (.gd file). It distinguishes from siblings like script_create and script_attach by focusing on patching existing file content, and further details exact-match semantics.
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: it is for exact text replacement within a script, with explicit failure modes and caveats. It does not explicitly name alternative tools or state when not to use it, but the behavior is unambiguous enough for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and reveals important behaviors like build_layout validating before mutating, the anchor_preset Control requirement, and the theme_override_constants path syntax. It does not describe return values or error handling, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is organized with a short intro, bullet-point operations, and a canonical call shape. Every line adds value, and the length is justified by the tool's multi-operation nature.
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 four distinct operations and non-trivial constraints, the description is highly complete, covering edge cases like CanvasLayer nesting and theme property syntax. It does not explicitly mention error behavior, but the presence of an output schema may mitigate that.
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% and the schema only provides a generic op/params wrapper. The description fully compensates by documenting each operation's parameters, including enum values for preset and resize_mode, and the detailed build_layout spec tree. This is essential for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 'UI / Control authoring' and lists four distinct operations with specific verbs and targets (set_anchor_preset, set_text, build_layout, draw_recipe), clearly distinguishing the tool from sibling node/scene/theme 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 clear contextual guidance per operation, such as 'CanvasLayer is not a Control' and where theme constants should be placed. However, it does not explicitly compare against sibling tools or 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description takes full responsibility for behavioral disclosure, and it delivers by explaining error codes for game_eval, the await focus behavior, return counts for logs_clear, and the replacement semantics of selection_set. It could add a bit more about side effects or prerequisites, but overall it is very 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 lengthy but well structured with a summary, resource forms, and bullet-pointed ops, with every line containing actionable information. It is front-loaded with the purpose and avoids unnecessary verbosity.
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?
It covers all seven ops, their parameters, return values, error handling, and call-shape variations, and the presence of an output schema means return values don't need over-explanation. The description leaves little room for ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no property descriptions, but the description thoroughly documents each op's parameters within the op listings, including the canonical call shape and flat-parameter compatibility alias. This fully compensates for the schema gap and gives the agent clear parameter 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 a clear summary of covered operations and then lists seven specific ops with their purposes, making it easy to understand what the tool does. It distinctly covers editor state, selection, performance monitoring, quit, log clearing, and game eval, setting it apart from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'Resource forms (prefer for active-session reads)' and describes each op's intended scenario, such as passing monitor names to filter and opting into debugger errors. Though it doesn't explicitly compare to sibling tools, the context is clear enough to determine when to use each operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behaviors: assign is 'Undoable', get_info is 'Read-only', physics_shape_autofit 'Auto-creates the concrete Shape subclass if needed', and search is 'Paginated'. It also explains the canonical call shape and compatibility alias. However, it omits failure modes or permission requirements, so not a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but efficiently structured as a bulleted op list with inline parameter details. Every operation earns its place given the tool's polymorphic nature. The summary line and 'Canonical call shape' note are valuable 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?
Despite the complexity (10 ops, many parameters), the description covers each operation's purpose, parameters, and key edge cases (e.g., autofit candidates in error.data.candidates, curve_created flag). It includes an output schema (though not shown) and canonical call format, making it sufficiently complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a generic 'params' object with no field details, so the description is the only source of parameter semantics. It meticulously documents each op's parameters, defaults, enums (e.g., fill: 'linear | radial | square', noise types, presets, shape_type short forms). This fully compensates for the 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a clear verb+resource statement: 'Resource (asset) search, inspection, assignment, and creation.' It then lists 10 distinct operations, each with a specific verb and scope. This clearly distinguishes it from sibling management 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 clear context for usage: 'Covers generic Resource subclasses plus specialized authoring' and specifically notes 'For specific families (Curve, Environment, etc.) prefer the dedicated ops.' This gives guidance on choosing internal ops, though it does not explicitly exclude external sibling tools, making it one point short of explicit when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavior: it explains the in-memory state preservation, the destructive effect of force_reload, the response timing ('sent only after the editor has actually switched'), and the difference between timeout and not_waited scenarios. This exceeds typical transparency expectations.
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 moderately long but every sentence serves a purpose. It is structured logically: first the core function, then conditional behaviors, then response semantics. No redundant or filler content. It could be slightly tighter, but given the complexity of the behavior, it is well-organized.
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 an output schema, the description provides necessary context on response fields (switched, settle) that are critical for safe follow-up writes. It covers edge cases (already open, timeout, synchronous contexts) and directs the user to re-check editor_state when needed. This is complete for 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?
The input schema already covers 100% of parameters, but the description adds meaningful context beyond the schema. It explains force_reload's destructive nature and the subtle behavior when path is already open, which the schema does not convey. However, session_id is not further elaborated beyond the schema's own description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb and resource: 'Open an existing scene file (.tscn) in the editor.' It distinguishes from sibling tools by focusing on the opening action and including details like force_reload and response semantics that are unique to this tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: explains no-op behavior when the scene is already open, explains when to use force_reload, and describes how to handle responses in synchronous contexts. It does not explicitly name alternative tools but gives practical guidance on when to re-check editor_state, which implies when to use that tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It discloses key behaviors: list filters editor connections by default and can surface them with include_editor, and connect/disconnect are undoable. It also explains the editor_connection_count field to signal hidden connections. Some behavioral aspects (e.g., error handling, persistence) are not covered, but the disclosed details are substantive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a one-line purpose, a bullet list of operations, and a concise note on call shape. Every sentence adds value, and the format is scannable and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a multi-operation tool with a generic schema, the description is remarkably complete: it covers all three operations, their parameters, default behavior, undoability, and the result field editor_connection_count. The presence of an output schema (per context signals) helps, but the description alone already provides sufficient operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must fully compensate. It does so by documenting each operation's parameters: list(path, include_editor=False), connect(path, signal, target, method), and disconnect(path, signal, target, method). It also explains the canonical envelope shape with 'op' and 'params'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Signals (Godot's event/observer mechanism) — list, connect, disconnect.' This is a specific verb+resource combination that distinguishes it from sibling tools like node_manage or scene_manage. The three operations are enumerated with clear verbs.
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 contextual guidance on how to use each operation, including canonical call shape and compatibility alias. It does not explicitly state when to use this tool versus alternatives, but the focused scope and op-level details make the intended usage clear.
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 important behaviors such as cascading down a Control subtree, clearing when empty theme_path is given, and the acceptance of a session_id. It also notes a compatibility alias for flat parameters, providing context beyond the raw schema. However, it does not mention error handling or side effects of operations like overwriting existing files, though the 'overwrite' parameter mitigates this.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a brief introduction followed by a bulleted list of operations. It is dense with information but well-organized, making it easy for an agent to quickly parse the different op shapes. Every sentence adds value, and the canonical call shape at the end clarifies the expected format without unnecessary repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex multi-operation tool with no annotations, the description is remarkably complete. It covers all operations, their parameters, behavior, and the overall wrapping structure. The existence of an output schema means return values are handled separately, so the description does not need to explain them. The description is sufficient for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds substantial meaning to the parameters. While the schema only defines 'op' as an enum, 'params' as a generic object, and 'session_id' as a string, the description details the exact structure of params for each operation (e.g., set_color requires theme_path, class_name, name, and value with color formats). This is critical since the schema has 0% coverage of the nested parameters, and the description fully compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that this tool handles 'Theme authoring (Godot's stylesheet-like resource for Controls)' and lists specific operations like create, set_color, apply, etc. This is a specific verb+resource description that distinguishes it from sibling tools like resource_manage or node_manage, which handle other aspects.
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 about when to use this tool (for theme-related operations on Godot Controls) and explains the cascading behavior when assigned via theme_apply. It does not explicitly state when not to use it or name alternative tools, but the specificity of the operations gives enough guidance for an AI to select it for theme management tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It reveals two non-obvious traits: auto-creation of the AnimationPlayer when player_path is unresolved, and that track node paths are relative to the AnimationPlayer's root_node. It doesn't cover error behavior or side effects when overwrite=false, but the disclosed behaviors are significant and useful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each earning its place: creation purpose, workflow follow-up, and auto-creation detail. It is front-loaded and free of filler, making it easy to parse quickly.
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 a complete input schema and output schema, the description covers all essential context: where the clip is created, how to proceed with tracks, path handling subtleties, and auto-creation behavior. No critical behavioral or contextual gaps remain.
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 meaning beyond the schema by explaining auto-creation for player_path and clarifying that node paths are relative to root_node, which affects how parameters like player_path and name are interpreted. This contextual info is not present in the schema, so the description adds value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a specific verb+resource+location: 'Create a new Animation clip inside an AnimationPlayer's default library.' It clearly distinguishes from sibling tools like animation_manage by explicitly directing track-manipulation follow-up to that tool, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit workflow guidance: after creating the clip, add tracks via animation_manage ops. It also gives an alternative ('see animation_manage preset ops for a forgiving target_path') and explains auto-creation behavior when player_path doesn't resolve, covering both when and how to use the 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 full burden and exceeds it: it discloses undo behavior for make_current, class-aware property handling, enum-by-name coercion, Vector2 dict coercion for zoom/offset, empty-path resolution to active camera, and op-specific semantics like 'Pass only the edges to change' and 'Reparent camera under target'. This rich behavioral detail compensates well for missing annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a one-line summary, a bulleted list of operations with code-formatted signatures, and a final note on call shape compatibility. It is longer than average but every section serves a purpose, and the formatting enhances scanability. Slight redundancy (e.g., repeating 'Camera2D/Camera3D' multiple times) prevents a 5.
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 a multi-op dispatcher with a generic schema, making completeness heavily reliant on the description. The description covers all 8 operations, their parameters, defaults, behavioral nuances, canonical call shape, and alias handling. It provides enough context for an agent to select and invoke the correct op, even without seeing an output schema.
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%, but the description fully defines every parameter within each op signature, including defaults (e.g., name="Camera", smoothing_speed=5.0) and value constraints (e.g., drag_margins fractions [0,1]). It explains property categories for configure and optional edge arguments for set_limits_2d, making the tool usable without needing to inspect 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 scope as 'Camera2D / Camera3D authoring' and enumerates specific operations (create, configure, set_limits_2d, etc.), making the purpose unambiguous. It distinguishes itself from sibling tools like node_set_property by focusing exclusively on camera behaviors, and the verb-first op names (create, configure, follow_2d) clearly indicate actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when NOT to use this tool, stating transforms (position, rotation, scale) should be set via node_set_property instead. It also indirectly establishes usage context by enumerating camera-specific operations, but does not offer broader 'when to use this vs. other tools' advice beyond that 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 provided, the description fully carries the burden. It discloses a side effect (refreshes session readiness cache), explains the semantic distinction between is_playing and game_status.status, and details the unusual 'break' status with a required follow-up action. This goes far beyond a simple 'get state'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every sentence earns its place: it starts with the core function, then explains access forms, side effects, recovery use, and response field semantics. The structure is logical, with clear paragraphs and front-loaded key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity—including a side effect, nuanced response fields, and a special 'break' status—the description covers all essential aspects. An output schema exists, so the description need not list every return field, but it explains the critical ones and their interpretation, making the tool fully contextualized.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single parameter session_id is fully described in the schema ('Optional Godot session to target. Empty = active session.'). The description reinforces this with 'prefer for active-session reads' but adds no new parameter-level detail beyond what the schema already provides, so a 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 'Get current Godot editor state' and enumerates specific components: version, readiness, open scene, play state. It also differentiates from the sibling editor_manage by noting it's the same handler via an alternative access form, which helps clarify its scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: it says 'prefer for active-session reads' for the resource form, notes the alternative editor_manage(op='state') for clients preferring a single tool, and gives a concrete recovery scenario after an EDITOR_NOT_READY rejection. This clearly indicates when and how to use the 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 provided, the description carries the full burden and excels. It discloses the default 50-150 entry response, the behavior of `total_count` vs `count`, the `unknown_fields` array for missing names, inclusion of null-valued properties, and serialization details for scripts. This is exceptionally transparent about edge cases and response semantics.
Agents need to know what a tool does to the world before 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 systematically covers resource form, default behavior, filtering, and null handling. Every sentence provides distinct, useful information without repetition or fluff. Though longer than minimal examples, the density and logical organization make it appropriately concise for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, no annotations, and an output schema (not shown), the description thoroughly covers invocation context, response semantics, and special cases. It explains exactly what to expect in typical and edge-case responses, making it complete for an agent to select and call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds meaningful context beyond the schema by explaining that `fields` provides a 'large response-size cut' and that `count` can only be reduced via `fields` while `total_count` remains the full set. It also clarifies that requested names not found appear in `unknown_fields`, which aids parameter interpretation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear verb+resource statement: 'Get properties of a node.' It further specifies a resource form (godot://node/{path}/properties) and contrasts with sibling tools like node_set_property by making the read-only nature explicit. This unambiguously distinguishes the tool from write/modify tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides strong usage context, noting the resource form is 'prefer for active-session reads' and explaining when to use the `fields` parameter to reduce response size. However, it does not explicitly name alternative tools or state when not to use this tool, so it falls just short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses key behaviors: delete is undoable, cannot delete/duplicate scene root, rename has collision and character restrictions, reparent cannot move into descendants, and scene_file guard triggers EDITED_SCENE_MISMATCH. It also explains the canonical call shape and compatibility alias, offering rich behavioral context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long due to nine ops, but it is organized with headers, bullet lists, and a clear canonical call shape. Every sentence adds operational value—no filler. The structure makes it easy to scan and parse.
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?
Addresses all ops, constraints, error conditions, read vs write behavior, resource forms, and call syntax. An output schema exists (likely for op results) but the description still covers return info for get_children and get_groups. For a complex multi-op tool with no annotations, this is comprehensively complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must define parameters. It lists the argument signature for every op (e.g., 'delete(path, scene_file="")') and explains the scene_file guard. However, it does not describe session_id's purpose beyond being 'top-level', and type details for path/index are inferred from naming rather than explicitly stated. This is a minor gap given the complexity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Node tree manipulation' and enumerates specific verbs (delete, duplicate, rename, reorder, reparent, groups) plus hierarchy reads. This clearly distinguishes it from sibling tools like node_create (creation), node_set_property (property changes), and node_find (search).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states a preference for resource forms during active-session reads and lists all ops explicitly. It does not explicitly contrast with sibling tools (e.g., 'use node_create for new nodes'), but the op list clearly implies the scope. The scene_file guard guidance adds usage context. A minor gap is lack of explicit when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so thoroughly. Each operation is explicitly marked as 'Read-only — does not modify any resource or project file,' and for the image op it adds 'reads the texture directly from the resource without any UI interaction.' It also documents error codes passed through from the GDScript handler, covering potential failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured with bullet points, code blocks, and separate sections for each op. Some repetition exists (similar error code lists), but the organization makes it easy to scan. It earns its length given the multi-op complexity, but a tighter format could reduce 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?
Despite the generic schema and lack of annotations, the description is fully self-contained. It provides return formats for both ops, detailed parameter semantics, error code meanings, and a workflow recommendation. The presence of an output schema does not reduce the need for this elaboration, as the schema only describes the wrapper, not the op-specific results.
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's params are a generic object with 0% description coverage, so the description must compensate and does so excellently. It documents each param for both ops: tileset_path (required, res:// path), source_id (required, ≥0), and max_size (optional, default 0, with scaling semantics). Types, defaults, and constraints are all explicitly defined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 'TileSet management — atlas inspection tools' and enumerates two specific operations with verb-object-resource structure (e.g., 'Return all occupied atlas tile positions' and 'Return the atlas sprite-sheet texture'). It distinguishes itself from sibling tools like tilemap_manage by scoping to TileSet atlas inspection and explicitly notes read-only 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 provides explicit guidance for one key scenario: 'To visually inspect what tiles look like, use tileset_get_atlas_image instead of editor screenshots.' It also notes that the operations are read-only and require no UI interaction, which implies safe usage. However, it does not explicitly mention when to avoid using this tool or contrast with all alternative tools, leaving some room for ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond basic operation summaries by disclosing important behavioral details: 'delete' is marked Undoable, 'play' and 'stop' are clearly noted as 'Editor preview. Not saved with scene.', and 'validate' reports 'broken_count + per-track issues' as a return value. It also explains the preset target_path resolution logic and the canonical call shape. With no annotations provided, the description fully carries the transparency burden and does so thoroughly.
Agents need to know what a tool does to the world before 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 structured efficiently: a one-line summary followed by a flat list of operations, each with a one-line signature and a brief explanation. It front-loads the purpose and uses consistent formatting. Every sentence adds value—no filler or redundancy. The detailed parameter notes are compact and directly relevant to using the tool.
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 high complexity (15 operations, many parameters, multiple presets), the description is remarkably complete. It covers every operation's purpose, parameter semantics, return values (for validate, list, get), side effects (undoable, not saved), and call-shape conventions. It also explains edge cases like target_path relative/absolute conversion. The presence of an output schema (not shown) means return values don't need to be fully separately explained, but the description still provides useful output hints.
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, leaving 0% parameter description coverage. The description compensates entirely by documenting every operation's parameters in detail, including types and examples (e.g., 'keyframes: [{time, value, transition?}, ...]', 'interpolation: linear|nearest|cubic'). It also explains the format for track paths and the high-level tween specs, making the tool fully usable from the description alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The opening line 'AnimationPlayer authoring (player, tracks, autoplay, presets, playback)' clearly states the tool's purpose and scope. The extensive list of ops with specific verbs (create, delete, validate, add_track, set_autoplay, play, stop, list, get, create_simple, presets) leaves no ambiguity about what the tool does. It also implicitly distinguishes from sibling tools like animation_create by focusing on authoring an AnimationPlayer rather than creating animation resources.
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 op is accompanied by a concise description of what it does (e.g., 'Create an AnimationPlayer with empty default library', 'Delete an animation clip... Undoable'), giving clear context for when to use each operation. However, the description does not explicitly contrast this tool with sibling tools (e.g., animation_create) or state when not to use it, so it lacks explicit exclusions and alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden of behavioral disclosure. It discloses that autoloads are persisted to project.godot, that singleton=True enables global access by name, that remove() does not delete the underlying file, and describes the canonical call shape. These side effects and operational details are clearly communicated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately long but extremely well-structured with a clear opening definition, a bulleted list of operations, and a final note on call shape. Every sentence serves a purpose, and the format makes it easy for an AI agent to parse. It is concise relative to the complexity of a multiplexed operation tool.
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 fully covers the tool's scope: it explains the concept of autoloads, lists all operations with their parameters, notes persistence behavior, and clarifies the calling convention. Given that an output schema is present, the description need not explain return values. No critical gaps remain for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage and only shows op, params, and session_id with no parameter documentation. The description compensates by listing the exact parameters for each operation: add(name, path, singleton=True), remove(name), and list() with no args. It also explains that flat op parameters are accepted as a compatibility alias, adding meaning entirely beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'Autoload (global singleton) management' and provides a concise overview of autoloads. It lists the specific operations (list, add, remove) with signatures, which uniquely identifies the tool's function and distinguishes it from sibling tools like scene_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 implies the tool is for managing autoloads by defining what autoloads are and how they behave. It gives clear context for when to use the tool (to register, list, or unregister autoloads), but does not explicitly state when not to use it or name alternative tools for other resource types. The lack of exclusions keeps it at 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, the description fully carries the burden of disclosure. It details persistence to project.godot, idempotency, removal of actions not loaded in live InputMap, validation of deadzone with VALUE_OUT_OF_RANGE, and clarifies that deadzone is not a key-repeat delay. It also explains the canonical call shape and flat parameter alias.
Agents need to know what a tool does to the world before 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 well-structured with a clear list of operations and nested parameter details. It uses bullet points, code formatting, and concise explanations. Every sentence adds value, and the structure makes it easy to scan for specific 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 tool's complexity, the description covers all necessary aspects: all six operations, their parameters, return behavior (is_builtin field), error conditions, and persistence details. The output schema exists and the description complements it by adding behavioral context that structured data cannot convey.
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 fully document parameters. It does so extensively: for each op, it lists parameter meanings, types, formats (e.g., keycode as name string not integer), valid ranges (deadzone 0.0-1.0), and specific mappings (mouse buttons, JoyButton indices). This far exceeds mere schema information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool manages InputMap actions and bindings (keyboard, mouse, gamepad) and persists to project.godot. It lists specific operations (list, add_action, bind_event, etc.), distinguishing it from sibling tools like resource_manage or node_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 provides context like 'prefer for active-session reads' for the resource form and explains idempotency for ensure_* operations. However, it does not explicitly mention when to use this tool versus an alternative, though the specificity of InputMap operations makes the intended use 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 carries full burden. It discloses side effects (saving .tres, assigning materials, undo for apply_to_node), error conditions (overwrite=False errors if file exists), and parameter coercion (enum names to values, texture paths). It also explains the canonical call shape and compatibility alias, giving a complete behavioral model.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is long, it is meticulously structured with a summary followed by a bullet list of ops, each concisely specifying signature and semantics. Every sentence adds value—no fluff. The canonical call shape at the end is a useful structural aid. Front-loaded with a clear definition.
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 (8 ops) and the sparse schema, the description is exceptionally complete. It covers all ops, their parameters, side effects, resource-form usage, and error handling. Since an output schema exists, return values need not be explained, and the description focuses on what the agent needs 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 degenerate (only op, params, session_id) with 0% coverage of actual parameters. The description fully compensates by listing each op's parameters with types, defaults, and allowed values (e.g., type: 'standard' | 'orm' | 'canvas_item' | 'shader', slots: 'override' | 'surface_<N>' | 'canvas' | 'process'). It even clarifies how values like colors/vectors are passed and that texture properties accept res:// paths.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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: 'Material authoring (StandardMaterial3D, ORMMaterial3D, ShaderMaterial, CanvasItemMaterial)' and enumerates specific ops (create, set_param, assign, etc.). It distinguishes from siblings by focusing exclusively on materials and their properties, not general resources or scenes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance on when to use the resource form ('godot://materials — prefer for active-session reads') and details each op's parameters and behavior. However, it doesn't explicitly state when NOT to use this tool in favor of a sibling (e.g., resource_manage), so the alternatives are implied rather than directly contrasted.
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 explains that write ops create nodes and sub-resources in a single undo action, auto-creates ProcessMaterial and QuadMesh, notes restart is not undoable, reports INVALID_PARAMS for unknown overrides, and specifies Vector3 requirements for GPU gravity even in 2D. These details exceed standard 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?
Although long, the description is well-structured into a concise op list with sub-bullets and contains no filler. Each sentence adds essential usage information, and the front-loaded overview prepares the reader for the detailed operation specifications.
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 ops, presets, override routing, error handling, and response reporting for a complex tool. It addresses edge cases like GPU gravity in 2D and unknown override keys, making it comprehensive enough for reliable invocation without additional documentation.
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 has only op/params/session_id with 0% description coverage. The description compensates completely by documenting every operation's parameters, including the type enum for create, property lists for set_main and set_process, draw pass parameters, and the overrides structure for apply_preset, plus the canonical call shape.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 manages particle systems (GPUParticles2D/3D, CPUParticles2D/3D) and enumerates specific operations (create, set_main, set_process, set_draw_pass, restart, get, apply_preset), making its purpose and scope explicit and distinct from generic node or scene management tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this tool handles particle systems and includes operation-level usage details, such as the single undo action for write ops and runtime-only restart. However, it does not explicitly name alternative tools or state when not to use this tool, relying on the scope stated in the first line.
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 explains that create 'Create a new .tscn with the given root and open it', save_as 'Save the currently edited scene to a new file path', and get_roots 'List scenes currently open in the editor; flag the edited one.' It also notes default behavior for root_name. However, it omits details about whether create overwrites existing files or how errors are surfaced, which is a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise yet comprehensive. It uses a bulleted list for operations with signature and one-sentence explanation each, plus a canonical call shape line. Every sentence adds value, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a multi-operation tool, the description covers all operations, parameters, defaults, and the call shape. It also provides an alternative resource-based approach for reads. Given the output schema exists and the description is thorough, the context is 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?
Schema coverage is 0%, but the description provides complete parameter information for each operation: 'create(path, root_type="Node3D", root_name="")', 'save_as(path)', and 'get_roots()'. It even explains the root_name default ('defaults to filename basename when empty'). 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 'Scene authoring (create, save_as, list open roots)' which clearly states the tool's scope and operations. It enumerates specific verbs and resources for each operation (e.g., 'create(path, root_type="Node3D", root_name="")'), and the mention of resource URIs for reads distinguishes this authoring tool from read-oriented alternatives like scene_get_hierarchy.
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 guidance is given: 'Resource form: godot://scene/current and godot://scene/hierarchy — prefer for active-session reads.' This tells the agent when to use an alternative resource-based approach instead of this tool. Each operation's description and parameter list further clarifies when to invoke create, save_as, or get_roots.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden of disclosing behavioral traits. It reveals that all write ops are undoable, explains the critical source-ID remapping caveat for specialized .tres files, details the canonical call shape and flat-parameter alias, and lists return values for each op. This is exceptionally transparent and goes beyond what annotations 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized: a one-line summary, a brief scope statement, an important warning box, and a bulleted list of operations with parameters and returns. Despite being long, every section earns its place with critical information, and the structure makes it easy to scan. No fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (four operations, a tricky source-ID remapping rule, and an alias call shape), the description is complete. It explains all operations, parameters, returns, and edge cases. The existence of an output schema does not make the description redundant because the description also details each operation's specific return structure, which is more granular than a generic schema.
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: only op, params (free-form object), and session_id with 0% parameter description coverage. The description compensates comprehensively by defining each operation's parameters (path, source_id, atlas_col, atlas_row, map_x, map_y) and their meanings, plus return shapes. It adds substantial semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'TileMap / TileMapLayer authoring (set tiles, fill rects, clear, read cells).' It clearly distinguishes itself from siblings like tileset_manage by targeting TileMapLayer nodes and enumerates four concrete operations. This is unambiguous and fully differentiates the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: operations target TileMapLayer nodes in the currently edited scene by scene-relative path, and all write ops are undoable via EditorUndoRedoManager. It implicitly tells when to use the tool (for authoring tilemaps) but does not explicitly name alternatives or exclusion conditions, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It thoroughly explains sequential execution, stop-on-first-error, default undo behavior, atomic-on-failure semantics, and that rollback only applies to sub-commands modifying the currently edited scene. This is strong transparency for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-structured and front-loaded. However, it references "The example below" when no example is actually present, which is a minor structural flaw. Everything else earns its place and is appropriately sized for a complex batch tool.
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 lack of annotations, the description is remarkably complete. It covers composition semantics, failure atomicity, undo behavior, path conventions, sub-command constraints, and even addresses session targeting indirectly through the schema. The output schema handles return-value expectations, so no additional return documentation is needed.
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 schema's commands parameter is only loosely typed as an array of objects with additionalProperties true. The description adds critical meaning by specifying the exact item structure, requiring plugin command names, giving examples, and explaining scene path conventions (relative to the edited scene root, not /root/...).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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: "Execute a list of editor sub-commands in order, stopping on first error." It clearly distinguishes this batch tool from the individual sibling tools (node_create, node_set_property, etc.) by focusing on composing multiple sub-commands in a single call.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: "Use this to compose multi-step edits (create node + set property + attach script) into a single tool call." It also gives a when-not rule by stating batch_execute itself cannot be a sub-command and clarifies that plugin command names, not MCP tool names, must be used.
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, but the description compensates with extensive behavioral detail: the EDITOR_NOT_READY error shape, stale_frame flag for backgrounded game windows, GAME_HELPER_TIMEOUT meaning, and the guarantee that AABB metadata is always returned. It also discloses that include_image=True yields an MCP ImageContent block.
Agents need to know what a tool does to the world before 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 tightly packed with essential information, structured with a lead paragraph and a bullet-like source list. No filler sentences; each clause addresses a distinct scenario or parameter behavior, and the most important usage guidance 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 complexity (four sources, nine parameters, no annotations, no output schema), the description covers error states, metadata, source fallbacks, and parameter interplay, providing an agent with enough context to select and invoke the tool correctly. The only minor omission is an explicit description of the success response shape beyond the optional image block, but AABB metadata is covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers all nine parameters, so the description's extra value is selective but meaningful. It enriches source semantics with per-source behavior and caveats (e.g., viewport_2d incompatibility with other parameters), clarifies view_target's camera reframing, and specifies the format for include_image. Some parameters like fov and azimuth receive no additional description, so a 4 rather than 5 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 opens with a specific verb-resource statement—'Capture a screenshot of the Godot editor viewport or running game'—and then enumerates four distinct sources. This clearly distinguishes the tool's purpose from sibling tools that manage scenes, projects, or cameras. No other sibling appears to provide screenshot functionality.
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: viewport_2d is recommended for 2D scenes, viewport for 3D, cinematic for active Camera3D, and game for a running project. It also gives corrective advice for error states, e.g., 'switch to cinematic if the scene has a Camera3D, or open a scene with 3D content.'
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 and delivers richly. It discloses buffer sizes, retention across runs, run_id semantics, cursor mechanics (superseding offset), truncation, boot-time parse errors never being captured, editor_errors_hint behavior, source filtering, and details on include_details. This level of disclosure 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but justified for the tool's complexity. It is front-loaded with the core purpose and structured by source types and tail patterns. Every section earns its place, though some repetition (e.g., run_id explanations) could be tightened. Still, it remains organized and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description goes beyond it by detailing return fields (run_id, current_run_id, game_status, truncated, next_cursor, editor_errors_count, etc.), explaining edge cases (stale_run_id, boot-time errors), and specifying behavior for prior runs. For a tool with this many parameters and sources, the 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?
Although schema coverage is 100%, the description adds substantial meaning beyond the schema. It explains each source's semantics, since_run_id retention behavior, since_cursor working details and precedence, and include_details purpose. The schema only says 'optional' and defaults; the description turns these into practical usage knowledge.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 'Read recent log lines from the Godot editor, plugin, or running game.' This uses a specific verb ('Read'), names the resource ('log lines' from distinct sources), and clarifies scope. The resource form and source breakdown further distinguish it from sibling tools, none of which target log reading.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance, 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 the tail pattern (poll with offset, use run_id/cursor) and when to prefer the resource form ('prefer for active-session reads'). This goes beyond vague context to actionable selection criteria.
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 carries the full burden. It discloses the 300s budget, timeout return code TEST_RUN_TIMEOUT, partial summary behavior, the risk of a 20s+ single test blocking the main thread, and the scene_warning mechanism. This far exceeds minimal disclosure and gives the agent critical context about side effects and failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured in three paragraphs, each covering a distinct aspect: execution, timeout/safety, and response details. The first sentence immediately states purpose, and every sentence contributes unique information about behavior or constraints. The length is justified by the tool's complexity, and there is no redundant 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 description covers execution model, timeout behavior, partial results, session safety, batch_execute exclusion, main scene dependency, and response content. Given that an output schema exists, the description need not enumerate fields, but it explains the essential context for correct usage, making it fully complete for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description enhances parameter understanding by explaining that verbose=True yields per-test duration_ms, which is not in the schema, and by tying the suite parameter to the discovery of test_*.gd files. It also adds context about the response containing edited_scene, which is not explicitly stated 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: 'Run GDScript test suites inside the connected Godot editor.' It then details the discovery and execution of test_*.gd files and test_* methods, clearly distinguishing the tool from test_manage by referencing it for retrieving partial results.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states 'Not allowed inside batch_execute' and advises opening the main scene with scene_open when a scene_warning appears. It also points to test_manage(op="results_get") as the alternative for obtaining full partial results, providing clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses side effects: single-file vs full scan updates, skipped_non_imported behavior, single-flight scan, and the data.cleanup.rm field for new files. It details what happens with non-imported resources.
Agents need to know what a tool does to the world before 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 multi-op tool description is long but every sentence earns its place. It uses a clear bullet structure, front-loads the purpose, and avoids repeating schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with five ops and no annotations, the description is complete: it covers all behaviors, parameters, return fields, and caveats. It even includes the canonical call shape and compatibility alias.
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%, but the description thoroughly documents each op's parameters with types and defaults (e.g., search(name='', type='', path='', offset=0, limit=100)) and explains the params container. 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 'Project filesystem access via the Godot editor's EditorFileSystem' and enumerates five specific operations. It distinguishes itself from sibling tools by focusing on filesystem operations rather than scene, script, or resource 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?
Provides explicit when-to-use guidance for each op, including alternatives like 'Use script_patch/script_create to save a script and receive fresh diagnostics' for reimport, and instructions for when to call scan after adding class_name scripts.
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 bears the transparency burden and does so well. It discloses specific behavioral details such as '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 the frame-timing semantics of input_sequence. It also clarifies that ops are executed through the EngineDebugger bridge, setting accurate 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 well-structured: a concise summary, a prerequisite line, then a bulleted list of ops with signatures and short explanations. It is long but every sentence provides necessary operational detail; there is no fluff. The canonical call shape at the end is a useful practical touch.
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 (nine ops), the presence of an output schema, and no annotations, the description is remarkably complete. It covers prerequisites, op semantics, timing constraints, exclusions, and input formats. It even clarifies a subtle edge case and provides a canonical invocation example. This gives an agent everything needed to select and invoke the correct op.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must (and does) provide comprehensive parameter semantics. Each op includes a signature with default values, accepted types, and special cases—for example, root_path 'accepts an absolute runtime path or a scene-relative path,' and input_mouse's position can be an object or array with explicit fallback behavior. This adds significant 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 opening line 'Runtime game inspection and input simulation' clearly states the tool's function with specific verbs and resource types. The description further distinguishes it from static editing siblings by emphasizing it 'targets the running game process through Godot's EngineDebugger bridge' and enumerates nine distinct runtime operations.
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 prerequisites: 'Start the project first with project_run and poll editor_state until game_capture_ready=true.' It also gives clear alternative guidance for input_sequence: 'Use this instead of separate input_action calls whenever timing matters...' and notes a restriction: 'Cannot run inside batch_execute.' This tells the agent exactly when and how to use the 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 provided, the description fully discloses type coercion behavior for vectors, colors, resources, NodePaths, and arrays, plus error conditions like PROPERTY_NOT_ON_CLASS. It also explains resource clearing and creation via __class__, offering deep 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 densely informative yet well-structured with bullet points for coercion types. Every sentence serves a purpose, and the critical 'verify first' guidance is front-loaded. The length is appropriate for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 params, rich type system, output schema present), the description covers all essential context: property name accuracy, value formats, path semantics, and error mitigation. It leaves no major gaps for an agent to misuse the 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?
Despite 100% schema coverage, the description adds substantial value: it clarifies that path is relative to scene root (not /root), explains how value is coerced per type, and details resource handling. The examples for Camera3D, Sprite2D, and Node3D prevent common mistakes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 that clearly distinguishes this tool from siblings like node_get_properties or node_create. It also details the exact scope (scene paths) and property naming nuances.
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 guidance to verify the property name first via node_get_properties or godot://node/{path}/properties, and warns against guessing. This clearly tells the agent when and how to prepare before using the tool, and provides a direct alternative for checking.
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:

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

Score Badge

Copy to your README.md:

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

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/robertobendi/wazzicode-godot'

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