Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations provide no safety cues (all false), so the description carries the burden. It discloses the prerequisite that an existing AnimationPlayer is required and points to create_animation_player otherwise. However, it does not mention side effects like overwriting animations with the same name, scene saving behavior, or error conditions, which would matter for a mutation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences, front-loaded with the core action and target. The alternative pointer to create_animation_player is valuable and does not add fluff. No wordy or redundant content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has 7 parameters with nested track/keyframe structures, and no output schema. The schema is thorough, and the description gives essential prerequisite context, but it lacks return/error behavior and detailed side-effect information. Minimally adequate for invocation, but not deeply complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all parameters. The description adds only high-level context (tracks, keyframes, existing node) already reflected in schema properties. Baseline 3 is appropriate since no extra parameter syntax or meaning is provided.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description uses a specific verb+resource: 'Add an animation with tracks and keyframes to an existing AnimationPlayer node.' It clearly differentiates from sibling 'create_animation_player' by focusing on adding to an existing node and mentioning the alternative.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use this tool (on existing AnimationPlayer) and when not (to create the player itself) with direct alternative: 'To create the AnimationPlayer itself, use create_animation_player first.' This gives clear usage boundaries.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnlyHint=false and destructiveHint=false, so the mutation nature is clear. The description adds a behavioral detail about defaulting to root when parentNodePath is omitted, but does not disclose other potential side effects (e.g., whether the file is auto-saved, existing node behavior, or prerequisites). This is adequate but not rich.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with no redundancy. It immediately states purpose, gives a useful default, and points to an alternative. Every word earns its place, perfectly concise and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with no output schema, the description covers the essential context: what it does, the default parameter behavior, and a relevant alternative. It could mention return behavior or side effects, but given the moderate complexity and schema richness, it is sufficiently complete for an agent to select and invoke correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, giving a baseline of 3. The description adds meaningful param semantics by explaining the default behavior for parentNodePath when omitted, which is not in the schema. This extra context justifies a score above baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (add a child node) and the resource (a scene file on disk), and distinguishes from a sibling tool by explicitly pointing to instantiate_scene for sub-scene instances. This meets the 'specific verb+resource' criterion and adds distinguishing context.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides a clear alternative usage ('For sub-scene instances, use instantiate_scene') and implies the primary use case (adding nodes to scene files). However, it does not explicitly mention when not to use the tool beyond that one sibling, so it lacks exhaustive exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds little beyond what annotations already state (readOnlyHint=false, destructiveHint=false). It does not disclose whether adding to an existing group is idempotent, whether new groups can be created, or any side effects on the scene.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, straightforward sentence with no fluff or repetition. Every word contributes to the meaning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple mutation tool with good schema coverage, the description is minimally adequate. However, it omits any mention of return values, error behavior, or whether node/group must already exist, which could leave an agent uncertain about expected outcomes.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and all parameters have descriptions, so the schema carries the semantic burden. The tool description adds no parameter-specific detail, which is acceptable given the high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific action ('Add a node to one or more groups in a scene') with a distinct verb and resource. It easily differentiates from sibling tools like remove_from_group, making the purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives such as remove_from_group or add_node. There is no mention of prerequisites or scenarios favoring this operation over others.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnlyHint=false (a mutation operation), but the description adds no behavioral context beyond the simple action. It does not disclose what happens to an existing script on the node, whether the scene file is saved, or any validation requirements. The description is neither misleading nor contradictory, but it is minimally informative.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence, front-loaded with the action and core objects. It contains no redundant information and is appropriately brief for the tool's simplicity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is adequate for a simple tool with fully documented parameters and annotations, but it lacks usage trade-offs, side-effect details, and any error conditions. Given the tool's complexity, this is a minimal but acceptable level of completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with all four parameters (projectPath, scenePath, nodePath, scriptPath) having clear descriptions. The tool description reinforces the role of scriptPath and nodePath ('GDScript file' and 'existing node') but adds no additional meaning beyond what the schema already provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('attach') with a clear resource ('GDScript file') and target ('existing node in a scene'), which distinguishes it from sibling tools like write_script (which writes script content) and add_node (which adds nodes). The meaning is immediately clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use this tool (when you have an existing node and a GDScript file to attach), but it does not explicitly mention alternatives or conditions when not to use it. There is no comparison with related script tools like write_script or validate_script.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations cover read-only/destructive/idempotent flags, and the description adds valuable context about process behavior and performance: it runs in a single Godot process versus separate processes per operation. This goes beyond the annotations, though it does not cover failure semantics or side effects, hence a 4 rather than 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the core purpose, and every sentence earns its place by providing either functional intent or usage context. No filler or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the moderate complexity of a batch operation and the rich schema with nested operation definitions, the description plus schema is sufficient for an agent to understand invocation. It lacks details about error handling or atomicity, but the performance guideline and clear purpose make it nearly complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% for both projectPath and operations, so the structured fields already provide full parameter documentation. The description itself adds no parameter-specific guidance, so the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool executes multiple scene operations in a single Godot process invocation, distinguishing it from individual scene-operation tools. The verb 'execute' plus the resource 'scene operations' makes the purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides an explicit usage guideline: 'Use for 3+ operations,' and justifies it by noting performance gains over separate process spawns. This gives the agent clear criteria for when to choose this tool over individual operations.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already set readOnlyHint=false, destructiveHint=false, idempotentHint=false. The description adds that it returns a serialized result and requires interactive mode. However, it does not disclose that calling arbitrary methods may have unpredictable side effects, relying on the caller's knowledge of the target method.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences long, front-loaded with the core purpose, and every sentence adds value: action, path resolution, result, and prerequisite. No redundant or filler content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 3 parameters and no output schema, the description is sufficiently complete. It covers the action, path resolution, argument handling, return value, and runtime requirement. Minor gaps like error handling are not critical for this tool's complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, with each parameter described. The description reinforces the meaning of nodePath and args but does not add new details beyond the schema, so the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool invokes a method on a live node in a running interactive Godot project, with concrete path examples. It distinguishes itself from sibling tools like set_node_properties or get_node_properties by focusing on method calls rather than property access.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states a prerequisite: the project must be running via run_interactive. It also clarifies that node paths are relative to the current scene. It does not name alternative tools explicitly, but the context is clear enough for an agent to decide when to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare read-only and idempotent. The description adds context about static rendering and the display server requirement, which goes beyond annotations. It does not contradict annotations and adds useful behavioral nuance.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three concise sentences, each serving a purpose: describing the action, distinguishing from alternatives, and stating a key requirement. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the rich schema and annotations, the description covers purpose, usage, and an important environmental requirement. No output schema exists, so return values need not be explained. The tool is simple enough that this description is sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description does not add additional parameter-level semantics beyond what the schema already provides. It mentions 'scene file' and 'viewport' but these are generic and not parameter-specific.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool renders a scene file statically and saves the viewport as a PNG. It explicitly differentiates from live capture alternatives by saying 'No running game needed' and naming game_screenshot and run_and_capture.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit when-to-use vs alternatives: 'For live game captures, use game_screenshot or run_and_capture.' Also notes a prerequisite ('Requires a display server') and that no running game is needed, giving clear context for choosing this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate readOnlyHint=false, so the agent knows this is a write operation, and the description adds that it modifies a file 'on disk'. However, it does not disclose potential side effects like overwriting existing connections or whether the scene must be saved. It provides basic context but not deep behavioral detail.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the main action, and the alternative guidance is appended without redundancy. Every word contributes value, making it highly concise and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having six required parameters and no output schema, the description fully covers the tool's purpose, its static-file context, and the alternative for runtime use. The schema handles parameter details, and the description is sufficient for an agent to understand when and how to invoke the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all six parameters are individually documented with clear descriptions. The tool description itself does not add extra meaning beyond what the schema already provides. Baseline 3 is appropriate because the schema carries the semantic load.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Connect') and specifies the resource ('a signal from one node to a method on another node in a scene file (.tscn) on disk'). It clearly distinguishes the tool from runtime monitoring tools by explicitly naming alternatives, which helps an agent select it correctly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly contrasts this tool with runtime signal monitoring by stating 'For runtime signal monitoring, use subscribe_signals or send_key_sequence.' This gives clear when-to-use and when-not-to-use guidance, going beyond implicit usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate this is a mutating operation (readOnlyHint=false), and the description adds the optional animations behavior. However, it does not disclose deeper behavioral details such as what happens if the node already exists, whether the scene file is saved, or prerequisites like project/scene validity.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences with the primary action front-loaded and no redundant filler. Every clause contributes meaning, including the alternative tool pointer.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given schema coverage and the explicit sibling differentiation, the description is sufficiently complete for a creation tool. It could optionally mention side effects like saving the scene or handling existing nodes, but those are not critical given the schema and annotations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers 100% of parameters, so the baseline is 3. The description adds only minimal extra context by calling animations 'optional pre-configured animations', which aligns with the schema but does not elaborate on structure or defaults beyond what the schema already provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states it creates an AnimationPlayer node in a scene with optional pre-configured animations. It explicitly distinguishes itself from add_animation, which is for adding animations to an existing player.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit guidance on when not to use this tool by directing users to add_animation for existing players. This gives clear contextual differentiation among sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only indicate readOnlyHint=false, destructiveHint=false, and idempotentHint=false, which are not informative. The description adds 'typed properties' but does not disclose key behaviors such as whether an existing file is overwritten, whether the file is created atomically, or what happens on invalid input. There is no mention of return values or error handling.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with no filler. It front-loads the core purpose and avoids redundancy with the annotations or schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With five parameters, a nested object, and no output schema, a one-line description is insufficient. It does not mention side effects (e.g., file overwrite behavior), prerequisites (e.g., valid project path), or return values. The description leaves too much unsaid for a tool of this complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%: every parameter has a description in the input schema. The description does not add additional meaning beyond the schema, so it stays at the baseline of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Create') with a specific resource ('.tres resource file') and adds 'typed properties', which clearly differentiates it from sibling creation tools like create_scene or create_tileset. It is unambiguous about what the tool does.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit when-to-use or alternative guidance is provided, but the description implies usage: use when needing to create a .tres resource file with typed properties. It does not mention exclusions or when not to use it, so it stops at implied usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description does not disclose behavioral details such as whether an existing file at scenePath will be overwritten, what permissions are needed, or what happens if the project path is invalid. Annotations are all false, which only signals that this is not a read-only operation, leaving the agent without clarity on side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is exactly two sentences: the first states the core purpose, and the second clarifies the key parameter and default. It is front-loaded, free of filler, and every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a relatively simple tool with three parameters and a 100% schema description coverage, the description covers the essentials. Its main gap is not explaining return values or what happens if the scene file already exists, but the schema and simplicity keep it mostly complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already covers all parameters, but the description adds a valuable default value for rootNodeType ('Node2D') and examples ('Node2D', 'Node3D', 'Control'), providing semantic detail not present in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Create'), a specific resource ('Godot scene (.tscn) file'), and the scope ('with a root node'). The word 'new' distinguishes it from tools like save_scene or add_node, making its purpose unambiguous relative to siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the primary use case (creating a new scene file) but provides no explicit guidance about when to use this tool versus alternatives like add_node or save_scene. It does not mention exclusions or alternatives, so usage context is inferred rather than stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations provide no safety profile (all flags false), and the description does not disclose side effects, such as whether an existing .tres file will be overwritten, required permissions, or if the project needs to be open. The description only restates the basic creation action without adding behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence with no redundant words. Front-loaded with the verb 'Create' and efficient in conveying the tool's purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has moderate complexity (5 params, nested objects) but the schema provides comprehensive parameter details. The description lacks information about return values or post-creation behavior, but given the rich schema, it is minimally viable.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so parameters are already fully documented. The description adds marginal meaning by mentioning 'atlas sources from texture files', but this is also evident from the schema. Baseline 3 applies since the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the action (Create), the resource type (TileSet resource), and the source (atlas sources from texture files). It distinguishes itself from sibling tools like create_scene or create_resource by specifying the exact resource and purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The purpose implies when to use the tool (when a TileSet with atlas sources is needed), but there is no explicit guidance on when not to use it or comparison to alternatives. The context is clear but not fully articulated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and idempotentHint=true, which the description does not contradict. The description adds valuable context by enumerating the exact categories available, which helps the agent understand the tool's scope. It does not detail edge cases, but for a simple read-only listing tool, this is adequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that immediately states the action and resource, followed by a colon-separated list of categories. Every word earns its place; there is no waste or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple discovery tool with high schema coverage, strong annotations, and no output schema, the description covers the essentials: the action, the resource, and the valid categories. It does not describe return format, but that is easily inferred for a listing tool and is not critical.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% for the single optional parameter, and the schema description already explains the 'category' parameter. The tool description adds meaning by listing the valid category names explicitly, effectively providing an inline enum set, which exceeds the baseline of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb 'List' with a clear resource 'available tools' and specifies the dimension 'by category'. It clearly distinguishes this introspection tool from the many action-oriented sibling tools (e.g., stop_project, export_project) by serving as a discovery/meta tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use the tool: to see what tools exist in a given category. It provides a full list of valid categories, giving context for filtering. However, it does not explicitly state when not to use it or mention alternatives, though no direct alternatives exist.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already provide readOnlyHint=false and destructiveHint=false, so the agent knows this is a mutation that is not destructive. The description adds no additional behavioral context (e.g., whether children are duplicated, whether scene must be loaded). It does not contradict annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, focused sentence that is front-loaded with the primary action. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 5 parameters and no output schema, the description covers the core behavior but leaves gaps: no mention of whether child nodes are duplicated, what happens to connections, or any return value. The schema handles param details, but behavioral expectations are incomplete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, with every parameter having a description. The tool description adds slight context by noting optionality of newName and parentNodePath, but this is already inferable from the schema (those fields are not in required). Baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function with a specific verb ('Duplicate') and resource ('node within a scene'), and distinguishes it from related sibling tools like reparent_node and rename_node by mentioning optional new name or parent.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use this tool (when duplicating a node), but it does not explicitly state when it should not be used or mention alternatives such as reparent_node or rename_node for related operations. Context is clear but not fully developed.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations provide readOnlyHint=false, destructiveHint=false, idempotentHint=false, so no safety context. The description merely says 'modify' without disclosing whether settings are overwritten, whether values are validated, whether the file is flushed, or any side effects. For a mutation tool, this is a significant transparency gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the core purpose, zero waste. The alternative is stated in a second concise sentence.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple two-parameter tool with no output schema, the description covers purpose and one alternative. However, it omits behavioral details like whether existing settings are merged or replaced, and whether changes persist immediately. This leaves the description somewhat incomplete for a mutation tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%: both parameters (settings and projectPath) have clear descriptions, with an example for settings. The description adds category context ('input actions, display, rendering, physics') but no additional syntax or format details beyond the schema, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a clear action: 'Modify project.godot settings' with a specific resource and enumerates categories (input actions, display, rendering, physics). It also explicitly distinguishes from the sibling tool manage_autoloads by directing autoload singletons there, satisfying the differentiation criterion.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives an explicit when-not/alternative: 'For autoload singletons, prefer manage_autoloads.' This tells the agent when not to use this tool and which sibling to use instead, meeting the highest bar for usage guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds valuable context beyond annotations: the expression runs in the context of the current scene and requires the project to be running via run_interactive. It does not discuss error handling or potential side effects of arbitrary expressions, but the annotation bar is low and the added context earns a 4.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is four sentences long, front-loaded with the core purpose, and every sentence earns its place: function, context/examples, use cases, and prerequisite. No fluff or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter tool with annotations covering safety and no output schema, the description is reasonably complete. It covers the purpose, usage context, execution context, and the critical prerequisite of run_interactive. It could mention error behavior or result formatting, but these are not essential for this tool type.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% coverage with clear examples for the expression parameter. The description adds meaning beyond the schema by explaining the execution context (current scene) and the runtime prerequisite, which helps the agent understand how to construct valid expressions. This exceeds the baseline 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool executes an arbitrary GDScript expression at runtime and returns the result, with concrete examples. It distinguishes itself from siblings like call_method (method call) and execute_script (script execution) by focusing on arbitrary expressions evaluated in the current scene context.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear usage context: useful for debugging, querying state, and one-off calculations. It also states the prerequisite that the project must be running via run_interactive, giving a specific when-to-use condition. However, it does not explicitly name alternatives or exclusion cases, so it isn't a full 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations are all false, so the description must convey behavioral traits. It notes the tool executes code in the current scene context and requires run_interactive, but it does not disclose potential side effects, state changes, or failure modes beyond the absence of read-only guarantees. This is adequate but not rich.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with no filler. It front-loads the primary action, adds a clear differentiator, and states a necessary prerequisite, making every word useful.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers purpose, differentiation, and a prerequisite, which is sufficient for basic invocation. However, because arbitrary code execution can have significant side effects and there is no output schema, more detail on expected behavior or caveats would improve completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The tool description itself does not add parameter-level semantics beyond what the schema already provides, such as the example and use of 'return x'.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool executes a multi-line GDScript block at runtime in the current scene context. It also explicitly distinguishes itself from evaluate_expression by mentioning support for variables, loops, and control flow, which separates it from a key sibling tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides a direct comparison to evaluate_expression, indicating this tool is suited for complex scripts requiring variables and control flow. It also states a prerequisite (requires run_interactive), which gives practical usage context, though it doesn't explicitly enumerate all when-not-to-use scenarios.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds no behavioral details beyond the annotations. It does not disclose whether the output file is overwritten, whether the scene must be part of an opened project, or any side effects during export. With annotations present (readOnlyHint=false), the agent knows it is a write operation, but the description offers no additional transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, well-formed sentence that immediately states the tool's purpose. It is concise and free of unnecessary details, earning its place with no redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with full parameter documentation and annotation coverage, the description is minimally sufficient. However, it lacks context about the operation's behavior, such as what nodes become mesh items or overwrite rules, making it incomplete for optimizing agent selection and safe invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 100% description coverage for all parameters, so the schema already explains each parameter fully. The description does not add parameter-level insights beyond what the schema provides, matching the baseline of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function with a specific verb and resource: 'Export a scene as a MeshLibrary resource.' This uniquely identifies the operation and distinguishes it from sibling tools like export_project or create_resource, which have different targets or formats.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided about when to use this tool versus alternatives, nor are any prerequisites or typical use cases mentioned. The description only states the action without contextual cues for selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations are present but all false, providing minimal safety context. The description does not add behavioral details such as whether existing output files are overwritten, whether export presets are validated, or what happens on failure. It therefore adds little beyond the basic purpose.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence that clearly conveys the action and key conditions. No wasted words or redundant repetition of schema information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has moderate complexity with four parameters and no output schema. The description covers the basic action but does not mention important context like output path requirements, preset prerequisites beyond 'configured', or behavior regarding existing files. While adequate for a simple export, it leaves some gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema fully documents all four parameters. The description mentions 'target platform' and 'configured export preset', which loosely align with the preset parameter, but it does not add detailed semantics or usage patterns beyond what the schema already provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Export') and resource ('a Godot project') with clear scope ('for a target platform using a configured export preset'). This distinguishes it from sibling tools like run_project or launch_editor, which serve different purposes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use when needing to build an export artifact, but it does not explicitly contrast with alternatives (e.g., run_project for testing) or state when not to use. The context is clear enough for a straightforward export operation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context: it operates on the live runtime scene tree and includes dynamically spawned nodes, and notes the run_interactive prerequisite. It doesn't describe return format or pagination, but that's not critical beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the primary purpose. The second sentence provides an alternative and a prerequisite. Every sentence earns its place with zero redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple search tool with two optional parameters, the description covers purpose, runtime context, alternative, and prerequisite. There is no output schema, but the return value (matching nodes) is implied. A minor gap is not specifying what information is returned for each match, but overall it's sufficiently complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%: both 'pattern' and 'typeFilter' have clear descriptions, including defaults and subclass behavior via is_class(). The tool description doesn't need to add more, and it only reinforces the parameter usage at a high level. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Search') and resource ('live runtime scene tree'), clearly stating it matches by name pattern and/or type. It also distinguishes from the sibling tool get_scene_tree by explicitly mentioning static .tscn analysis.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives a direct alternative: 'For static .tscn analysis, use get_scene_tree.' It also states a prerequisite: 'Requires run_interactive.' This clearly guides when to use this tool versus alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover readOnly, idempotent, and non-destructive behavior. The description adds valuable behavioral context: 'Slowest verification path' (performance) and 'Requires run_interactive' (prerequisite), which go beyond annotation data.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Every sentence serves a distinct purpose: purpose, usage condition, alternatives, inline capture guidance, and prerequisite. It is concise despite covering multiple aspects, with no filler words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter tool with no output schema, the description is complete: it explains what the tool does, when to use it, alternatives, and a prerequisite. The agent has enough information to select and invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% for the single optional parameter outputPath, so the baseline is 3. The description does not add parameter-level detail beyond what the schema provides, but it doesn't need to.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Capture a screenshot from a running interactive project.' It distinguishes itself from sibling tools by explicitly contrasting with game_state, evaluate_expression, get_runtime_errors, and send_key_sequence for inline captures.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit when-to-use guidance: 'use only when visual appearance itself matters', and names specific alternatives for other cases. It also states a clear prerequisite: 'Requires run_interactive.'

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Adds operational context beyond annotations: describes 'fast' performance, requires run_interactive, and discloses conditional return of Player position. Annotations (readOnly, idempotent, non-destructive) are complemented, not contradicted.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tightly packed sentences with front-loaded purpose, followed by alternatives and a prerequisite. No filler; every clause adds useful information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description adequately covers return values (scene name, autoload vars, Player position), usage context, prerequisites, and fallback alternatives. It fully equips an agent to decide when and how to invoke the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has zero parameters, so baseline is 4 per rubric. The description adds value by outlining what the tool returns, though it naturally cannot add parameter-level detail since none exist.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states the tool returns scene name, autoload variables, and Player position, with a specific verb ('returns') and resource. Explicitly differentiates from game_screenshot by noting it is preferred for gameplay logic.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit when-to-use guidance: preferred over game_screenshot for gameplay logic, and directs users to evaluate_expression or get_node_properties for state not exposed via autoloads. Also mentions inline state capturing via send_key_sequence and the prerequisite run_interactive.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the safety profile is known. The description adds that the source is a running Godot project and that errors_only and tail filters are supported. However, it does not disclose failure behaviors (e.g., if no project is running) or the exact structure of returned output. Given annotation coverage, this is adequate but not rich.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three short sentences, front-loaded with the core action, and every sentence carries useful information (purpose, filters, alternative). No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple with no required parameters and no output schema. The description covers purpose, source, filters, and points to an alternative for structured errors. It does not discuss behavior when no project is running, but for this complexity level, it is nearly complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 100% description coverage for both tail and errorsOnly, clearly explaining their meaning. The tool description mentions these filters but does not add information beyond the schema. Thus the description adds no extra parameter value; baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves console output (stdout/stderr) from a running Godot project. It specifies the resource and scope, and distinguishes itself from the sibling get_runtime_errors by pointing to that tool for structured errors.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly directs users to get_runtime_errors for structured errors with stack traces, establishing a clear when-not and alternative. The mention of 'running Godot project' implies the prerequisite context. This is explicit enough for a simple read tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, fully covering the safety profile. The description adds minimal behavioral context with the word 'installed', implying it reads the local environment rather than a remote source, but it does not specify return format or failure modes.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence with no wasted words. Every word contributes to the tool's purpose, and it is immediately understandable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (no parameters, no output schema, safe annotations), the description fully covers what an agent needs to know. The lack of return format details is acceptable for a trivial version query.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so the description cannot add parameter-level meaning. The baseline for 0 parameters is 4, and the description is sufficient for a parameterless operation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Get the installed Godot version' uses a specific verb ('Get') and a clear resource ('installed Godot version'). It fully distinguishes this tool from all sibling tools, none of which retrieve version information.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The tool's purpose is self-evident: to retrieve the installed Godot version. Since no sibling tool offers this capability, explicit usage guidance is unnecessary. The context is clear, though no exclusions or alternative tools are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds value by disclosing that the tool runs headless without requiring a running game, which is a non-obvious behavioral trait. It does not mention edge cases or failure modes, but it goes beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the main purpose, and every word earns its place. It efficiently communicates scope, parameter type, and execution mode without any fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity and absence of an output schema, the description adequately covers the analysis capabilities (methods, signals, dependencies, exports) and the headless execution context. It does not detail the return format, but the listed items provide a clear expectation of what insights are returned.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema is fully described (100% coverage), providing clear definitions for scriptPath and projectPath. The description adds extra semantic clarity by explicitly warning 'Takes a scriptPath, not a nodePath,' which prevents a common mistake and enriches understanding beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses specific verbs and resources: 'Analyze a GDScript file' with concrete actions (classify methods, identify signals, map dependencies, list exports). It also explicitly distinguishes from node-based tools by stating 'Takes a scriptPath, not a nodePath,' which clearly separates it from sibling tools like get_node_properties or get_scene_insights.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear usage context by noting that it operates on a script path, not a node path, and runs headless (no game needed). This helps the agent understand when to use it (static analysis) versus launching a game. However, it does not explicitly name alternative tools or provide when-not-to-use guidance, so it falls short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate read-only, idempotent, and non-destructive behavior, so the description adds value by detailing what it returns (all non-default properties or specific ones if listed) and by specifying it operates on saved scene files. This goes beyond the annotations without contradicting them.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise, consisting of two sentences that lead with the core action. Every sentence contributes useful information without any fluff or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read tool with no output schema, the description adequately explains the return behavior (all or specific properties) and distinguishes from runtime access. It could optionally mention the return format, but given the simplicity and annotations, it is sufficiently complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema covers 100% of parameters, so the baseline is 3. The description adds meaningful context for the 'properties' parameter by explaining the behavior when omitted (all non-default) versus when provided (specific ones), which enhances understanding beyond the schema's brief field descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool reads properties from a node in a saved scene file on disk, using the specific verb 'Read' and mentioning the resource type. It also differentiates from sibling tools by explicitly noting that runtime properties should be handled by evaluate_expression.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context: it reads static properties from .tscn files, not runtime state. It explicitly names an alternative tool (evaluate_expression) for runtime properties, but does not enumerate all other alternatives like set_node_properties for writing, which is implicitly clear from the name.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is known. The description adds the prerequisite of run_interactive and clarifies optional filtering, which adds useful behavioral context beyond the annotations. It does not describe return format, but that is not a major gap for this simple read tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three short sentences that are all essential: purpose, optional filtering, and prerequisite. It is front-loaded with the main action and contains no filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-optional-parameter read tool with good annotations, the description covers the core aspects: what it does, the optional filter, and the prerequisite. It doesn't define return values or error behavior, but given the simplicity of the tool and the annotations, it is sufficiently complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema fully documents the 'metrics' parameter (optional array of strings, default all). The description repeats this with 'Optionally filter to specific metrics,' adding no additional meaning. Since schema description coverage is 100%, baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves performance metrics (FPS, draw calls, memory, node count) from a running project, with an optional filter. This is a specific verb+resource+scope that distinguishes it from sibling tools like get_debug_output or get_scene_insights.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly mentions 'Requires run_interactive,' which is a clear prerequisite and context for when to use this tool. It implies use when the project is running and the user needs performance metrics, but it does not explicitly name alternatives or provide exclusions, hence not a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description does not disclose any additional behavioral traits, such as error handling or what exactly constitutes 'metadata', thus adding no value beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with no superfluous words, extremely concise and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of an output schema, the description should inform the agent what metadata is included (e.g., project name, version, settings), but it does not. Also, no usage scenarios are provided, making the description incomplete for a tool that may need to be selected among many siblings.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema's single parameter projectPath is fully described ('Path to the Godot project directory'), achieving 100% schema coverage. The description does not add parameter-level detail, but the schema is sufficient, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The verb 'retrieve' and resource 'metadata about a Godot project' clearly state the tool's function, distinguishing it from siblings like list_projects and get_godot_version. However, it does not enumerate what metadata is returned, leaving some ambiguity about the exact scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no context for when to use this tool, no alternatives, and no exclusions. It is a single declarative statement without any guidance on selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses stateful 'since the last call' behavior and return content (structured entries with error type, source, stack traces). Adds prerequisite of run_interactive. Annotations already cover read-only/destructive hints, and description does not contradict them.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the core purpose, concise and free of filler. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With one optional parameter and no output schema, the description covers the return structure and prerequisites well. It doesn't explicitly describe the consuming behavior of the default clear=true, but the schema's parameter description fills that gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The only parameter, 'clear', has full schema description coverage (100%). The description adds no additional parameter detail, but the schema already clearly explains the default behavior and peek option, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description uses a specific verb ('Retrieve') and clearly identifies the resource: runtime errors, warnings, and backtraces since the last call. This distinguishes it from sibling get_debug_output by focusing on structured runtime errors with stack traces.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

States explicit prerequisites ('Requires Godot 4.5+ and run_interactive'), giving clear context for when the tool can be used. However, it does not explicitly mention alternatives or when not to use it, so it falls short of full guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds valuable behavioral context by revealing that the tool runs headless, which is not indicated in annotations, and by describing the scope of the analysis, giving a clear picture of what the tool inspects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise—two short sentences that front-load the primary action and list the analyzed components, followed by the headless note. Every word earns its place, with no redundancy or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the absence of an output schema, the description compensates by listing the analysis dimensions (type distribution, signals, sub-scenes, scripts, groups, tree depth), giving a strong hint of the return content. It also notes the headless execution. However, it does not explicitly describe the return format (e.g., a JSON object), which prevents a perfect score.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with both parameters (projectPath and scenePath) clearly documented in the schema. The description adds no additional parameter-level details beyond what the schema already provides, so the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Analyze') with a clear resource ('a scene's architecture') and enumerates the exact aspects covered (type distribution, signals, sub-scenes, scripts, groups, tree depth). This distinguishes it from sibling tools like get_scene_tree, which likely only returns the raw tree.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context by noting it 'Runs headless (no game needed)', implying it is for static analysis without launching the game. However, it does not explicitly state when to use this tool over alternatives or mention any exclusions, so the usage guidance is implied rather than explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is covered. The description adds meaningful behavior beyond these: it reads from disk (not a running scene), returns data as JSON, and emphasizes no running game is required. This gives the agent a clearer picture of the tool's operational behavior without contradicting the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the core function ('Read a scene's node tree...') and then a concise alternative. No filler words or repetition; every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple (read a file and return JSON), and the description covers the essential aspects: what is read, where it comes from (disk), the output format (JSON), and the contents of the JSON (names, types, properties, hierarchy). The alternative use case is addressed, and the schema/annotations handle parameter and safety details, so nothing essential is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema fully describes both parameters (projectPath and scenePath), achieving 100% schema coverage. The description does not add extra parameter-level detail, but that is unnecessary because the schema already provides clear meaning. The baseline of 3 applies since the description contributes nothing beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the specific verb 'Read' and identifies the resource as 'a scene's node tree from a .tscn file on disk', with a clear list of what is returned (names, types, properties, hierarchy). It also explicitly distinguishes from the sibling tool get_scene_insights by stating the alternative for architecture analysis, making the purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states 'No running game required', establishing a clear context for when to use this tool (file-based inspection without a live project). It also provides a direct when-not instruction by saying 'For architecture analysis, use get_scene_insights', which guides the agent to another sibling tool for a specific alternative use case.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses behavior beyond the annotations: it clears the buffer by default and mentions the return fields. It also notes a dependency on run_interactive. No contradiction with annotations; it adds useful context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, with two clear sentences. It is front-loaded with the core action and includes essential return and side-effect information without unnecessary detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one optional parameter, the description covers purpose, return values, side effect, and a prerequisite. It could mention empty-buffer behavior, but annotations and schema cover safety, making it sufficiently complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema fully documents the 'clear' parameter with its default and effect. The description restates the default behavior but does not add semantic meaning beyond what the schema already provides, so a baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the tool's purpose: retrieving buffered signal events. It specifies the source (subscribe_signals) and the return content (signal name, arguments, timestamp), which distinguishes it from siblings like subscribe_signals or wait_for_signal.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states a prerequisite (requires run_interactive) and implies typical usage after subscribing to signals. However, it does not explicitly mention alternatives or exclusions, such as using wait_for_signal for a single signal instead.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is safe and non-mutating. The description adds scoping context by specifying it reads from a TileMapLayer node in a scene, but it does not go beyond that to describe return format, side effects, or error behavior. It is consistent with annotations, with no contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence that gets straight to the point with the verb 'Read'. Every word earns its place, and there is no redundant filler or repetition of the tool name.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has no output schema, so the description should clarify what the agent can expect in return. It says 'Read existing tile cells' but does not specify the format (e.g., list of cell coordinates, tile IDs). The parameters are well-covered, but the missing return details and lack of any note about prerequisites or failures leave a moderate gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with each parameter getting a clear description (projectPath, scenePath, nodePath). The tool description adds no additional parameter-level meaning beyond what the schema already provides, meeting the baseline for well-documented parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Read existing tile cells from a TileMapLayer node in a scene' uses a specific verb ('Read') and clearly identifies the resource (tile cells in a TileMapLayer node). It distinguishes from sibling write tools such as set_cells by emphasizing 'existing' cells and the read action.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage: if an agent needs to read tile data from a TileMapLayer node, this is the tool. However, it provides no explicit when-to-use guidance or mention of alternatives, so it falls under 'implied usage' rather than clear contextual direction.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds a version constraint (Godot 4.4+) but does not disclose return format or error behavior, which would further aid transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence: 'Get the UID for a specific file in a Godot project (for Godot 4.4+)'. Every word contributes, with no redundant or filler content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only getter with full schema coverage and safety annotations, the description is largely sufficient. It clearly indicates what the tool returns (a UID) and the required parameters, though it omits explicit return format details since no output schema is provided.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema covers both parameters with clear descriptions (relative file path and project directory). The description adds no additional parameter-level meaning beyond what the schema already provides, so a baseline score is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action (Get) and resource (UID for a specific file in a Godot project), with a version qualifier (Godot 4.4+). This clearly distinguishes it from siblings like update_project_uids or get_project_info.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context: use when you need the UID for a specific file in a Godot 4.4+ project. It does not explicitly name alternatives or when-not-to-use, but the purpose is well-scoped and not misleading.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description reveals important behaviors: automatic resolution/verification of assetId, default stripping of a wrapping folder, overwriting of existing files, deferred import, and rejection of path-traversal entries. These are non-obvious and critical for safe usage, adding significant value beyond the structured metadata.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Four well-structured sentences, each carrying distinct value: purpose, source methods, extraction and overwriting, and security check. No filler or redundancy; front-loaded with the core action.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 7 parameters, no output schema, and moderate annotations, the description covers security, file system effects, import behavior, and both usage paths. It is sufficient for an agent to invoke the tool correctly and anticipate side effects.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema coverage is 100%, the description enriches key parameters: it explains that assetId resolves download URL and sha256, that downloadUrl is a direct .zip link with no hash verification, and that subdirectory/stripTopLevel control extraction. This goes beyond the schema's basic type/description and clarifies trade-offs.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description begins with a clear verb+resource pair: 'Download an asset from the Godot Asset Library and extract it into a project.' It precisely identifies the action and destination, and distinctly separates this from sibling tools like search_assets (which only searches) or export_project (which exports).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains how to use the tool via assetId or downloadUrl, and implies it is for installing assets/addons. It does not explicitly name alternatives or exclusion criteria, but the context is clear enough that an agent can decide when to invoke it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnlyHint=false, so the description does not need to state this is a write operation. It adds the context that the operation creates a child instance, but does not disclose side effects, reversibility, or prerequisites beyond that. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, front-loaded with the core action, and includes a helpful example without extraneous detail. It earns its place efficiently.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with six parameters and no output schema, the description is minimal. It does not mention prerequisites (e.g., whether the project must be open), return values, or error conditions. While the schema and example cover much, the added context is thin for the complexity involved.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with all parameters documented. The tool description adds little beyond what the schema already provides, such as clarifying the relationship between parent and child scene paths. This matches the baseline for fully covered schemas.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action: 'Add a scene as a child instance of another scene,' with a concrete example. It uses a specific verb and resource, and distinguishes itself from sibling tools like create_scene or add_node by focusing on instantiating an existing scene as a child.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The example ('spawn a player scene inside a level') implies a common use case, but there is no explicit guidance on when to prefer this tool over alternatives or any exclusions. It lacks the 'use X instead' clarity seen in high-scoring tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations are all false, offering minimal safety context. The description compensates by clarifying the tool launches the editor GUI rather than the game, adding a meaningful behavioral distinction. It does not disclose whether the call blocks or returns immediately, but the core behavior is transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences that front-load the primary action and immediately follow with a clarifying exclusion. Every word contributes to understanding without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter tool with no output schema, the description covers the core purpose, exclusions, and alternatives. It is complete in context and requires no additional explanation to use correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, with projectPath already described as 'Path to the Godot project directory.' The description adds only the general reference to 'a project' and does not provide additional parameter-specific detail, which is acceptable given full schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Uses a specific verb 'launch' with a clear resource: 'the Godot editor GUI for a project.' It explicitly distinguishes itself from run_project and run_interactive by stating it does not run the game, making the purpose unambiguous relative to siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit when-not-to-use guidance: 'Does not run the game' and names exact alternative tools: 'use run_project or run_interactive for that.' This is a clear directive for tool selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint and idempotentHint, so the safety profile is known. The description adds useful behavioral context that it reads project.godot and works without a running game, which goes beyond the annotation metadata.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with no redundant information. It front-loads the purpose and immediately adds a practical usage tip, making it highly scannable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only tool with one parameter, the description covers the action, purpose, and a key operational constraint. It doesn't detail the return format, but the phrase 'list all input actions' adequately implies a list of action names, which is sufficient given the tool's low complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already provides a complete description of projectPath (100% coverage), so the baseline is 3. The description's mention of project.godot adds minimal semantic value beyond the schema, which already indicates a Godot project directory.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the primary function with a specific verb and resource: 'List all input actions defined in a project's project.godot (the InputMap).' It also situates the tool relative to a sibling by mentioning it's useful before using send_input, which differentiates it from other project-management tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives a clear usage context ('Useful before using send_input') and a key constraint ('No running game required'). It doesn't explicitly state when not to use it or name alternative tools, but the guidance is sufficient for the agent to select it appropriately.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds almost no behavioral context beyond what the name and annotations imply; it does not explain how projects are detected (e.g., presence of project.godot) or any constraints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence that fully conveys the core functionality without unnecessary words. It is well-structured and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the low complexity (2 params, one optional), good annotations, and full schema coverage, the description is adequate. It does not explain return values, but for a list tool this is often implicit; the absence of an output schema is mitigated by the straightforward nature of the operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema covers both parameters (directory and recursive) with descriptions, achieving 100% coverage. The description adds no significant semantic value beyond the schema, so a baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('List') and the target ('Godot projects') with a specific location ('in a directory'), making it distinct from sibling tools like get_project_info or export_project. It is specific and not a tautology.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The guidance is implied: to enumerate projects, use this tool. However, it does not explicitly state when to use it versus alternatives (e.g., get_project_info for details) or provide any exclusions. There is no explicit 'when to use' context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate this is not read-only, not idempotent, and not destructive, but the description adds no further behavioral context. It does not clarify whether the scene file is modified, whether the node must exist, or any side effects of loading a sprite.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence that directly states the tool's purpose. There is no wasted wording or redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity and complete parameter descriptions, the one-sentence description is minimally viable. However, it lacks information about behavioral outcomes (e.g., persistence, prerequisites) and offers no output schema or annotation support, leaving some ambiguity for an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% coverage, with each parameter (nodePath, scenePath, projectPath, texturePath) already described meaningfully. The description adds no additional parameter semantics beyond what the schema provides, so the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Load a sprite into a Sprite2D node' uses a specific verb and clearly identifies the resource (sprite) and target (Sprite2D node). It is distinct from sibling tools like add_node or set_node_properties, as it focuses specifically on loading a texture into an existing Sprite2D node.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool versus alternatives, nor any mention of prerequisites or context. It simply states what it does, leaving the agent to infer when to invoke it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate the tool is not read-only and not destructive, so the safety profile is partly covered. The description adds that it edits project.godot, but it does not disclose output formats for 'list' or potential side effects of 'add'/'remove' (e.g., whether existing entries are overwritten). This is sufficient but not rich.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, tightly worded sentence that leads with the action verbs and resource. No wasted words, and it is immediately scannable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is adequate for a simple tool with documented parameters, but it lacks an explanation of the 'list' action's return value or any prerequisites/error conditions. Since there is no output schema, a brief note on what list returns would improve completeness, but overall the description covers the core functionality.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the parameters are fully described in the schema. The description does not add extra meaning beyond what the schema already provides. The baseline of 3 applies here since the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses specific verbs 'Add, remove, or list' and clearly identifies the resource ('autoload singletons in project.godot'). This distinguishes it from sibling project-management tools by naming the exact configuration element it targets.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly implies usage: use this tool whenever you need to manage autoload singletons in a Godot project. It does not explicitly state exclusions or name alternative tools, but the context is unambiguous and the action set (add/remove/list) covers the primary use cases.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With annotations providing only false hints (readOnly, destructive, etc.), the description must disclose behaviors itself. It does reveal a non-obvious trait: the MCP receiver remains active during pause. But it does not mention side effects, reversibility, or what happens to the game state. This is adequate but not comprehensive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the primary action and followed by a key behavioral detail and prerequisite. Every sentence earns its place without redundancy or fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one optional parameter and no output schema, the description adequately covers purpose, a key behavioral nuance, and a requirement. It could mention what happens after unpausing, but overall it is sufficiently complete for an agent to use it effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema covers the single parameter 'paused' with a clear description. The tool description adds no additional parameter details, so baseline 3 is appropriate given 100% schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Pause or unpause') with a clear resource ('a running project'), making the primary action unmistakable. It also distinguishes from sibling tools like stop_project by implying a non-terminal halt. The added detail about the MCP receiver staying active further clarifies the tool's unique role.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides contextual guidance by stating 'MCP receiver stays active for screenshots, state queries, and property changes while paused,' which suggests use cases where the project should remain responsive. It also notes 'Requires run_interactive,' setting a prerequisite. However, it does not explicitly name alternative tools or exclusions, so it falls short of full guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context by stating it returns the full source code as text, clarifying the output format beyond what annotations provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that immediately states the action (read), the target (GDScript file), the context (Godot project), and the return type (full source code as text). No superfluous words or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read operation, the description is complete: it names the resource, the scope, and the output format. The tool has no output schema, but the description explicitly states what is returned, and the read-only annotations cover side-effect concerns. No additional context is needed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with both parameters adequately described in the schema. The description adds no further detail about parameter meaning or formatting, so it does not go beyond the baseline for full schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Read') and resource ('GDScript file from a Godot project'), clearly distinguishing it from sibling tools like write_script, validate_script, and execute_script. It specifies the scope (Godot project) and the output (full source code as text).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies its usage: read a script file when you need its contents. However, it does not explicitly mention when to use it over alternatives or provide exclusions, so it stops at implied usage rather than clear guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description simply restates the destructive action already declared by destructiveHint=true. It does not add context about error behavior (e.g., what happens if the node is not in the group), idempotency, or any side effects. No additional behavioral disclosure beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, clear sentence with no filler. It immediately states the action and target, making it efficient and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple and fully covered by the schema (100% parameter documentation). No output schema is needed since the operation returns nothing significant. The description sufficiently communicates the core operation, though it could mention edge cases like non-existent groups, but this is minor given the tool's simplicity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, with all four parameters well-documented in the input schema. The description adds no parameter-specific meaning beyond the schema, which is acceptable given the high schema coverage, meeting the baseline of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Remove a node from one or more groups in a scene' uses a specific verb ('Remove') and clearly identifies the resource (a node) and the target (groups). This clearly distinguishes it from sibling tools like add_to_group and remove_node.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the use case (removing a node from groups) but does not explicitly state when to use this tool over alternatives like add_to_group or provide any exclusions or prerequisites. It relies on the agent inferring the context from the operation itself.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations already indicate destructiveHint=true and readOnlyHint=false, so the agent knows this is a destructive write operation. The description adds important context that the operation removes not only the node but also its children, which is behavior beyond the basic annotation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, focused sentence that immediately conveys the core action. It is front-loaded with the verb and resource, with no redundant or filler content. Every word contributes to understanding the tool's purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a straightforward deletion tool with three fully documented parameters and clear annotations, the description is sufficient. It conveys the essential behavior (including child deletion) without requiring extensive explanation. It could mention error cases or whether changes persist to disk, but given the schema and annotation support, the description meets the needs for effective selection and invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema provides 100% coverage with descriptions for all three parameters (projectPath, scenePath, nodePath). The description does not add any additional parameter-level semantics beyond what the schema already specifies, so the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb 'remove' with a clear resource 'node (and its children)' from a 'scene', making the tool's function unambiguous. It is distinct from sibling tools like add_node, reparent_node, or rename_node, which have different operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage (when you need to delete a node from a scene) but does not provide explicit guidance on conditions, exclusions, or alternatives. There is no mention of when not to use this tool or how it compares to similar operations like remove_from_group.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds meaningful behavioral context beyond the annotations (which only indicate readOnlyHint=false and destructiveHint=false): it guarantees that properties, children, and connections are preserved. This addresses what is not destroyed and clarifies the non-destructive nature of the rename. It does not contradict any annotation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two short sentences, front-loaded with the action ('Rename') and followed by a concise behavioral guarantee. Every word earns its place, with no redundant or extraneous information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple rename operation with four well-documented parameters and no output schema, the description provides sufficient context for an agent to select and invoke the tool correctly. It covers the core purpose and a key behavioral guarantee, though it does not mention edge cases like name collisions or what happens if the node does not exist.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents each parameter (projectPath, scenePath, nodePath, newName) with clear descriptions. The tool description does not add additional detail about parameter formats, constraints, or relationships beyond what is in the schema, so the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the specific verb 'Rename' with a clear resource ('a node in a scene file') and explicitly states the scope: 'keeping all properties, children, and connections intact.' This clearly distinguishes it from sibling operations like remove_node or reparent_node, which would alter structure.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The operation is inherently specific, and the phrase 'keeping all properties, children, and connections intact' implies when it is appropriate (when the goal is purely renaming without structural changes). However, it does not explicitly mention alternatives or exclusions, such as 'use set_node_properties to change other attributes' or 'do not use for reparenting.'

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description does not add much beyond the basic operation. Annotations already indicate it is not read-only (readOnlyHint=false) and not idempotent, so the mutation nature is known. The phrase 'within the same scene' is a useful constraint, but there is no disclosure of side effects like children moving with the node or impact on references.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence that perfectly conveys the tool's function without unnecessary words. It is front-loaded and earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple mutation tool with fully described parameters and no output schema, the description is adequate. It mentions the key constraint of being within the same scene, which is important context. It doesn't explain return values, but that's not required given the simple nature of the operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage, with all four parameters well-documented (e.g., nodePath and newParentPath examples). The description adds no additional meaning about parameters, so the baseline score of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Move a node to a different parent') and the scope ('within the same scene'), which distinguishes it from sibling tools like rename_node or remove_node. The verb and resource are specific, making the tool's purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use the tool: when you need to change a node's parent within a scene. It does not explicitly mention alternatives or exclusions, but the purpose is self-evident enough to guide selection among the many node-related tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate destructiveHint=true; the description adds context by explaining the tool 'resets game state' and requires the project to be running via run_interactive. This goes beyond the raw annotation without contradicting it.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three concise sentences: the action, the use case, and the prerequisite. Every sentence adds value with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with no parameters and no output schema, the description fully covers what it does, when to use it, and the necessary precondition. No critical information is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so the baseline is 4. The description correctly does not attempt to describe nonexistent parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb 'reload' with a clear resource ('current scene') and context ('running interactive Godot project'). It clearly distinguishes from scene-editing siblings by focusing on runtime reload.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides a clear use case ('resetting game state during test loops') and a prerequisite ('must be running via run_interactive'). It does not explicitly name alternatives or when-not conditions beyond the prerequisite, so not a full 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the description need not repeat those. It adds useful context: the tool runs for a specified duration, captures a screenshot, then stops, and requires a display server. This goes beyond the annotations without contradicting them.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no fluff. The first sentence states the core action and stopping behavior; the second differentiates from siblings and adds the display server prerequisite. Every phrase contributes.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description, combined with the rich annotations and 100% schema coverage, is fully complete for this tool's complexity. It covers purpose, runtime behavior, prerequisites, and sibling differentiation. No return schema is needed as the tool is screenshot-focused and the output path is in the parameters.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%; all parameters already have descriptive comments. The description does not add additional parameter-level meaning beyond what the schema provides (e.g., duration, outputPath, scene). It satisfies the baseline for full schema coverage but offers no extra semantic value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the action clearly: 'Run the project for a duration, capture a screenshot, then stop.' It also differentiates from siblings by explicitly contrasting with capture_screenshot ('Runs the full game') and game_screenshot ('without needing run_interactive'). This provides a specific verb, resource, and scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides context for when to use this tool vs alternatives: it explicitly states it runs the full game unlike capture_screenshot, and does not require run_interactive unlike game_screenshot. It also notes the prerequisite of a display server. However, it does not explicitly say 'use this instead of X when Y' or provide exclusions beyond these comparisons.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses meaningful behavioral context beyond annotations: it injects an MCP input receiver, enables capabilities like send_key_sequence and game_state, and communicates via TCP. It doesn't detail side effects or cleanup, but it adds valuable transparency for a run tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with the core action, followed by capabilities and usage guidance. Every sentence earns its place with no filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple two-parameter schema and no output schema, the description provides enough context to select and invoke the tool: it states the purpose, lists enabled features, and gives an alternative. It could mention lifecycle details or prerequisites, but it is largely complete for an AI agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 100% description coverage for its parameters (projectPath and scene), so the description isn't required to repeat them. The description adds no parameter-specific meaning, but the schema handles semantics adequately.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Run a Godot project with MCP input receiver injected.' It clearly states the tool's function and differentiates it from siblings by saying 'Use instead of run_project for interactive testing.'

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly provides usage guidance with 'Use instead of run_project for interactive testing,' naming the alternative and the context in which to choose this tool. This tells the agent when to prefer run_interactive over run_project.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations are all false, providing no positive hints. The description adds context by specifying non-interactive behavior and console output capture, and clarifies what it does not do. While it doesn't disclose potential side effects, it's adequate for a run tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, directly to the point. Every word adds value; no fluff. Front-loaded with the action and resource.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple, and the description covers the core behavior and output (console output). It distinguishes from run_interactive and mentions non-interactive mode. No output schema, but the description indicates what to expect.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers 100% of parameters with descriptions, and the description text doesn't add additional parameter meaning beyond that. Baseline of 3 is appropriate since the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool runs a Godot project non-interactively and captures console output, using a specific verb and resource. It distinguishes from sibling tools like run_interactive by explicitly noting what this tool does not do.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says 'No input, screenshots, or state queries — use run_interactive for those,' providing clear guidance on when to use this tool versus the alternative. This meets the highest standard for usage direction.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds behavioral context by noting the GUT installation requirement and the return format (pass/fail summary and console output), which is useful beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the core purpose and then adding necessary prerequisites and expected output. Every sentence earns its place without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity, the strong schema descriptions, and the annotations, the description provides enough context. It clearly states the output and prerequisite, and the absence of an output schema is compensated by the summary mention. Minor gaps like timeout behavior are covered by parameters.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all parameters are well-documented. The description does not add parameter-specific details beyond what the schema provides, but it does not need to; baseline 3 is appropriate given the high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Run') and resource ('GUT tests') with the method ('via headless Godot'), clearly distinguishing it from sibling tools like run_project or run_interactive. It also explains what GUT is, eliminating ambiguity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description states the prerequisite (GUT installed) and the headless nature, implying it is meant for unit testing rather than general project running. It does not explicitly name alternatives or exclusions, but the context is clear enough for an agent to choose correctly.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations provide no safety profile (readOnlyHint, destructiveHint false). The description discloses the copy behavior via newPath, but does not explicitly state whether saving without newPath overwrites the existing scene or what happens to the current scene state. This leaves some ambiguity for a mutation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the main purpose and followed by usage guidance. No redundant filler, every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a straightforward save tool with full schema coverage and no output schema, the description provides purpose, usage, and copy behavior. It is slightly incomplete in not detailing overwrite behavior, but overall adequate for the tool's simplicity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.