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 clearly discloses that the tool writes/removes client config files, lists the ops, and explains the call shape including compatibility aliases. It does not mention potential side effects like overwriting existing entries or requiring specific permissions, but it covers the main behaviors.

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

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

The description is well-structured with clear sections for ops, call shape, and compatibility. It is concise despite the detail, using bullets and examples effectively. Every sentence adds value.

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

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

Given the tool's complexity (multiple ops, various clients, call shape flexibility), the description is thorough. It explains the output of status(), the actions of configure/remove, and the compatibility alias. The presence of an output schema means return values need not be detailed, and the description covers the essential usage context.

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

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

Schema coverage is 0%, so the description compensates by explaining the op enum values and their expected parameters (e.g., 'client' is one of the ids from status()). It also explains the canonical call shape and flat parameters alias. However, it does not detail the 'params' object structure beyond the client field or explain session_id.

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

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

The description clearly states the tool's purpose: configuring AI clients to use the MCP server by writing/removing client config files. It lists supported clients and differentiates from sibling tools which focus on scenes, resources, sessions, etc.

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

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

The description provides clear context for when to use the tool (to set up AI clients) and details the ops (status, configure, remove) with explanations of each. It does not explicitly state when not to use it or name alternative tools, but the scope is well-defined.

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

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

With no annotations, the description carries the full burden and excels. It discloses behavior such as 'quit() gracefully quit the Godot editor on next frame', logs_clear returning cleared_count, the opt-in nature of clearing debugger errors, and the subtle 'await only progresses while the game window is focused'. It also explains all game_eval error codes in detail. No contradictions with annotations exist (none provided).

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

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

The description is long but elegantly structured: a summary line, resource-form note, bulleted operation list with details, and call-shape explanation. Every sentence earns its place; the length is justified by the multiple operations and error cases covered. It front-loads the core purpose and follows with specifics.

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

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

Given the tool has six operations, no annotations, no parameter descriptions in schema, and only a sparse input schema, the description is impressively complete. It covers return values for logs_clear, all game_eval error conditions, and operational nuances. The presence of an output schema covers basic return structures, so the description need not repeat those; no critical gaps remain.

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

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

Schema description coverage is 0%, so the description fully compensates by documenting each operation's parameters inline (selection_set(paths), monitors_get(monitors=None), logs_clear(clear_debugger_errors=False), game_eval(code)). It also clarifies the canonical call shape ({'op': '<verb>', 'params': {...}}) and the flat-parameter alias, which adds meaning beyond the raw schema.

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

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

The description opens with 'Editor selection, performance monitors, quit, log clearing, game eval' and then enumerates specific operations with verbs (state(), selection_get(), selection_set(), etc.), making the tool's purpose crystal clear. It distinguishes from siblings like editor_state (which likely reads state only) and logs_read (separate tool) by covering management actions beyond simple reads.

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

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

The description explicitly recommends 'Resource forms (prefer for active-session reads)' for state/selection/performance, guiding when to use the alternative resource-based access. For game_eval, it details when to retry (EVAL_GAME_NOT_READY) and when not to (EVAL_HUNG). However, it does not explicitly compare to each sibling tool, so it lacks full exclusionary guidance.

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

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

With no annotations, the description fully discloses side effects: it kills the server in plugin-managed mode, drops the WebSocket transport, and can raise PLUGIN_DISCONNECTED on timeout. It also explains recovery steps and response shape differences, going well beyond basic expectations.

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

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

The description is front-loaded with the core purpose, then uses bolded mode sections and bullet-like details to convey complex transport behavior efficiently. Every sentence carries necessary operational information without fluff.

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

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

For a tool with dangerous side effects and no annotations, the description covers both execution modes, return payloads, timeout behavior, error code, and recovery diagnostics. It is sufficiently complete given the optional single parameter and existing output schema.

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

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

Schema coverage is 100% for the single optional session_id parameter, so baseline is 3. The description does not add additional parameter context, but the schema already states it targets a Godot session and defaults to active session.

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

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

The description opens with 'Reload the Godot editor plugin' — a specific verb and resource. It further clarifies the mechanism ('Disables and re-enables the plugin on the next frame'), clearly differentiating it from sibling editor management tools.

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

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

Provides detailed context for both launch modes and expected response behavior, including reconnect guidance and timeout diagnostics. However, it does not explicitly name alternatives or state when not to use this tool relative to siblings like editor_manage or session_manage.

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

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

No annotations are provided, but the description compensates with extensive behavioral detail: the EDITOR_NOT_READY error shape, stale_frame flag for backgrounded game windows, GAME_HELPER_TIMEOUT meaning, and the guarantee that AABB metadata is always returned. It also discloses that include_image=True yields an MCP ImageContent block.

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

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

The description is long but tightly packed with essential information, structured with a lead paragraph and a bullet-like source list. No filler sentences; each clause addresses a distinct scenario or parameter behavior, and the most important usage guidance is front-loaded.

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

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

Given the tool's complexity (four sources, nine parameters, no annotations, no output schema), the description covers error states, metadata, source fallbacks, and parameter interplay, providing an agent with enough context to select and invoke the tool correctly. The only minor omission is an explicit description of the success response shape beyond the optional image block, but AABB metadata is covered.

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

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

The input schema already covers all nine parameters, so the description's extra value is selective but meaningful. It enriches source semantics with per-source behavior and caveats (e.g., viewport_2d incompatibility with other parameters), clarifies view_target's camera reframing, and specifies the format for include_image. Some parameters like fov and azimuth receive no additional description, so a 4 rather than 5 is appropriate.

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

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

The description opens with a specific verb-resource statement—'Capture a screenshot of the Godot editor viewport or running game'—and then enumerates four distinct sources. This clearly distinguishes the tool's purpose from sibling tools that manage scenes, projects, or cameras. No other sibling appears to provide screenshot functionality.

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

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

It provides explicit source-selection guidance: viewport_2d is recommended for 2D scenes, viewport for 3D, cinematic for active Camera3D, and game for a running project. It also gives corrective advice for error states, e.g., 'switch to cinematic if the scene has a Camera3D, or open a scene with 3D content.'

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

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

With no annotations, the description fully carries the burden. It discloses a side effect (refreshes server's readiness cache), explains when that side effect is useful, and details special game_status.status values including 'break' and the need to call project_manage(op="stop").

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

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

The description is multi-paragraph but tightly organized: purpose, alternative invocation, side effect, response-field clarifications, and special statuses. Each section earns its place with no redundancy.

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

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

Given the tool's complexity—state retrieval, cache synchronization, response interpretation, and special break behavior—the description covers all needed context. Since an output schema exists, return format details are not required.

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

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

The only parameter session_id is already fully described in the schema ('Optional Godot session to target. Empty = active session.'). The description adds no additional parameter-level meaning, so the baseline of 3 applies.

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

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

The description opens with 'Get current Godot editor state' and enumerates specific contents (version, readiness, open scene, play state). This clearly differentiates it from sibling management/mutation tools.

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

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

It explicitly states 'prefer for active-session reads', notes the alternative editor_manage(op="state") for clients wanting a single tool, and gives a concrete recovery scenario after EDITOR_NOT_READY. This is strong when-to-use guidance.

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

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 present, the description carries the full burden of behavioral disclosure. It reveals important traits: 'A present but malformed position is rejected rather than silently falling back to the cursor,' 'Action-based input is focus-independent, so it works on a backgrounded game window,' and 'Cannot run inside batch_execute.' It also describes replies, state reads, and the effect of each op on the running game.

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

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

The description is long but appropriately structured: a one-line summary, a prerequisite note, then a consistent bulleted list of ops with syntax and parameter details. The canonical call shape paragraph adds useful invocation context without redundancy. Every sentence provides valuable information; nothing is wasted.

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

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

For a tool with nine sub-operations, a minimal schema, and no annotations, this description is remarkably complete. It covers prerequisites, parameter semantics, timing and ordering constraints, return metadata (e.g., 'Includes path, type, text where present'), and usage exclusions. An agent can confidently select the right op and invoke it correctly without additional information.

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

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

The input schema only defines an `op` enum and a generic `params` object with additionalProperties true, offering zero parameter descriptions. The description compensates fully by detailing every parameter for each operation, including types, defaults, and constraints such as get_scene_tree's root_path behavior, input_mouse's position format and malformed-value handling, and input_sequence's step ordering requirement.

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

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

The description opens with 'Runtime game inspection and input simulation,' which is a specific verb+resource statement that clearly distinguishes this tool from sibling tools like editor_manage or scene_manage. It then enumerates nine distinct operations with clear names and one-line purposes, leaving no ambiguity about what the tool does.

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

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

It explicitly states the prerequisite: 'Start the project first with project_run and poll editor_state until game_capture_ready=true.' It also provides usage guidance within the tool, e.g., 'Use this instead of separate input_action calls whenever timing matters' and 'Cannot run inside batch_execute,' which tells the agent when to use this tool and when not to.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states the tool is read-only, bounded, and live, and transparently explains that partial component failures are labeled rather than hidden. This goes beyond minimal disclosure and sets accurate expectations for a non-mutating snapshot.

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

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

The description is two sentences: the first states the core purpose and nature, the second enumerates the snapshot components and error handling. Every sentence earns its place, with no wasted words or redundant phrasing.

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

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

Despite the tool's complexity, the description covers all key aspects: what is returned, the bounded/depth-limited nature, conditional git summary, and failure labeling. An output schema exists, so not explaining return format is acceptable. The description is complete for orienting an agent to the tool's purpose and capabilities.

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

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

Both parameters have detailed schema descriptions (100% coverage), so the schema already explains the params. The tool description adds no extra parameter-specific meaning, but given full schema coverage, a baseline of 3 is appropriate.

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

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

The description clearly defines the tool as an orientation snapshot for Godot work, listing the exact components it returns (pinned session/project, editor readiness, scene hierarchy, selection, errors/warnings, git summary). This distinguishes it from sibling tools like scene_get_hierarchy or logs_read, which focus on narrower scopes.

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

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

The phrase 'Orient before Godot work' gives clear usage context as the initial tool to invoke before more specific operations. It does not explicitly name alternatives or exclusions, but the composite snapshot nature implies it serves as a broad overview while siblings provide targeted actions.

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

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

With no annotations provided, the description carries full burden, and it delivers: it discloses fresh probes, stale cache reporting, bounded diagnostic windows, that it does not write project content, that test scripts are responsible for their own side effects, and the exact verdict types. This is highly transparent.

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

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

The description is concise and front-loaded with the core purpose. Each paragraph adds value: purpose/behavior, optional test running with a side-effect warning, and verdict/response semantics. No wasted sentences.

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

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

Given the tool's complexity and the presence of an output schema, the description is sufficiently complete. It explains the orchestration behavior, optional test integration, safety guarantees, and verdict meanings, leaving no major gaps for an agent to select and invoke the tool correctly.

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

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

Schema description coverage is 100%, so parameters are already well-documented. The description adds some context for run_tests (invokes the in-editor runner) and mentions optional filters, but does not substantially enhance parameter understanding beyond what the schema provides.

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

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

The description clearly states the tool's purpose: 'Verify live Godot health with an explicit, evidence-based verdict.' It uses a specific verb and resource, and distinguishes itself from siblings like test_run by framing itself as an orchestration tool that does not write project content.

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

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

The description implies when to use the tool (e.g., 'Set run_tests=True to also invoke the existing in-editor runner') but does not explicitly contrast it with alternative tools like test_run or state when not to use it. Usage context is present but no clear exclusions or alternatives are named.

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

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 does so admirably. It discloses buffer sizes (500/2000), retention across runs, run_id semantics, stale_run_id behavior, editor cursor mechanics (since_cursor supersedes offset), boot-time parse errors not captured, editor_errors_hint logic, and the effect of include_details. This is exceptionally transparent.

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

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

The description is long, but every section earns its place: source breakdowns, buffer sizes, run/cursor handling, and edge cases are all relevant. It is well-structured with clear labels. A slight deduction for length; it could potentially be tightened without losing critical details, but it avoids fluff.

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

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

The tool is complex with 7 parameters, multiple sources, and an output schema, but the description covers all aspects: sources, return fields (run_id, current_run_id, game_status, dropped_count, etc.), edge cases (boot-time errors, plugin-enable timing), and tail patterns. It is fully complete for a tool of this complexity, even with an output schema present.

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

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

Although the schema already provides 100% coverage with descriptions for all 7 parameters, the tool description goes far beyond the schema. It explains the intricate relationships between parameters, such as since_run_id reading prior runs, current_run_id vs run_id, since_cursor superseding offset, and the meaning of include_details. This adds substantial semantic value beyond the schema's field-level descriptions.

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

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

The description opens with a specific verb and resource: 'Read recent log lines from the Godot editor, plugin, or running game.' It immediately distinguishes the tool by enumerating four sources (plugin, game, editor, all) and their purposes, which clearly separates it from sibling tools that manage scenes, scripts, nodes, etc.

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

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

The description offers concrete guidance on when to use each source, e.g., 'Use when the editor Output or Debugger Errors panel shows red/yellow rows but other sources turned up nothing' for the editor source. It also explains polling patterns for game and editor logs. However, it doesn't explicitly state when *not* to use this tool or name alternative tools, so it falls short of a 5.

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

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?

With no annotations provided, the description carries full burden and delivers detailed behavioral context: type coercion rules for Vector2/3, Color, NodePath, Resource, StringName, and Array/Dictionary, plus behavior for null/empty values. It also discloses a common failure mode (PROPERTY_NOT_ON_CLASS) and provides concrete examples of correct property names.

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

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

The description is well-structured with a clear opening, followed by a verification note and a bulleted list of type coercions. Every sentence earns its place, and the length is justified by the complexity of type handling. It is front-loaded with the core purpose.

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

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

Given the tool's complexity (type coercion, resource handling, error modes) and the presence of an output schema, the description is remarkably complete. It explains not only what the tool does but also the nuances of value conversion, common pitfalls, and when to use complementary tools.

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

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

Although schema coverage is 100%, the description adds significant meaning beyond the schema by explaining how 'value' is interpreted for different types, how resources are handled, and how to clear properties. It enriches the 'property' parameter with the verify-first guidance, adding practical semantics not present in the schema.

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

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

The description opens with 'Set a property on a node', a specific verb+resource statement that clearly distinguishes it from siblings like node_create, node_get_properties, and node_manage. It unambiguously states what the tool does.

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

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

Explicitly instructs users to verify the property name with node_get_properties (or the godot:// endpoint) before writing, and warns against guessing. Also mentions resource_manage for more control over resource creation, providing clear guidance on when to use this tool vs alternatives.

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

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 compensates well by disclosing stop()'s idempotent behavior ('succeeds with was_running=false'), strict parameter validation ('only the registered keys are accepted'), and the requirement that session_id be a sibling of op/params. It doesn't cover all possible side effects but gives meaningful behavioral insight.

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

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

The description is well-organized with a bulleted list, code formatting, and a compact call shape example. Every sentence contributes unique value, and the structure makes the content easy to scan without unnecessary verbosity.

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

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

The tool has an output schema, so the description need not cover return values. It thoroughly documents all operations and constraints, including idempotency and validation rules. However, it could be more explicit about error conditions or how settings_set interacts with a running project, leaving a minor gap.

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

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

Schema description coverage is 0%, but the description fully compensates by explaining each operation's parameters: stop takes none, settings_get expects a key with a concrete example, settings_set takes key and value. It also clarifies the canonical call shape and parameter nesting rules, adding substantial meaning beyond the raw schema.

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

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

The opening sentence 'Project run/stop and project.godot settings' clearly defines the tool's scope. It then enumerates three concrete operations (stop, settings_get, settings_set) with specific one-line descriptions, effectively distinguishing it from sibling tools like project_run or game_manage.

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

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

The description gives actionable guidance by noting 'prefer for active-session reads' regarding resource forms, warning against passing extra params, and explaining session_id placement for multi-editor setups. While it does not exhaustively compare to every alternative, it provides clear do/don't rules.

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

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

With no annotations, the description carries the full burden, and it excels: it discloses idempotency, the wait-for-helper behavior, and provides a detailed breakdown of game_status values including 'not_live', 'no_helper', 'stopped', and 'break' with actionable advice for each. This goes well beyond a basic run command.

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

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

The description is well-structured: a lead sentence, a concise modes list, an idempotency note, and a detailed but necessary explanation of statuses. Every sentence adds value, and the length is justified by the tool's complex runtime states. There is no filler or redundancy.

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

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

Given the tool's complexity, the description is remarkably complete. It explains the three modes, idempotent behavior, the check-in wait, all status values, and how to handle failures. The output schema exists, and the description fully covers the return fields, making it self-sufficient for an agent.

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

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

The input schema describes all four parameters with 100% coverage, so the description doesn't need to add much. It does note that 'custom' requires the scene parameter, which aligns with the schema. However, the description adds little beyond the schema, so a baseline score of 3 is appropriate.

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

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

The description opens with a specific verb and resource: 'Run (play) the Godot project from the editor.' It clearly distinguishes from siblings like project_manage by focusing on playback, and it elaborates with three distinct modes, making the tool's purpose unambiguous.

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

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

The description provides clear usage context, including idempotent behavior and an explicit alternative: 'To switch scenes, call project_manage(op="stop") first, then project_run again.' It also recommends polling editor_state for late transitions. While it doesn't explicitly state when not to use the tool, it offers practical guidance for common scenarios.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does this thoroughly: notes read-only operations ('get_info'), undoable operations ('assign', 'create'), pagination and filtering requirements for 'search', auto-creation behavior for 'curve_set_points' and 'physics_shape_autofit', and error candidate paths in 'error.data.candidates'. This is rich behavioral context beyond what schema alone could provide.

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

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

The description is long but well-structured: a summary sentence, a bulleted list of operations with parameters and explanations, and a canonical call shape note. Each line earns its place for a multi-operation tool. Slight verbosity in repeated 'path+property' patterns, but not excessive given the complexity.

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

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

The description is complete for a tool with 10 operations and no annotations. It covers all operation behaviors, parameter semantics, output/error signals (e.g., candidate paths), and even the canonical call shape. The output schema exists and is generic, so the description rightfully focuses on operation-specific semantics, making this fully adequate.

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

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

Schema description coverage is 0%, so the description is the sole source of parameter meaning. It compensates exhaustively by explaining each parameter inline per operation, including format examples like 'sky may be bool or a procedural sky dict' and distinct shape_type forms for 2D/3D. This fully compensates for the generic 'params' object in the schema.

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

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

The description opens with a specific verb+resource: 'Resource (asset) search, inspection, assignment, and creation.' It then enumerates each operation with its purpose, distinguishing itself from sibling tools like node_manage or scene_manage by focusing on Resource subclasses. The scope is clear and detailed.

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

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

The description provides clear context and per-operation guidance, including a note 'For specific families (Curve, Environment, etc.) prefer the dedicated ops.' This helps the agent choose among internal operations, but it does not explicitly contrast this tool with sibling tools like material_manage or animation_manage, so some cross-tool guidance is missing.

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

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 behavioral burden. It discloses operation-specific behavior (e.g., root_name defaults to filename basename, get_roots flags the edited scene) and the canonical call shape with flat-op compatibility. It doesn't mention side effects like file overwrite behavior, but it is substantially transparent.

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

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

The description is well-structured and front-loaded: a one-line summary, a resource-form hint, a bulleted list of operations with parameters, and a call-shape note. Every sentence adds value and there is no redundant content, making it both efficient and easy to parse.

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

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

Given the tool's multi-operation complexity and the presence of an output schema, the description is largely complete. It covers the input structure, operations, defaults, and compatibility alias. Minor missing edge cases (e.g., behavior when no scene is open for save_as) prevent a perfect score.

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

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

Schema description coverage is 0% and the schema has a generic 'params' object, so the description is the only source of parameter meaning. It fully explains each operation's parameters (create with path, root_type, root_name; save_as with path; get_roots with no params) and the default behavior for root_name, compensating completely.

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

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

The description opens with 'Scene authoring (create, save_as, list open roots)', which clearly states the tool's verb and resource. It distinguishes from siblings by enumerating three specific operations and noting the resource form for active-session reads, making its scope unambiguous.

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

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

It provides a clear usage context: for authoring scenes (create, save_as, get_roots) and explicitly recommends the resource form ('godot://scene/current' and 'godot://scene/hierarchy') for active-session reads. However, it doesn't name alternative sibling tools or provide explicit 'when not to use' guidance, so it stops short of full differentiation.

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

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?

No annotations are provided, so the description carries full responsibility for behavioral disclosure. While 'save to disk' implies writing, it does not disclose whether the file is overwritten, what prerequisites exist (e.g., an active scene), or what failure modes might occur. This is insufficient for a mutation tool.

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

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

The description is a single sentence, front-loaded with the action and resource. There is zero filler or redundant information, making it an excellent example of concise writing.

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

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

The tool is simple, with one optional parameter and an output schema that presumably covers return behavior. However, the description omits important behavioral context such as prerequisites (e.g., an open scene) and whether the operation overwrites the existing file. This is adequate but has clear gaps.

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

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

The input schema already provides a complete description for session_id, achieving 100% schema coverage. The tool description adds no parameter-level detail, but the schema handles it, so the baseline score of 3 applies.

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

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

The description clearly states the action (save), the resource (currently edited scene), and the destination (to disk). While it does not explicitly differentiate from sibling tools like scene_manage, the verb and resource are specific and unambiguous.

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

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

The purpose implies when to use this tool (persisting the current scene), but the description provides no explicit guidance on prerequisites, alternatives, or exclusions. For example, it does not mention that a scene must be open or how it differs from scene_manage.

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

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 full responsibility for disclosing behavior, and it excels. It states failure conditions ('Fails on multiple matches unless replace_all=True; fails on zero matches'), exact matching semantics ('Exact byte match (whitespace significant)'), side effects ('Triggers filesystem scan'), and undo limitations ('Not undoable via Ctrl+Z'). This is comprehensive and transparent.

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

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

The description is concise and well-organized. Each sentence delivers essential information: first the overall purpose, then the matching behavior, failure modes, exactness, and side effects. No fluff or redundancy; it earns a perfect score for structure.

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

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

For a tool with 5 parameters, no annotations, and an output schema, the description covers all necessary operational aspects: exact replacement behavior, failure conditions, replace_all option, side effects, and undoability. It does not need to describe return values because an output schema exists. It is fully complete given the tool's complexity.

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

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

Schema coverage is 100%, so a baseline of 3 applies. The description adds value by clarifying the matching semantics ('Exact byte match (whitespace significant)') and reinforcing the uniqueness of old_text unless replace_all. This goes beyond the schema's 'Exact substring' phrasing, thus warranting a 4.

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

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

The description opens with a specific verb and resource: 'Anchor-based string-replace edit on a .gd file.' This clearly distinguishes it from sibling tools like script_create or script_manage by specifying the exact operation (string replacement) and the target file type. The behavior is unambiguous and sets expectations precisely.

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

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

The description provides strong context for when to use the tool: for exact, controlled string-replacements on .gd files, with explicit notes about failure on multiple/zero matches and the replace_all option. It does not explicitly name alternatives or state 'when-not-to-use,' but the clarity of behavior implies appropriate usage, so it earns a 4 rather than a 5.

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

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

With no annotations, the description carries full responsibility for behavioral disclosure. It explains precedence rules ("An exact id match always wins"), substring resolution requirements ("must resolve to exactly one session"), and error behavior ("returns an error listing the candidates"). This goes beyond the schema by detailing matching logic and failure modes, but does not cover broader effects like session persistence or side effects.

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

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

The description is concise and front-loaded: the first sentence states the purpose, followed by a compact paragraph on matching rules. Every sentence contributes meaningful information—no filler, no repetition of schema content. The structure aids quick comprehension.

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

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

For a one-parameter setter tool with a simple state-changing operation, the description covers essential context: what it does, how to identify the session, and error behavior. An output schema exists, so return values are presumably documented there. The description is complete enough for an agent to invoke correctly without additional information.

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

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

The schema already provides 100% coverage for the single parameter, describing format and examples. The description adds further meaning by enumerating the fields matched by a substring hint (short name, project_path, session_id) and the precedence rule for exact IDs. This augmentation clarifies edge cases not fully documented in the schema.

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

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

The description clearly states the tool's purpose with a specific verb and resource: "Set the active Godot editor session for subsequent tool calls." It also distinguishes itself from siblings like session_manage by focusing on state setting rather than session management/list operations. The matching semantics further clarify its role.

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

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

The description implies when to use the tool: before subsequent calls to target a specific session. It specifies the input format and matching behavior, but does not explicitly mention alternatives or exclusions (e.g., when to prefer session_manage). It is clear context without explicit negative guidance.

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

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?

No annotations exist, so the description carries the full burden. It discloses the 300s budget, timeout return code TEST_RUN_TIMEOUT, partial summary behavior, the risk of a 20s+ single test blocking the main thread, and the scene_warning mechanism. This far exceeds minimal disclosure and gives the agent critical context about side effects and failure modes.

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

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

The description is structured in three paragraphs, each covering a distinct aspect: execution, timeout/safety, and response details. The first sentence immediately states purpose, and every sentence contributes unique information about behavior or constraints. The length is justified by the tool's complexity, and there is no redundant fluff.

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

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

The description covers execution model, timeout behavior, partial results, session safety, batch_execute exclusion, main scene dependency, and response content. Given that an output schema exists, the description need not enumerate fields, but it explains the essential context for correct usage, making it fully complete for an agent to select and invoke the tool correctly.

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

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

Schema coverage is 100%, so the baseline is 3. The description enhances parameter understanding by explaining that verbose=True yields per-test duration_ms, which is not in the schema, and by tying the suite parameter to the discovery of test_*.gd files. It also adds context about the response containing edited_scene, which is not explicitly stated in the schema.

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

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

The description opens with a specific verb+resource: 'Run GDScript test suites inside the connected Godot editor.' It then details the discovery and execution of test_*.gd files and test_* methods, clearly distinguishing the tool from test_manage by referencing it for retrieving partial results.

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

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

The description explicitly states 'Not allowed inside batch_execute' and advises opening the main scene with scene_open when a scene_warning appears. It also points to test_manage(op="results_get") as the alternative for obtaining full partial results, providing clear when-to-use and when-not-to-use guidance.

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

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.