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

With no annotations, the description fully discloses important behaviors: it creates in the default library, auto-creates AnimationPlayer if the path doesn't resolve (with parent requirement), and explains the root_node-relative track path handling. These are critical side effects and context not inferable from the schema.

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

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

The description is a tight, well-structured paragraph. It opens with the primary action, then the follow-up steps, and then crucial path semantics. No redundant or vague sentences exist.

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

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

For a tool with 6 parameters and an output schema, the description covers the main workflow, prerequisites (parent exists), and side effects. It does not explicitly describe failure behavior for existing clips when overwrite is false, but the overall context is sufficient for an agent to select and invoke the tool.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value beyond the schema by explaining the default library context, the auto-creation behavior tied to player_path, and the root_node relative path handling, which are not detailed in the parameter descriptions.

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

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

The description clearly identifies the verb (Create), object (Animation clip), and context (inside an AnimationPlayer's default library). It differentiates from sibling tools like animation_manage by specifying that this creates the clip, not the tracks, and even directs users to proper follow-up operations.

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

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

The description provides strong usage context by stating that after creating the clip, tracks are added via animation_manage ops. It also notes the auto-creation behavior for non-existent paths, though it could be more explicit about when not to use this tool compared to others.

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

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

With no annotations, the description carries the full behavioral burden. It discloses important traits: delete is undoable, play/stop are editor previews not saved with the scene, set_autoplay with empty name clears autoplay, validate returns broken_count and per-track issues, and target_paths are converted to relative track paths. It does not address error conditions or prerequisites such as session/active scene, but it is far more transparent than most.

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

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

Although long, the description is densely packed and organized by operation with a consistent one-line signature followed by brief explanations. It starts with a high-level summary and ends with the canonical call shape. Every line earns its place, and the bulleted layout makes scanning easy.

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

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

Given the tool's complexity (15 operations) and a generic input schema, the description is remarkably complete: it covers all operations, parameter details, target-path resolution, preset behaviors, and call-shape conventions. An output schema exists, so return-value documentation is not required. Minor details like overwrite semantics and error handling are not spelled out, but the description is sufficient to invoke all operations correctly.

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

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

Schema description coverage is 0%, so the description is the only source of parameter semantics. It fully compensates by documenting every operation's parameters, including track_path format ('NodeName:property'), keyframe structures, interpolation enum values, tweens spec, and all preset arguments. This is essential for invoking the tool correctly and is done thoroughly.

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

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

The description clearly states the tool's scope with 'AnimationPlayer authoring' and then enumerates 15 specific operations from player_create to preset_pulse. It identifies the resource (AnimationPlayer clips/tracks) and differentiates from sibling animation_create by focusing on player-level manipulation rather than creation of animation resources, though it does not explicitly name alternatives.

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

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

The description provides clear context: all operations are for AnimationPlayer authoring, and each op's signature implies when it should be used (e.g., create_simple for high-level multi-track builds, preset_fade for one-call fades). However, it does not explicitly state exclusions or compare against alternative tools like animation_create or node_set_property, so it stops short of a 5.

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

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

With no annotations, the description carries the transparency burden. It discloses that no scene instance is created, that 'all' does not include inheritors, and that pagination works per section. It does not mention potential errors or permissions, but for a read-only inspection tool the disclosed behavior is substantial.

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

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

The description is well-structured with resource form, ops, and call-shape sections, and every sentence adds value. It is somewhat lengthy due to detailed parameter explanations, but this is justified given the schema gap. It avoids repetition and stays organized.

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

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

The tool has an output schema, and the description provides complete operational context: purpose, usage, parameter details, pagination behavior, and call format. It leaves little ambiguity for an agent to select and invoke the tool correctly, even among many siblings.

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

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

Schema coverage is 0%, so the description must fully explain parameters. It does so extensively: sections can be a comma-separated string or list, defaults to ['properties'] only, 'all' excludes inheritors, and offset/limit apply per section. The op signature and call shape are also explained, fully compensating for the generic schema.

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

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

The description clearly states the tool inspects Godot API documentation-shaped metadata from the ClassDB, with specific examples like 'what properties does X have' and method signatures. It distinguishes itself from runtime node inspection by noting it works 'without creating a scene instance', making it distinct from sibling tools like node_get_properties.

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

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

The description provides clear context on when to use the tool, such as 'prefer for active-session reads' and details the resource form. It explains section selection and pagination but does not explicitly name alternative tools or exclusion scenarios, so it falls short of a full 5.

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

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

With no annotations, the description compensates by flagging 'Not undoable' for play/stop, noting 'real editor preview playback', and stating atomicity for player_set_playback. It could go further by disclosing side effects of create/set operations, but the provided behavioral notes are valuable.

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

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

The description is compact and well-structured, using a bulleted list with one-line ops. Every sentence earns its place, and the canonical call-shape note is necessary for a multi-op tool. No fluff or redundancy.

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

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

All six operations are documented with parameters and some return info (e.g., duration_seconds for player_set_stream). The description lacks explicit error/edge-case behavior, but the presence of an output schema reduces the need to explain return formats, making this sufficiently complete.

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

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

The top-level schema has zero descriptions, but the description fully specifies each sub-command's parameters, types, defaults, and requirements (e.g., 'at least one of volume_db/pitch_scale/autoplay/bus required'). This adds essential meaning beyond the schema, making it highly effective.

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

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

The description opens with 'Sound effects, music, ambience (AudioStreamPlayer / 2D / 3D)', clearly identifying the tool as audio management. It then enumerates six concrete operations (player_create, player_set_stream, etc.), making the purpose specific and well-distinguished from sibling tools like node_manage or resource_manage.

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

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

The description provides clear domain context ('sound effects, music, ambience') and operation-level details, such as when to use player_create vs play. However, it does not explicitly compare with alternative tools (e.g., resource_manage for loading streams), so alternatives are not named.

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

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

With no annotations provided, the description fully carries the burden of behavioral disclosure. It discloses that autoloads are persisted to project.godot, that singleton=True enables global access by name, that remove() does not delete the underlying file, and describes the canonical call shape. These side effects and operational details are clearly communicated.

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

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

The description is moderately long but extremely well-structured with a clear opening definition, a bulleted list of operations, and a final note on call shape. Every sentence serves a purpose, and the format makes it easy for an AI agent to parse. It is concise relative to the complexity of a multiplexed operation tool.

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

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

The description fully covers the tool's scope: it explains the concept of autoloads, lists all operations with their parameters, notes persistence behavior, and clarifies the calling convention. Given that an output schema is present, the description need not explain return values. No critical gaps remain for an agent to invoke the tool correctly.

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

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

The schema has 0% description coverage and only shows op, params, and session_id with no parameter documentation. The description compensates by listing the exact parameters for each operation: add(name, path, singleton=True), remove(name), and list() with no args. It also explains that flat op parameters are accepted as a compatibility alias, adding meaning entirely beyond the schema.

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

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

The description clearly states the tool's purpose as 'Autoload (global singleton) management' and provides a concise overview of autoloads. It lists the specific operations (list, add, remove) with signatures, which uniquely identifies the tool's function and distinguishes it from sibling tools like scene_manage or resource_manage.

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

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

The description implies the tool is for managing autoloads by defining what autoloads are and how they behave. It gives clear context for when to use the tool (to register, list, or unregister autoloads), but does not explicitly state when not to use it or name alternative tools for other resource types. The lack of exclusions keeps it at a 4 rather than a 5.

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

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

With no annotations provided, the description carries the full burden and does an excellent job. It discloses execution stops at first error, rollback semantics, sequential processing, requirement to use underlying plugin command names, path notation relative to the edited scene root, and the restriction against nested batch_execute calls. This goes beyond what any annotation schema would typically provide.

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

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

The description is longer than average but each sentence adds necessary detail about format, behavior, and use cases. It is well-structured with a clear opening, a formatted example, and topic-specific sentences. While it could be slightly tightened, it remains efficient and informative without redundancy.

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

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

Given the tool's complexity and the presence of an output schema (which handles return values), the description is complete: it covers input item structure, valid command names, execution ordering, failure handling, rollback semantics, path conventions, and a concrete example. No critical gaps are apparent for an agent to use this tool correctly.

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

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

Although the schema covers all three parameters (100% coverage), the description adds substantial meaning: it specifies the precise structure of each commands array item (`{"command": "<plugin_command>", "params": {...}}`), enumerates example command names, explains the rollback effect of the `undo` parameter, and clarifies path semantics relative to the scene root. This is far beyond the schema's minimal parameter descriptions.

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

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

The description clearly states 'Execute a list of editor sub-commands in order, stopping on first error,' which is a specific verb+resource with an explicit behavioral constraint. It distinguishes itself from sibling single-operation tools by focusing on batch composition and sequencing.

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

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

The description explicitly says 'Use this to compose multi-step edits (create node + set property + attach script) into a single tool call,' providing a clear use case. It also notes that `batch_execute` itself cannot be a sub-command and explains the undo/rollback behavior, which guides correct usage, though it doesn't explicitly name alternative single-command tools.

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

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

No annotations are provided, so the description carries the full burden. It discloses behavioral details such as make_current unmarking previous cameras in one undo, class-aware configure behavior, Vector2 coercion, empty path resolution for get, and the flat-parameter compatibility alias. This is more than a minimal description, though it omits some edge-case side effects like invalid path handling.

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

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

The description is structured with a one-line summary, then bullet-pointed operations with signatures. Each bullet adds distinct operational detail or a caveat (e.g., 'Pass only the edges to change'). There is no fluff or repetition, and the information is front-loaded.

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

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

Given the tool's multi-operation complexity, the description is complete: it covers all eight operations, their parameters, edge cases like empty path for get, and the call shape. An output schema is indicated as present, so return values need not be explained. The description fully equips an agent to invoke the tool correctly.

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

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

The input schema only defines op as an enum, params as a free-form object, and session_id, providing almost no parameter information. The description compensates fully by listing each operation's parameters with names, types, defaults, optional markers, and special semantics (e.g., drag_margins fractions, overrides merging). This is essential for correct use.

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

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

The description begins with 'Camera2D / Camera3D authoring' and enumerates eight specific operations with signatures, making the tool's purpose explicit. It also differentiates from sibling tools by stating that transforms belong to node_set_property, not here.

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

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

Provides clear negative guidance: transforms should be set via node_set_property, not camera_manage. Also explains the canonical call shape and compatibility alias for parameter passing. However, it does not explicitly state when to prefer camera_manage over the many sibling scene/camera-related tools beyond this one exclusion.

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

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

With no annotations provided, the description carries the full burden. It explicitly states that the tool 'Writes / removes client config files' and details each op's effect, including the destructive nature of 'remove'. It also hints at error states via the 'error' status in status(). It does not mention permissions or backup behavior, but the core side effects are transparent.

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

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

The description is well-structured with a concise intro, a bulleted Ops list, and a clear canonical call shape. Every sentence adds meaningful information, with no redundancy or filler. The use of code formatting and list structure makes it easy to scan.

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

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

Given the tool's moderate complexity, the description covers the essential behavior: supported clients, ops, call shape, and compatibility. An output schema exists, so the lack of return-value details is not a gap. The description is sufficient for an agent to correctly select and invoke the tool.

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

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

The schema has 0% description coverage, so the description must compensate. It effectively explains the 'op' enum via the Ops list, describes the 'params' object shape (including that 'client' is an id from status()), and clarifies the flat-parameters compatibility alias and top-level 'session_id'. This is strong parameter semantics despite no schema descriptions.

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

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

The description states a specific verb ('Configure') and resource ('AI clients... Godot AI MCP server'), and enumerates supported clients. The 'Ops' section further clarifies the distinct actions (status, configure, remove), making it easily distinguishable from sibling tools like editor_manage or scene_manage.

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

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

The description clearly indicates that the tool is for managing client config files and provides usage context for each op (status, configure, remove). It does not explicitly name alternatives or exclusions, but the purpose is so specific that usage intent is unambiguous. The canonical call shape and compatibility alias are also helpful guidance.

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

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

With no annotations provided, the description carries the disclosure burden. It reveals that all write ops are undoable via EditorUndoRedoManager, and that sibling CSG shapes auto-combine—useful behavioral context beyond the basic operation. It could mention error cases, but current disclosures are solid.

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

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

The description is well-structured with a one-liner summary, a detailed explanatory paragraph, and clearly formatted op bullets. It is slightly longer than necessary but every sentence adds value.

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

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

The description covers operation semantics, parameter details, return values, undo behavior, grouping constraints, and property handling. Given the tool's two-OP scope, this is fully sufficient for an agent to select and invoke correctly.

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

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

The input schema is generic (op/params/session_id) with 0% coverage of inner parameters. The description fully documents both ops: parameter names, defaults, enums, and return values, providing complete semantic meaning.

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

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

The description opens with 'CSG authoring' and clearly states it creates boolean shapes and sets their operations. It specifies resource types (box, sphere, cylinder, etc.) and differentiates from sibling tools like node_create by focusing on CSG-specific behavior.

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

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

The description explains the use case (carving holes/caves/tunnels in the editor) and gives guidance on grouping with CSGCombiner3D. It also directs users to node_set_property/material_manage for post-creation edits, but does not explicitly state when not to use this tool.

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

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

With no annotations provided, the description carries the full disclosure burden and does well: it reveals session-only scoping, that params are 'forwarded unvalidated' to the addon handler, batch incompatibility for deferred tools, and the flat-parameter compatibility alias. It stops short of covering error behavior for an unknown tool_name, a minor gap given the dynamic nature of the tools.

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 purpose is front-loaded and every paragraph earns its place (op semantics, batch interaction, alternative routing, call-shape alias). It is dense but not padded; the only minor inefficiency is repeating 'custom' terminology across closely-packed paragraphs that could be slightly tightened.

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 complex, dynamic tool with no annotations and zero schema coverage, the description covers purpose, both operations, parameter shape, batching constraints, alternative first-class registration, and call format. An output schema exists, so return-value omission is excused. It falls just short of perfect only by not describing failure modes for invalid tool names or session handling.

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 0%, so the description must compensate — and it does thoroughly. It explains the meaning of each op enum value, specifies that op='invoke' requires a tool_name string plus an optional params dict whose shape follows the params_schema returned by op='list', and even provides the canonical JSON call shape. This adds far more meaning than the bare 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 first line, 'List or invoke custom tools registered by third-party addons,' pairs specific verbs (list/invoke) with a specific resource (custom tools from third-party addons), unambiguously distinguishing it from the many sibling *_manage tools. The purpose is concrete and immediately usable.

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 explicit routing guidance: state when to use it, and name the alternative — 'Some custom tools are also registered first-class as custom_<name> with their own schema — prefer those when present.' It also sets preconditions ('Active session only') and constraints for the sibling batch_execute (deferred tools cannot run in batches).

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?

No annotations are provided, so the description carries the full burden—and it does: it discloses that quit() is graceful and next-frame, logs_clear returns counts and only clears the visible Debugger errors when explicitly requested, selection_set replaces the selection, and game_eval enumerates fast, actionable error codes including hung and oversized results. This is high-value behavioral disclosure beyond what the generic schema could convey.

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 long but organized with a summary, resource-form note, bulleted ops, and a canonical call shape. Each section adds needed information; it is front-loaded and scannable, though a little more trimming around resource-form vs op duplication would tighten it.

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 seven-op dispatcher with no annotations and a generic input schema, the description covers call shape, operation semantics, defaults, and error behavior thoroughly; an output schema exists so return-value details need not be repeated. It still leaves some contextual gaps such as session_id usage and explicit prerequisites for selection_set, but nothing critical for basic 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?

Schema coverage is 0% and params is only a free-form object, so the description is the only source of parameter meaning. It defines every operation signature, defaults, value types, and effects (paths list, monitors list or None, clear_debugger_errors boolean, code string), fully compensating for the schema gap.

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 compact enumeration of the tool's domains (selection, performance monitors, quit, log clearing, game eval) and then names each operation with a clear verb and target. It does not explicitly differentiate itself from sibling tools like editor_state or logs_read, so it stops short of a full 5.

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 provides concrete routing cues: resource forms are preferred for active-session reads, logs_clear requires opt-in for the user-facing Debugger dock, and game_eval explains retry conditions for EVAL_GAME_NOT_READY. However, it never explicitly names sibling tools or states 'use this tool when X instead of Y', leaving some alternation to inference.

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 no annotations, the description fully carries the behavioral disclosure burden. It openly states that a plugin-managed reload kills the server, drops the WebSocket transport, requires reconnect and session lookup, can time out after 90 seconds, and returns recovery diagnostics.

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

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

The description is longer than average but earns its length: it is front-loaded with a one-line purpose and then organized into clear bulleted modes. Every sentence conveys necessary operational detail, and the structure makes conditional behavior easy to parse.

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 high complexity and the absence of annotations, the description is remarkably complete: it covers both execution contexts, response shapes, timeout behavior, error semantics, and recovery steps. Nothing meaningful is missing for an agent to call and handle the result 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?

The single parameter session_id is already 100% covered by the schema, including its default and empty-means-active semantics. The description adds no additional parameter detail, but none is needed because the schema fully documents the parameter.

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?

States a specific verb and resource ('Reload the Godot editor plugin') and immediately defines the concrete behavior: disables and re-enables the plugin on the next frame. The two-mode breakdown further differentiates this from sibling maintenance 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?

Provides very clear execution context by explaining both launch modes and the expected response in each, which effectively tells an agent when this tool is appropriate. It does not explicitly name alternatives or exclusions, but the modal detail makes selection unambiguous.

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 no annotations, the description carries full burden and excels: it documents error shapes (EDITOR_NOT_READY, NODE_NOT_FOUND, GAME_HELPER_TIMEOUT), the stale_frame note for backgrounded games, camera selection fallback for cinematic, and return behaviors like include_image and AABB metadata.

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

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

The description is structured with a lead sentence, a guidance paragraph, a bulleted source list, and a closing note on parameters. Each section earns its place; the length is justified by the tool's four modes and ten parameters.

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

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

Given no output schema, the description explains what callers receive (MCP ImageContent, AABB metadata, error data) and covers edge cases (no scene, no 3D content, no Camera3D, game not running, backgrounded game). It is fully actionable.

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

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

Even though schema coverage is 100%, the description adds significant meaning: it explains that view_target takes comma-separated Node3D paths and reframes the editor camera, that coverage=True captures perspective + orthographic top-down references alongside AABB, and clarifies the behavior of include_image and default source.

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

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

The description opens with a specific verb+resource: 'Capture a screenshot of the Godot editor viewport or running game.' It clearly delineates four sources and is distinct from any sibling tool, so purpose is unambiguous.

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

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

It provides explicit source-selection guidance: default 'viewport' requires Node3D content, 'viewport_2d' for 2D scenes, 'cinematic' requires a Camera3D, and 'game' requires a running project. It also gives exclusionary constraints, e.g., 'viewport_2d' is 'Not compatible with view_target/coverage/elevation/azimuth/fov.' and advises switching to 'cinematic' under specific conditions.

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

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

With no annotations provided, the description fully discloses the side effect (refreshes session readiness cache), the non-mutating nature of the call, and nuanced field semantics like game_status.status='break' requiring a follow-up project_manage(op='stop'). No annotation contradictions.

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 long but extremely dense; every paragraph adds necessary operational details (resource form, adapter call conventions, side effect, field semantics). It is front-loaded with purpose and structured logically, though slightly longer than the minimum needed.

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?

Even with an output schema present, the description provides essential context the schema cannot: the resource form preference, cache-refresh side effect, adapter calling quirks, and the special 'break' state handling. Nothing an agent needs to call this correctly 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?

Schema coverage is 100% and the only parameter, session_id, is already well-documented in the schema ('Optional Godot session to target. Empty = active session.'). The description does not add further parameter guidance, but the schema fully covers it, 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 opening line states the verb ('Get'), the resource ('current Godot editor state'), and the key fields (version, readiness, open scene, play state). It clearly distinguishes from siblings like project_manage and scene_open by referencing the dedicated current-scene resource for that need.

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 says to prefer the resource form for active-session reads, names readResource('godot-ai', 'godot://scene/current') as the alternative for scene-only data, and gives a concrete recovery use case after EDITOR_NOT_READY. It also includes a 'never' instruction for server-prefixed tool names, so the agent knows exactly when and how to call this.

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?

No annotations are present, so the description carries full behavioral disclosure. It reveals side effects (write_text creates/overwrites and includes data.cleanup.rm for new files), caveats (reimport on non-imported paths reports skipped_non_imported and does not prove script validity), and concurrency behavior (scan is single-flight).

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

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

The description is structured as a bulleted list of ops with code formatting, making it scannable. Each paragraph provides essential details without redundancy, and even the longer reimport/scan entries contain only pertinent caveats and cross-references.

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

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

The tool exposes five distinct operations with different input/output behavior; the description covers all of them, including return fields, edge cases, and invocation shape. It also accounts for integration with sibling tools (script_patch, script_create, resource_manage) and global class_name registration, making it complete for an agent to select and invoke correctly.

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

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

The input schema only provides an opaque 'params' object, so the description is the sole source of parameter meaning. It lists each op's parameters with defaults and constraints, e.g., 'search(name="", type="", path="", offset=0, limit=100)' and 'At least one filter must be set'.

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

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

The opening line 'Project filesystem access via the Godot editor's EditorFileSystem' clearly identifies the tool's domain. Each listed op (read_text, write_text, reimport, scan, search) uses a specific verb and resource, and the description distinguishes the tool from sibling tools by focusing on filesystem operations rather than scene/script/project management.

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

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

The description explicitly contrasts this tool with alternatives: for scripts it says 'Use script_patch/script_create to save a script and receive fresh diagnostics' and for assets awaiting first import it says 'or scan...'. It also explains when scan is needed after adding class_name scripts, and notes write_text only does single-file updates, not a full scan.

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

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

With no annotations provided, the description carries the full burden and does an excellent job: it discloses focus-independent input behavior, the direct fallback limitation for suspend state synchronization, rejection of malformed positions, and frame-timing semantics. These are meaningful behavioral details beyond a simple operation list.

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 long but efficiently organized: a two-line summary, a scannable bullet list of operations with parameter details, and a brief canonical call-shape note. Each sentence serves a clear purpose, and the structure makes 13 operations easy to navigate.

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 multi-operation complexity, the description provides complete operational context: prerequisites, input methods, restrictions, and compatibility aliases. Since an output schema exists, omitting per-op return types is acceptable, and the description covers the remaining use context thoroughly.

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 generic (only op, params, session_id), so the description compensates thoroughly by documenting every operation's parameters, defaults, allowed values, and special cases such as position accepting an object or array.

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 precise summary—'Runtime game inspection and input simulation'—and names the specific resource (the running game via Godot's EngineDebugger bridge). It clearly distinguishes this tool from static scene/editor tools by focusing on runtime state and input.

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 explicit prerequisites ('Start the project first with project_run and poll editor_state until game_capture_ready=true') and explicit restrictions ('Cannot run inside batch_execute'). It also provides internal guidance such as using input_sequence instead of separate input_action calls when timing matters.

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 no annotations, the description carries full behavioral disclosure. It reveals that write operations are undoable via EditorUndoRedoManager, explains item=-1 erase semantics and orientation range 0..24, and specifies return structures for every operation. This is exemplary transparency.

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

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

The description is well-structured with a summary, a 'Ops:' bulleted list, and a closing canonical call-shape note. Each sentence adds value, and the bullet format makes complex multi-operation details easy to scan.

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

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

The description covers all five sub-operations with parameters and returns, the call shape, scene targeting, and undo behavior. Given the tool's complexity and lack of annotations, this is fully complete for agent invocation.

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

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

Schema description coverage is 0%, but the description fully compensates by documenting every operation's parameters (path, item, map coordinates, rect dimensions, orientation) and giving semantic details like valid item discovery and orientation index meaning. It adds far more meaning than the sparse schema provides.

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

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

The description opens with 'GridMap authoring (set items, fill 3D regions, clear, read cells + library items)', naming specific verbs and a concrete resource (GridMap nodes). It distinguishes itself from sibling 2D tile/tileset tools by explicitly focusing on 3D GridMap operations.

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

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

The description clearly states that all operations target GridMap nodes in the currently edited scene by scene-relative path, and it recommends using gridmap_list_library_items before placing cells. It doesn't explicitly exclude alternative tools, but the '3D analogue of tileset atlas inspection' note gives contextual differentiation from sibling 2D tools.

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

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

With no annotations, the description fully carries the burden of disclosure. It details persistence to project.godot, idempotency, removal of actions not loaded in live InputMap, validation of deadzone with VALUE_OUT_OF_RANGE, and clarifies that deadzone is not a key-repeat delay. It also explains the canonical call shape and flat parameter alias.

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

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

The description is long but well-structured with a clear list of operations and nested parameter details. It uses bullet points, code formatting, and concise explanations. Every sentence adds value, and the structure makes it easy to scan for specific operations.

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

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

Given the tool's complexity, the description covers all necessary aspects: all six operations, their parameters, return behavior (is_builtin field), error conditions, and persistence details. The output schema exists and the description complements it by adding behavioral context that structured data cannot convey.

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

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

Schema description coverage is 0%, so the description must fully document parameters. It does so extensively: for each op, it lists parameter meanings, types, formats (e.g., keycode as name string not integer), valid ranges (deadzone 0.0-1.0), and specific mappings (mouse buttons, JoyButton indices). This far exceeds mere schema information.

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

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

The description clearly states that the tool manages InputMap actions and bindings (keyboard, mouse, gamepad) and persists to project.godot. It lists specific operations (list, add_action, bind_event, etc.), distinguishing it from sibling tools like resource_manage or node_manage.

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

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

The description provides context like 'prefer for active-session reads' for the resource form and explains idempotency for ensure_* operations. However, it does not explicitly mention when to use this tool versus an alternative, though the specificity of InputMap operations makes the intended use clear.

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

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

With no annotations provided, the description carries the full burden, and it delivers extensively: buffer sizes (500/2000), retention across runs, boot-time parse errors never included, editor_errors_count/hint semantics, filtering rules, addons dropped, cursor superseding offset, and truncation behavior. This is exemplary behavioral disclosure.

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

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

The description is long, but every block earns its place given the tool's complexity and the absence of annotations. It is front-loaded with a one-sentence purpose, then structured into source categories and tail-pattern guidance. It is dense rather than padded, though slightly longer than strictly necessary.

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 return-field semantics (run_id, current_run_id, stale_run_id, dropped_count, editor_errors_hint), source-specific entry shapes, cursor/run lifecycle, edge cases like lost scripts, and polling patterns. Combined with the existing output schema, an agent has everything needed to invoke and interpret results 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?

Although the schema covers all 7 parameters (100%), the description adds substantial meaning beyond the schema: since_cursor supersedes offset, since_run_id reads retained prior runs, include_details returns Errors-tab metadata, and source determines entry shape. It transforms the parameters into a coherent replay/pagination model.

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: 'Read recent log lines from the Godot editor, plugin, or running game.' It then enumerates the exact source modes (plugin/game/editor/all) and the resource form, making the tool's scope unambiguous and clearly distinct from the unrelated sibling 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 explicit when-to-use guidance, e.g., 'Use when the editor Output or Debugger Errors panel shows red/yellow rows but other sources turned up nothing.' It also explains the default source, when to use since_run_id versus since_cursor, and how to poll game logs with offset and run_id. This is far beyond minimal 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?

No annotations exist, so the description fully carries the transparency burden, and it does so excellently. Each op lists its side effects: save to disk, assign to node, inline material creation, error when file exists unless overwrite=True, and one undo action for apply_to_node. The compatibility alias for flat parameters is also disclosed.

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

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

The description is long but extremely well-structured: it opens with the tool's scope, then uses bullet-pointed op signatures, and closes with a note on call shape. Every sentence carries necessary information for a multi-op tool, though a couple of lines could be tightened without losing value.

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

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

Given the tool's complexity (eight operations, many parameter combinations) and the generic schema, the description leaves no critical gaps. It covers all ops, their parameters, error semantics, resource-form usage, and edge cases. Since an output schema exists, the lack of return-value descriptions is appropriate.

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

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

The input schema only exposes op, params, and session_id with 0% coverage of actual parameters. The description compensates comprehensively by providing full pseudo-signatures for every operation, including defaults, enum values, and domain-specific rules like texture properties accepting res:// paths and enum-valued params accepting names.

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

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

The description clearly identifies the tool as a material authoring and management tool, listing specific material types (StandardMaterial3D, ORMMaterial3D, ShaderMaterial, CanvasItemMaterial) and eight concrete operations. It uses strong verbs like create, set_param, get, list, assign, apply_to_node, and apply_preset, making the tool's purpose very distinct from the vague 'material_manage' name.

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

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

It provides detailed per-operation guidance, including parameter signatures, valid types, and behavior like overwrite errors and undo grouping. It also notes the canonical call shape and a compatibility alias. However, it does not explicitly compare this tool to siblings like resource_manage, so alternatives are not discussed.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does disclose core behavior (creates, adds to parent, instantiates scene) and the mutual exclusivity rule. However, it omits potential side effects like modifying the scene file, needing to save, or error conditions. More transparency would be beneficial for a mutation tool.

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

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

The description is two sentences, front-loaded with the primary action, and contains no filler. It efficiently covers both modes of operation and the key interaction rule. A model of conciseness.

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

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

Given the 6-parameter tool with an output schema present, the description is reasonably complete. It explains the two modes and the parent relationship. It could mention error handling or save requirements, but the core behavior and parameter semantics are adequately covered, and the output schema handles return values.

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

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

All six parameters are fully described in the schema (100% coverage), so the baseline is 3. The description adds valuable parameter semantics by explaining that type and scene_path are mutually exclusive and that scene_path takes precedence, which is not stated in the schema. This pushes the score to 4.

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

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

The description opens with a specific verb+resource: 'Create (spawn) a new node in the scene tree.' It clearly distinguishes itself from sibling tools like node_find and node_set_property by focusing on creation, and further clarifies the two modes of operation (type vs. scene instantiation).

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

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

The description provides clear context for when to use the tool: when you need to create a new node or instantiate a PackedScene. It also offers a usage caveat about type/scene_path mutual exclusivity. However, it does not explicitly name alternatives or state when not to use this tool, so it stops short of a 5.

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

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

With no annotations, the description must disclose behavioral traits. It appropriately discloses that pagination is in effect and that filters are combined with AND, which are important semantics not present in the schema. It does not mention side effects or error conditions, but the read-only nature of 'Find' is reasonably implied.

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

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

The description is extremely concise, using two short sentences to convey purpose and core constraints. It is front-loaded with the action and resource, and every sentence adds value.

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

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

Given the tool's moderate complexity and the presence of a detailed output schema, the description adequately covers the key usage constraints (required filter, AND semantics, pagination) and purpose. It is complete enough for an agent to select and invoke this tool correctly, especially with the rich input schema.

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

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

Schema coverage is 100%, so the baseline is 3. The description does mention the three filter types (name, type, group) and pagination, but these are already fully documented in the input schema. It adds no extra nuance about parameter values beyond what the schema provides.

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

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

The description uses a specific verb 'Find' and identifies the resource 'nodes in the scene tree' with filters by name, type, or group. This clearly distinguishes it from siblings like scene_get_hierarchy, which lists the hierarchy, and node_get_properties, which inspects a specific node's properties.

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

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

It explicitly states the requirement 'At least one filter must be provided' and explains that filters AND together, giving clear usage constraints. It also mentions pagination, implying use of limit/offset for large results. However, it does not name alternative tools or specify when not to use this tool, so it falls short of a 5.

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

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

With no annotations, the description carries full burden. It thoroughly discloses behavior: default response size (50-150 entries), the meaning of count/total_count, handling of unknown fields, inclusion of null-valued properties, and script serialization details. This goes far beyond basic transparency.

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

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

The description is front-loaded with the purpose, then progressively adds detail. It is longer than minimal but every sentence adds value, with clear paragraph breaks for readability. No redundant or filler content.

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

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

The description covers edge cases (null values, unknown fields, script paths), response semantics, and performance considerations. While an output schema exists, the description still adds essential context that the schema alone would not provide, making it fully comprehensive.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaningful semantics beyond the schema by explaining how the fields parameter affects the response, the relationship between count and total_count, and the unknown_fields behavior, enriching parameter understanding.

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

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

The description opens with 'Get properties of a node,' using a specific verb and resource. It clearly differentiates from sibling tools like node_set_property (set) and node_find (search), making the tool's purpose unmistakable.

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

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

The description provides context for when to use this tool ('prefer for active-session reads') and offers performance guidance on using the fields filter. It does not explicitly exclude alternatives, but the mention of hot reads and filtering implies practical usage scenarios.

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

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

With no annotations, the description carries full burden. It discloses key behaviors: delete is undoable, cannot delete/duplicate scene root, rename has collision and character restrictions, reparent cannot move into descendants, and scene_file guard triggers EDITED_SCENE_MISMATCH. It also explains the canonical call shape and compatibility alias, offering rich behavioral context beyond the schema.

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

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

The description is long due to nine ops, but it is organized with headers, bullet lists, and a clear canonical call shape. Every sentence adds operational value—no filler. The structure makes it easy to scan and parse.

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

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

Addresses all ops, constraints, error conditions, read vs write behavior, resource forms, and call syntax. An output schema exists (likely for op results) but the description still covers return info for get_children and get_groups. For a complex multi-op tool with no annotations, this is comprehensively complete.

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

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

Schema coverage is 0%, so the description must define parameters. It lists the argument signature for every op (e.g., 'delete(path, scene_file="")') and explains the scene_file guard. However, it does not describe session_id's purpose beyond being 'top-level', and type details for path/index are inferred from naming rather than explicitly stated. This is a minor gap given the complexity.

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

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

The description opens with 'Node tree manipulation' and enumerates specific verbs (delete, duplicate, rename, reorder, reparent, groups) plus hierarchy reads. This clearly distinguishes it from sibling tools like node_create (creation), node_set_property (property changes), and node_find (search).

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

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

The description states a preference for resource forms during active-session reads and lists all ops explicitly. It does not explicitly contrast with sibling tools (e.g., 'use node_create for new nodes'), but the op list clearly implies the scope. The scene_file guard guidance adds usage context. A minor gap is lack of explicit when-not-to-use guidance.

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

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

No annotations exist, so the description carries the full burden, and it delivers: it discloses type coercion formats for Vector, Color, NodePath, Resource, StringName, and Array/Dictionary, and explains resource ownership, serialization as [sub_resource], and that null/'' clears. This is rich behavioral disclosure beyond the obvious 'setter' semantics.

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 front-loaded with the core action, then uses compact bullet-like sections for coercion and resource behavior. Every sentence adds operational value, and the organization makes the long content 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?

Covers the critical failure mode (PROPERTY_NOT_ON_CLASS), value clearing, resource lifecycle, sharing strategy, and serialization timing. With an output schema available to describe return values, nothing essential is missing for correct 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?

Although schema coverage is 100%, the description substantially extends the schema by explaining how to encode Godot property values (e.g., Vector3 dict keys, Color hex strings, res:// paths, __class__ resource creation). It also clarifies the path parameter's relative-to-scene-root meaning and property-name exactness.

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?

Opens with a clear verb+resource statement ('Set a property on a node'), then reinforces scope by contrasting with node_get_properties and giving Godot-specific examples. It is easily distinguished from sibling tools like node_create or node_manage.

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

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

Explicitly instructs the agent to verify property names with node_get_properties before writing, and explains when to use resource_manage(op='create') instead of inline resource creation for shareable resources. This gives concrete selection and sequencing 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?

With no annotations provided, the description takes full responsibility for disclosing behavior. It does this thoroughly: mentions that all write ops create nodes and sub-resources in a single undo action, that restart is runtime-only and not undoable, and that unknown override keys return INVALID_PARAMS rather than being silently dropped. It also details auto-creation of ProcessMaterial and QuadMesh, which is crucial for understanding side effects.

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

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

The description is long but every sentence carries specific technical content. It is well-structured with bullet points per operation, making it easy to scan. While it could be trimmed slightly (e.g., repeating 'auto-creates ProcessMaterial' for GPU emitters), the density of useful information justifies its length. It is front-loaded with the core purpose and then elaborates appropriately.

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

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

The description covers all operations, parameter semantics, error behavior, response reporting ('response reports applied_main / applied_process / applied_draw'), and cross-type constraints (GPU vs CPU, 2D vs 3D). It handles edge cases like overrides routing and invalid keys. Given the tool's complexity and the minimal schema, this description is exceptionally complete.

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

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

The input schema is minimal (op, params, session_id) with 0% schema description coverage. The description compensates magnificently by explaining every operation's parameters in detail, including property names, types, defaults, and per-type variations (e.g., 'GPU gravity requires {x, y, z} even for gpu_2d'). It also explains the canonical call shape and flat-op compatibility alias, providing meaning far beyond the schema.

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

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

The description opens with 'Particle systems (GPUParticles2D/3D, CPUParticles2D/3D)', immediately identifying the specific resource. It then enumerates all operations (create, set_main, set_process, etc.) with a clear verb for each, making it unambiguous what the tool does and distinguishing it from sibling manage tools like animation_manage or material_manage.

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

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

The description clearly implies when to use the tool: whenever particle emitters need to be created, configured, or restarted. It provides context for particle-specific behavior (e.g., GPU vs CPU, 2D vs 3D) and even notes edge cases like 'GPU gravity is a Vector3' and 'cpu_* types reject draw overrides.' However, it does not explicitly state 'use this instead of X' or provide exclusions versus sibling tools, so it falls slightly short of a 5.

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

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

With no annotations, the description carries the full behavioral burden and does so thoroughly: stop is idempotent and reports was_running=false; settings_set persists to project.godot and refuses a named list of keys; set_main_scene requires an existing res:// scene loadable as PackedScene and persists the change. It also discloses strict params validation and compatibility alias behavior.

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 organized with a header, resource-form note, per-op bullets, and a canonical call-shape summary, making it scannable. It is long, but the density is justified for a four-operation tool; the resource-form sentence is the least tightly integrated element and contributes to the length.

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 multi-op tool with no annotations, the description is complete: it covers all ops, parameter shapes, persistence behavior, refused keys, session handling, and call format, with an output schema available for return values. Nothing an agent needs to select or invoke correctly 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?

Schema description coverage is 0%, so the description must define parameter semantics, and it does: stop takes no params, settings_get takes key, settings_set takes key/value, and set_main_scene takes a res:// path. It also clarifies constraints like only registered keys being accepted and session_id being a top-level sibling.

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 enumerates four concrete operations (stop, settings_get, settings_set, set_main_scene) and names related tools, so an agent can tell what the tool manages. However, the opening line 'Project run/stop' is slightly imprecise because there is no operation to start/run a project (project_run is a sibling), which creates minor ambiguity until the op list is read.

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 explicit routing guidance: prefer resource forms for active-session reads, do not pass extra fields to stop, and use set_main_scene/autoload_manage(op='add') instead of settings_set for refused startup-execution keys. It also explains the canonical call shape and where session_id belongs, so an agent knows exactly when and how to invoke each op.

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 no annotations provided, the description carries the full burden and does so thoroughly. It discloses idempotency, waits briefly for the helper, defines all status values (not_live, no_helper, stopped, break), explains the implications of a break state, and advises on recovery. Autosave side effects are also mentioned. This is exceptionally transparent behavior disclosure.

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

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

The description is longer than average but every sentence adds essential information. It is well-structured with paragraphs for modes, idempotency, and response statuses. While the status explanation is detailed, it's necessary for correct interpretation. No fluff, but the length pushes the boundary of conciseness; still, it earns its place.

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

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

Given the tool's complexity (multiple modes, statuses, helper interaction, error states), the description is comprehensive. It covers edge cases like no helper autoload, break during boot with script errors, and late transitions via editor_state. The output schema exists, so return values are structured, but the description explains their semantics fully. This is a complete picture for an AI agent.

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

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

Schema coverage is 100%, and each parameter already has a description. The description adds extra context by explaining the meaning of mode values (e.g., custom requires scene), the autosave use case for smoke tests, and the role of session_id (though not explicitly named, the schema covers it). This adds value beyond the schema without redundancy.

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

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

The description clearly states the tool's purpose: 'Run (play) the Godot project from the editor.' It then lists specific modes (main, current, custom) and distinguishes from the sibling tool project_manage by explaining when to stop the project first. This is a specific verb+resource that stands out from siblings.

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

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

Explicit usage guidance is provided: when to use each mode, how to switch scenes (call project_manage(op="stop") first), and the optional autosave behavior for smoke tests. The description also explains what happens if the project is already running, guiding the agent on whether to stop first. This clearly differentiates when to use project_run vs alternatives.

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

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

With no annotations, the description carries the full transparency burden and does so thoroughly: it notes undoable operations, read-only calls, auto-creation of resources, bounded work limits, refusal conditions, one-undo-action batching, and candidate paths in error data. It also discloses return shapes for key operations such as physics_shape_generate.

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 long but well-structured with a clear purpose statement, bulleted operations, and a canonical call-shape note. Each operation is compactly specified with relevant constraints and options, and the length is justified by the number of distinct resource operations covered.

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 broad scope of 11 operations and minimal schema coverage, the description is complete enough for an agent to select and invoke the correct operation. It includes required filters, shape-type mappings, preset names, return flags, undo behavior, and boundary conditions for complex operations.

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 only defines op, params, and session_id with 0% coverage, so the description must explain all parameters and does so extensively per operation. It documents each operation's parameters, defaults, accepted enum-like values, and the distinction between assigning to a property versus saving to a resource_path.

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 resource management as a multi-operation tool covering search, inspection, assignment, creation, and specialized authoring. It names concrete operations and distinguishes specialized resource families (Curve, Environment, shapes, textures) from generic resource handling.

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 explicit guidance for when to use dedicated operations (e.g., preferring curve_set_points, environment_create, physics_shape_*) over generic create, and explains canonical call shape and flat alias compatibility. It does not explicitly contrast with sibling node/scene/material tools, but internal usage boundaries are clear.

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 no annotations, the description carries the full burden. It discloses that the return is a paginated flat list with specific fields (name, type, path, child count), that it walks to a specified depth, and that it operates on the active scene. This gives good behavioral insight, though it doesn't explicitly state read-only or error behavior.

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

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

The description is two sentences plus a resource form line, with the core purpose stated first. Every sentence adds value and there is no redundancy or filler.

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

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

Given the output schema and fully documented parameters, the description covers the key behavioral aspects (pagination, depth, flat list, active scene). It doesn't mention error handling or explicit read-only safety, but those are less critical for a get-style tool with an output schema.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds context by explaining the result is a paginated flat list and that depth controls walk depth, but this largely restates what the schema already provides. It does not significantly extend parameter understanding beyond the schema.

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

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

The description states 'Get the scene tree hierarchy from the open scene' with a specific verb and resource, and clearly distinguishes from sibling tools like node_find by focusing on the full hierarchy rather than searching. The resource form adds further specificity.

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

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

The description says 'prefer for active-session reads', providing clear context on when to use the resource form. However, it does not explicitly name alternative tools or state when not to use it, so exclusions are missing.

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

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

With no annotations, the description carries the full burden, and it does well: it discloses that create writes the initial root immediately but later mutations remain in editor memory until scene_save or save_as, that save_as writes to a new path, and that get_roots flags the edited scene. It also documents the canonical call shape and the flat-parameter compatibility alias.

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 well structured: a one-line summary, a resource-form note, a concise list of ops, and then call-shape details. Each section earns its place and there is no redundant restating of schema fields.

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 multi-op authoring tool with no annotations, the description covers the key operational differences, persistence behavior, and call shape. It does not discuss edge cases such as overwrite behavior when saving to an existing path or invalid root_type values, but the output schema covers return expectations.

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 0%, so the description compensates by defining create(path, root_type='Node3D', root_name=''), explaining root_name defaults to filename basename, and listing save_as(path) and get_roots(). session_id is not semantically explained, but the core parameters are well covered.

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 'Scene authoring (create, save_as, list open roots)', which names specific verbs and the resource domain, and each operation is individually explained. It is clear what the tool does, though it does not explicitly compare itself to closely related siblings like scene_save or scene_open.

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

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

The description gives one concrete usage exclusion: 'prefer for active-session reads' for the godot://scene/current and godot://scene/hierarchy resource forms. It does not explicitly explain when to choose scene_manage over scene_save or scene_open, so guidance is present but not fully comprehensive.

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 no annotations, the description fully carries the behavioral burden. It discloses that force_reload discards unsaved in-memory edits, that the reply is sent only after the switch lands, and describes the two non-success paths (switched:false with settle timeout or not_waited) with a recommendation to re-check editor_state. This is exemplary.

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

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

The description is dense but efficiently structured. The first sentence gives the purpose, the second paragraph explains edge cases and force_reload, and the third covers reply timing and safe write conditions. Every sentence contributes to decision-making, with no fluff or redundancy.

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

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

For a tool with moderate parameters and significant behavioral nuance, the description covers all critical aspects: synchronous vs asynchronous behavior, timeout semantics, discard behavior, and follow-up safety. An output schema exists, so return values are handled elsewhere. This is fully complete for an agent to use correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds substantial meaning: it gives a concrete path example (res://main.tscn), explains the no-op default, and details the force_reload parameter's destructive semantics (discarding unsaved edits). It also clarifies the interaction between path, force_reload, and settle behavior, going well beyond the schema.

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

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

The description opens with a specific verb and resource: 'Open an existing scene file (.tscn) in the editor.' This clearly identifies the tool's function and distinguishes it from siblings like scene_save or scene_manage. The .tscn extension and 'existing scene file' add precision.

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

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

Provides strong contextual guidance: explains the no-op behavior when the path is already the current scene, instructs when to use force_reload, and clarifies the reply timing and settle semantics. It does not explicitly name alternative tools or state when-not-to-use, but the context is unambiguous and actionable, missing only a direct comparison to siblings.

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

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

With no annotations, the description carries the full behavioral burden. It discloses that the tool writes the in-memory scene to disk and targets the 'existing path,' implying overwrite. It could be more explicit about destructive overwrite or prerequisites, but it is substantially transparent for a simple save operation.

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 no filler. The main purpose is front-loaded in the first sentence, and the second sentence earns its place by explaining when and why to call the tool.

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 low-complexity tool with one optional parameter and an output schema, the description covers the core workflow well: after mutations, save to the existing path. Some edge context such as overwrite warning or needing an open scene is not explicit, so it is strong but not fully 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% for the only parameter, session_id, and the schema already documents 'Optional Godot session to target. Empty = active session.' The description adds no parameter-specific meaning, but the baseline of 3 applies when the schema handles parameter semantics.

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: 'Save the currently edited scene to disk.' It also distinguishes this tool from sibling mutation tools by explaining that node/property mutations only alter the in-memory scene, while scene_save persists them.

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 says when to call the tool: after node/property mutations, 'call this explicitly to persist those mutations to the existing path.' This is clear contextual guidance, though it does not name specific alternatives or explicit when-not-to-use conditions, so it falls just 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?

In the absence of annotations, the description appropriately discloses the key destructive behavior ('Replaces any existing script') and assures undoability. This goes beyond minimal and covers the most impactful side effects, though it omits details like permission requirements or session behavior.

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

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

The description is two concise sentences. It front-loads the primary action and immediately states the crucial caveat, with no filler or redundancy.

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

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

For a simple tool, the description covers the core purpose, the replacement behavior, and undoability. An output schema exists, so return details are likely covered elsewhere. It might benefit from mentioning node existence validation, but overall it is sufficiently complete for its complexity.

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

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

Schema description coverage is 100%, with detailed parameter descriptions and examples. The description does not add any extra parameter-level semantics beyond what the schema already provides, so it earns the baseline score of 3.

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

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

The description uses a specific verb ('attach') and identifies the resource ('script' to a 'node'), making the tool's purpose unmistakable. It clearly distinguishes from sibling tools like script_create or script_patch by focusing on the act of attachment.

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

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

The context is clear: this tool is for attaching a script to a node. The phrase 'Replaces any existing script' hints that it can also be used to swap scripts. However, it does not explicitly mention alternatives or exclusion cases, so it falls short of a 5.

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

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

With no annotations, the description carries full burden for behavior disclosure. It explicitly mentions overwrite behavior, filesystem scan triggering, and the sidecar listing in data.cleanup.rm. This is substantial, though it omits permission/session context.

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

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

The description is three sentences, front-loaded with a clear purpose, and every sentence contributes behavior or side-effect information. No filler or redundancy.

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

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

Given the moderate complexity and the presence of an output schema, the description is complete enough: it covers core functionality, overwrite semantics, and side effects. Minor gaps exist around session targeting and alternative tool guidance, but these are not critical.

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

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

The input schema already provides 100% coverage for all three parameters, including descriptions for path, content, and session_id. The description adds no parameter-specific detail beyond this, so baseline 3 is appropriate.

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

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

The description clearly states the tool creates a .gd file on disk, explicitly naming the resource type and the action. It also distinguishes from siblings like script_patch by focusing on creation rather than patching.

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

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

The description implies use for creating new GDScript source files, but it does not explicitly state when to prefer this over alternatives like script_patch or script_manage. There are no clear exclusions or when-not-to-use notes.

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

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

With no annotations provided, the description carries the burden of disclosing behavior. It notes that detach is undoable, reveals what read returns (source, line count, file size), and explains the canonical call shape and compatibility alias. It does not mention permissions or error behavior, but the provided details are useful and non-contradictory.

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

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

The description is well-structured with a clear opening, a bulleted list of ops, and a code block for call shape. Every sentence contributes useful information, and the front-loaded purpose statement makes the tool's intent immediately clear.

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

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

Given the presence of an output schema, the description covers what is needed: operation semantics, resource path format, canonical invocation, and compatibility alias. It is complete for a dispatch-style tool with three ops, and the output schema likely handles return-value documentation.

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

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

Schema coverage is 0%, so the description must compensate. It explains the op enum, the params object, and session_id placement, and shows path as a parameter for each operation through signatures like read(path). This adds meaning beyond the bare schema, though it could be more explicit about required parameter fields per op.

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

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

The description clearly identifies the tool as managing .gd scripts via three specific operations (read, detach, find_symbols), using specific verbs and resources. It effectively distinguishes itself from sibling tools like script_create, script_patch, and script_attach by focusing on read/detach/outline rather than creation or modification.

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

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

It provides clear context on when to use the resource form (prefer for active-session reads) and lists the available operations with their purpose. It does not explicitly mention when not to use this tool versus alternatives, but the op-level descriptions and the resource form guidance give adequate usage direction for most cases.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states failure modes (multiple/zero matches), exact byte matching, whitespace significance, filesystem scan behavior, in-place reload of loaded scripts, the reloaded/reload_reason response signal, and non-undoability. This is exemplary transparency.

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

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

The description is compact, front-loaded with the core purpose, and every sentence adds essential operational detail. There is no filler, repetition, or unnecessary context. It fits substantial behavioral information into a tight structure.

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 modest complexity, full schema coverage, and an output schema, the description is complete. It covers matching behavior, failure conditions, side effects on loaded scripts, response hints, and undoability. An agent has enough context to invoke the tool correctly and anticipate 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%, so the baseline is 3. The description adds meaning beyond the schema by explaining the uniqueness requirement for old_text, the replace_all fallback, the exact-match/whitespace-sensitive semantics, and the reload consequence of a patch. This exceeds the schema's simple property 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 opens with a clear verb and resource: 'Anchor-based string-replace edit on a .gd file.' It further specifies the exact operation (find old_text, replace with new_text) and distinguishes this from siblings like script_create or script_manage by focusing on in-place patching.

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 situates the tool as an editing operation on existing GDScript files, with detailed constraints about matches and reload behavior. It does not explicitly name alternatives or exclusion conditions, but the intended use case is strongly implied and unlikely to be confused with creation or management 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?

The description explains behavior beyond simply stating the function: exact ID matches always win, substring matches must resolve to exactly one session, and ambiguous matches return an error with candidates. This is valuable because no annotations are provided.

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 and well-structured. It front-loads the purpose, then explains input matching rules in clear, minimal sentences with 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 single-required-parameter tool with an output schema, the description fully covers what the tool does, how input is interpreted, and the error behavior for ambiguous matches. 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?

Schema coverage is 100%, so the baseline is 3, but the description adds meaningful matching semantics: the exact versus substring matching behavior and the fields matched (short name, project_path, session_id). This goes beyond the schema's parameter description.

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 specific action: 'Set the active Godot editor session for subsequent tool calls.' This distinguishes it from session_manage and other session-related operations, making the tool's role immediately understandable.

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 phrase 'for subsequent tool calls' gives clear context for when the tool should be used, but there is no explicit guidance on when to use this versus session_manage or other session operations. No alternatives or exclusionary conditions 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a read-only operation through the verb 'list' and lists the exact metadata fields returned. It also discloses the server-global 'exclude_domains' behavior, adding context beyond a simple list call. It stops short of explicitly stating 'no side effects', but the listing semantics are clear.

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

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

The description is organized with a short opening, a resource form note, a bulleted op section, and a protocol note. It is front-loaded with the core purpose. There is minor redundancy ('Session listing' vs. 'List every connected Godot editor'), but the overall structure is efficient and scannable.

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

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

Given the tool's simplicity (only a 'list' op) and the presence of an output schema, the description is largely complete. It details the response metadata and server-level 'exclude_domains' information, and it explains the calling convention. It could be more explicit about whether session_id is relevant for list(), but overall it covers what an agent needs to invoke the tool correctly.

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

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

The schema coverage is 0%, so the description must compensate. It explains the canonical call shape ('{"op": "<verb>", "params": {...}}') and clarifies that flat op parameters are accepted as an alias, while 'op' and 'session_id' remain top-level. This adds meaning beyond the raw schema by describing how parameters are structured and transmitted.

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

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

The description opens with 'Session listing' and then explicitly states 'List every connected Godot editor with metadata', giving a specific verb+resource. It clearly distinguishes this session listing tool from siblings like session_activate by focusing solely on the list operation, which the input schema enforces via the 'list' const.

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

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

The description provides clear context for when to use the tool: to list all connected editors. It also offers an explicit usage preference: 'Resource form: godot://sessions — prefer for resource-aware clients.' While it doesn't explicitly discuss alternatives or exclusions, the context is clear and the single allowed operation makes usage unambiguous.

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

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

With no annotations, the description carries the behavioral disclosure burden. It adds meaningful detail: connect/disconnect are undoable, list filters out editor-internal connections by default but can surface them, and the response includes editor_connection_count. This goes beyond bare operation names, though it does not discuss permissions or error behavior.

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

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

The description is well-organized with a brief intro, three bullet-pointed operations, and a compact call-shape note. Every sentence provides useful information, and the structure makes the multi-op behavior easy to parse without unnecessary verbosity.

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

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

The description covers all operations, their parameter semantics, and key behaviors like undoability and default filtering. Since an output schema exists, return-value specifics are not required. It could briefly mention error conditions or signal name requirements, but the provided information is sufficient for most use cases.

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

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

Schema description coverage is 0%, so the description must compensate fully, and it does. It names and explains each relevant parameter (path, include_editor, signal, target, method) within the operation snippets and clarifies the canonical call shape with op and params. This adds substantial meaning beyond the generic schema.

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

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

The description identifies signals as Godot's event/observer mechanism and enumerates the three operations: list, connect, and disconnect. This is a specific verb+resource statement that clearly distinguishes this tool from the broader sibling set.

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

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

Each operation is described with its intended use case: listing signals with optional editor-internal inclusion, connecting a signal to a target method, and disconnecting an existing connection. It does not explicitly name alternatives or exclusions among sibling tools, so it falls short of a 5.

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

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

With no annotations, the description carries the transparency burden. It discloses that the tool only re-fetches the most recent payload, does not re-execute tests, and that verbose=True expands individual result details. This clearly signals a non-mutating inspection operation.

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

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

The description is compact and well-structured: purpose, resource form, operation list, and call shape are each clearly separated. Every sentence contributes operational value, and the purpose is front-loaded.

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

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

The output schema covers return structure, so the description does not need to detail responses. It adequately covers purpose, usage, and core parameter semantics for a one-op tool. The only noticeable omission is session_id semantics, but this is a minor gap given the overall clarity.

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

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

The schema has 0% description coverage, so the description compensates by explaining the core parameters. It documents the canonical call shape, constrains op to results_get, and describes the verbose flag within params. However, session_id is only mentioned as top-level without explaining its meaning, leaving a small gap.

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

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

The description opens with 'Test result inspection (re-fetches the most recent test_run payload)', using a specific verb and resource. It clearly distinguishes this from the sibling test_run by emphasizing 'no re-execution' and positioning it as a read-oriented tool.

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

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

It says 'prefer for active-session reads', giving clear context for when to use this tool. It also notes that it returns 'full results from the last run, no re-execution', implying it is the right choice when results are needed without rerunning tests. It does not explicitly list exclusions or alternatives, but the guidance is still useful.

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

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

Discloses several behaviors: caching issues (preload cache), timeouts (300s budget), potential session drop, return of partial summaries, and warnings. This gives the agent a clear picture of side effects and failure modes.

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

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

The description is lengthy and repeats some information (e.g., response includes edited_scene). While it provides valuable details, it could be more concise. However, it is structured into paragraphs and fronts the main 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 description covers important operational context: timeouts, cache, scene requirements, and restrictions. Given the tool's complexity, it is fairly complete. Output schema exists so return values are not described, which is acceptable.

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 descriptions cover all parameters comprehensively. The tool description adds context for 'verbose' and 'suite' but doesn't explain test_name, session_id, exclude_test_name. Since schema coverage is 100%, the description doesn't need to repeat, but it does not add much beyond.

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 purpose: running GDScript test suites in the Godot editor and describes what it does (discovers, instantiates, runs). It also mentions the default behavior and verbose option, making it distinct from other 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?

Provides guidance on when to use: it mentions restrictions like 'Not allowed inside batch_execute', advice to restart editor for cache issues, and suggests opening the main scene. It also points to test_manage for full partials. However, it doesn't explicitly contrast with other test-related tools beyond that.

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 no annotations provided, the description carries the full burden of behavioral disclosure. It explains cascading behavior when applying a theme, that an empty theme_path clears, and includes overwrite semantics for create. It also clarifies parameter formats for color values, which adds useful context beyond what the schema provides.

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

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

The description is lengthy but well-structured, using a bulleted list of operations that makes it scannable. Every sentence adds value, though the density of options might be slightly overwhelming, but it remains appropriately sized for a tool with six distinct operations.

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

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

Given the complexity of the tool with six operations and many optional parameters, the description is thorough. It covers all operations, parameter shapes, session targeting, and even a note on compatibility, making it complete for an agent to select and invoke correctly. The output schema exists, so return value details are not required.

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

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

Schema description coverage is 0%, and the description fully compensates by detailing each operation's parameters, including supported value formats like colors, integers, and stylebox options. It also explains optional parameters for set_stylebox_flat and the compatibility alias for flat op parameters, providing rich meaning beyond the bare schema.

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

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

The description clearly states it is for Theme authoring in Godot, a stylesheet-like resource for Controls. It lists specific operations (create, set_color, set_constant, set_font_size, set_stylebox_flat, apply) with distinct verbs and resources, making it easy to differentiate from sibling tools like ui_manage or resource_manage.

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

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

The description explains the canonical call shape (op plus params dict) and notes the session_id wrapper for targeting a specific editor. It implies when to use the tool (theme editing) but does not explicitly mention alternatives or when not to use it, so it falls short of perfect guidance.

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

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

With no annotations provided, the description fully carries the burden of disclosing behavioral traits. It reveals that all write ops are undoable, explains the critical source-ID remapping caveat for specialized .tres files, details the canonical call shape and flat-parameter alias, and lists return values for each op. This is exceptionally transparent and goes beyond what annotations would typically provide.

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

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

The description is well-organized: a one-line summary, a brief scope statement, an important warning box, and a bulleted list of operations with parameters and returns. Despite being long, every section earns its place with critical information, and the structure makes it easy to scan. No fluff or repetition.

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

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

Given the tool's complexity (four operations, a tricky source-ID remapping rule, and an alias call shape), the description is complete. It explains all operations, parameters, returns, and edge cases. The existence of an output schema does not make the description redundant because the description also details each operation's specific return structure, which is more granular than a generic schema.

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

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

The input schema is minimal: only op, params (free-form object), and session_id with 0% parameter description coverage. The description compensates comprehensively by defining each operation's parameters (path, source_id, atlas_col, atlas_row, map_x, map_y) and their meanings, plus return shapes. It adds substantial semantic value beyond the schema.

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

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

The description opens with a specific verb and resource: 'TileMap / TileMapLayer authoring (set tiles, fill rects, clear, read cells).' It clearly distinguishes itself from siblings like tileset_manage by targeting TileMapLayer nodes and enumerates four concrete operations. This is unambiguous and fully differentiates the tool's purpose.

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

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

The description provides clear context: operations target TileMapLayer nodes in the currently edited scene by scene-relative path, and all write ops are undoable via EditorUndoRedoManager. It implicitly tells when to use the tool (for authoring tilemaps) but does not explicitly name alternatives or exclusion conditions, so it falls short of a 5.

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

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

With no annotations provided, the description carries the full burden and exceeds expectations. Each op explicitly states 'Read-only — does not modify any resource or project file' and the image op adds 'reads the texture directly from the resource without any UI interaction.' It documents error codes, return formats, and the max_size scaling behavior. This is exemplary behavioral disclosure.

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

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

The description is long but meticulously structured with bullet points, consistent formatting, and a clear top-level summary. Each sentence earns its place—the repeated error code lists are justified for self-contained ops. The front-loaded 'TileSet management — atlas inspection tools' immediately orients the reader.

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

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

For a two-op dispatcher, the description is comprehensive: it covers purpose, parameters, return values, error codes, the canonical call shape, and usage guidance. The output schema isn't shown, but the return structures are documented in text. The tool's complexity is fully addressed.

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

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

The input schema is generic with 0% parameter description coverage, but the description fully compensates by documenting every operation-specific parameter: names (tileset_path, source_id, max_size), types, required status, and defaults. It also explains return structures and error codes. This provides complete semantic meaning beyond the schema.

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

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

The description clearly identifies the tool as 'TileSet management — atlas inspection tools' and enumerates two specific operations with precise verbs: 'Return all occupied atlas tile positions' and 'Return the atlas sprite-sheet texture'. This distinguishes it from sibling tools like tilemap_manage and editor_screenshot by focusing on read-only TileSet atlas inspection.

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

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

The description gives an explicit usage recommendation: 'To visually inspect what tiles look like, use tileset_get_atlas_image instead of editor screenshots. It reads the texture directly from the resource — no UI interaction or editor state required.' This directly contrasts with a sibling tool. It also repeatedly states read-only behavior, implying when to use. However, it does not explicitly mention when not to use the tool or alternatives for the tiles query.

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

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

Given no annotations, the description carries the full burden. It discloses atomicity ('Atomically build'), validation ('Validates everything before mutating'), error conditions ('which errors'), and compatibility aliases for parameters. Could not mention return values, but an output schema exists.

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

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

Clearly structured with a one-line summary followed by bulleted ops with signatures and examples. Every sentence provides necessary detail (e.g., margin=0, theme_override_constants example) with no fluff or redundancy.

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

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

Covering four distinct operations with constraints, pitfalls, and integration notes, the description is thorough for a UI authoring tool. It addresses canonical call shape and session_id handling, and the output schema likely covers return specifics. Minimal gaps for its complexity.

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

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

The schema's params object is generic (0% coverage), so the description fully compensates by documenting each operation's parameters with names, types, defaults, enums, and examples. For instance, set_anchor_preset lists all preset values and resize_mode options.

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

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

The description clearly states the tool's purpose: 'UI / Control authoring (HUD, menus, layouts, vector decoration).' It enumerates four distinct operations (set_anchor_preset, set_text, build_layout, draw_recipe) with concrete details, distinguishing it clearly from sibling tools like node_manage or scene_manage.

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

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

Provides strong contextual guidance for specific operations, e.g., the note that CanvasLayer is not a Control and to apply presets to a Control child, and the warning about theme_override_constants vs direct properties. It does not explicitly name alternative tools, but the UI-specific scope is clear.

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