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

With no annotations, the description carries the behavioral disclosure burden. It reveals important side effects and constraints: auto-creation of the AnimationPlayer if player_path does not resolve, the parent must exist, and track paths are relative to root_node rather than scene root. It does not describe every edge case, but covers the most consequential 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 compact and front-loaded with the core purpose. Each sentence adds useful operational context: next steps, path semantics, and auto-creation behavior. There is no filler or repetition of schema-visible parameter documentation.

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 creation tool with an output schema. It covers what is created, how to proceed with tracks, important path semantics, and the auto-creation fallback. The only omitted details, such as loop_mode behavior and overwrite handling, are already documented in the 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 adds meaningful context beyond the schema for player_path by explaining resolution failure, auto-creation, and the parent-exists requirement, which helps agents use the parameter more correctly.

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: 'Create a new Animation clip inside an AnimationPlayer's default library.' It clearly distinguishes this tool from animation_manage by stating that tracks are added afterward via animation_manage ops, so an agent can tell them apart.

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 clear sequential context: use this tool to create the clip, then use animation_manage ops to add property/method/simple tracks. It also points to animation_manage for forgiving target_path behavior, but it does not explicitly state when not to use this tool beyond that implied workflow.

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 important behaviors: delete is undoable, play/stop are not saved with the scene, presets accept two path forms and convert scene-absolute paths via get_path_to, and the canonical call shape with op/session_id is explained. It also notes that parameters can be flat as a compatibility alias. This is substantial behavioral detail, though it does not cover every side effect (e.g., whether operations require the editor to be running).

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

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

The description is long but efficiently organized: a one-line purpose, a bulleted list of ops with parameter signatures and brief explanations, and a final paragraph on path handling and call shape. The front-loaded purpose and the clear op list make it scannable. It could be trimmed slightly, but every sentence earns its place given the 15 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?

The description is comprehensive for a complex tool with 15 operations. It covers parameter details, behaviors, path conventions, and call format. An output schema exists (though not shown), so return values are presumably handled there. Nothing critical for an agent to correctly invoke the tool appears missing.

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

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

The schema only defines op, params (a freeform object), and session_id, with 0% coverage of actual parameters. The description compensates fully by documenting every operation's parameters, defaults, types, and semantics (e.g., keyframes format, interpolation values, tween specs). This is a textbook example of the description carrying the parameter documentation load when the schema is opaque.

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 explicitly states 'AnimationPlayer authoring (player, tracks, autoplay, presets, playback)' and enumerates a comprehensive list of operations. Each op is a clear verb+resource (e.g., 'player_create', 'add_property_track'), and the high-level scope distinguishes it from sibling tools like animation_create, which is more basic creation. It leaves 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?

The description does not explicitly say when to use this tool versus alternatives like animation_create or other manage tools. It does provide context on path handling ('matching every other scene tool') and mentions that play/stop are editor previews not saved, which gives some usage nuance. However, it lacks explicit when-not-to-use guidance or cross-references to specific siblings.

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

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

With no annotations, the description carries the behavioral burden and does well: it states the call returns class-reference sections without creating a scene instance, notes that 'all' excludes the heavier inheritors section, and explains default section behavior and one-section-at-a-time pagination. It could still be more explicit about the operation being read-only and side-effect free, but these traits are strongly implied and the disclosure is substantive.

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 and dense, but it is organized with a purpose statement, resource form, op signature, and transport notes. A little tightening is possible (for example the canonical call shape could be moved earlier), yet every substantive detail serves the zero-coverage schema.

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

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

Given the sparse schema and no annotations, the description provides the needed operational context: op name, params object contents, defaults, pagination, and call-shape conventions. An output schema exists, so return values need not be described; remaining gaps like explicit include_inherited/include_inheritors semantics or required session_id are minor.

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 meaning, and it compensates thoroughly. It documents the get_class signature with defaults, explains the allowed sections values, clarifies the 'all' special value, and gives pagination guidance; it also clarifies op, params, and session_id placement and the compatibility alias.

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: it inspects Godot API documentation-shaped metadata from the editor's ClassDB, and lists concrete question types (properties, method signatures, signals, enums, constants, defaults, hint strings). It also names the single supported op, get_class, which makes the tool distinguishable from the surrounding node/project/scene management siblings.

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

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

There is some internal guidance: the resource form is preferred for active-session reads, and the flat-parameter form is described as a compatibility alias. However, the description never says when to choose api_manage over sibling tools such as node_get_properties, nor does it state explicitly when not to use this tool; usage context is implied rather than contrasted.

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 burden and does well: it discloses atomic playback updates, the duration_seconds return value, non-undoable preview play/stop, supported resource extensions, and project-wide scanning. However, it does not explain the persistence or undo behavior of scene-mutating ops like player_create or player_set_stream, leaving some behavioral ambiguity.

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 compact, well-organized reference: a domain-scoping first line, a bulleted op list with signatures, and a canonical call-shape note. Every line carries information, and the monospace formatting makes it easy for an agent to scan.

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

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

For a multi-op tool with no annotations and an open-ended params object, the description covers operation selection, parameters, defaults, constraints, resource types, and relevant return behavior. The canonical call shape and compatibility alias note complete the invocation picture, while the output schema covers return shapes.

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 provides no parameter descriptions (0% coverage), so the description must compensate, and it largely does with op signatures, defaults, allowed type values, and required-field rules. It lacks some finer semantics such as volume_db units, bus constraints, or path validity rules, but it meaningfully documents the intended sub-parameters.

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

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

The opening line scopes the tool to sound effects, music, and ambience, and the op list names concrete resources (AudioStreamPlayer/2D/3D, AudioStream resources). Each op uses a specific verb and resource, making the tool's purpose clear and distinct from broad siblings 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?

Each op describes a specific usage scenario: create a player, assign a stream, update playback properties, play/stop preview, or scan resources. The description also gives constraints like 'at least one of volume_db/pitch_scale/autoplay/bus required' and 'Not undoable' for preview playback. It does not explicitly exclude generic 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 behavioral burden. It discloses that autoloads are globally accessible by name when singleton=True, that state persists to project.godot, that remove only unregisters without deleting the file, and that flat parameters are a compatibility alias. This is strong behavioral disclosure, though it omits details like error cases or validation 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 dense but every sentence earns its place: a definition of the resource, a concise op list with parameter semantics, side-effect notes, and the canonical invocation shape. It is front-loaded and well structured 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 this complexity, the description is complete. It explains the domain, all operations, parameters, persistence, and call shape. Since an output schema exists, omitting return-value details is acceptable, and the behavioral notes cover the key side effects an agent needs to know.

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 explain parameters. It does: list() has no params, add(name, path, singleton=True) documents each argument and the default, and remove(name) takes one param. It also clarifies the canonical payload shape and the compatibility alias, going well 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 clearly states what the tool does: manage Godot autoloads (scripts or scenes loaded at project start). It names concrete operations (list/add/remove) and defines autoloads precisely, making it easily distinguishable from sibling tools like script_manage or project_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 context is clear: this tool is for autoload management, and the operation list implies when it should be used. However, it does not explicitly state when to prefer this tool over alternatives or mention any exclusions, leaving some routing decision to the agent.

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

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

With no annotations, the description carries full behavioral disclosure and does so thoroughly: sequential execution, stop-on-first-error, undo rollback semantics with atomic-on-failure, path conventions relative to scene root, and the prohibition on nested batch_execute. This is exactly the behavioral information an agent needs 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 front-loaded with the core purpose and each paragraph adds necessary detail without padding. It loses one point because it references 'the example below' but no example is actually present, which is a structural inconsistency.

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

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

Given the tool's high complexity and the presence of an output schema, the description covers command format, failure semantics, rollback, and path conventions almost completely. The missing literal example is the only notable gap, and the explicit statement of an absent example is a small but real completeness defect.

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 real value by defining the exact shape of each commands item, mandating plugin command names rather than MCP tool names, and clarifying scene-path semantics, which are not apparent from the schema alone.

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?

First sentence gives a precise verb and resource: execute a list of editor sub-commands in order, stopping on first error. It also clarifies the distinction from MCP tool names and frames the tool as a multi-step composition, which separates it from the many single-operation sibling tools.

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

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

The description explicitly says to use this for composing multi-step edits into one call, such as create node + set property + attach script. It does not explicitly name single-step alternatives or state when not to use it, but the composition guidance is clear enough for an agent to route correctly.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does a good job: it explains that make_current=True unmarks previously current cameras of the same class in one undo, that configure is class-aware and coerces Vector2 dicts, that set_limits_2d only changes passed edges, and that get with an empty path resolves to the active camera. It also documents the canonical call shape and compatibility alias. It doesn't mention side effects like whether operations are undoable in general, but the specific undo behavior for create is disclosed.

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

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

The description is long but well-structured: a one-line summary, a bulleted list of ops with signatures and explanations, and a final note on call shape. The front-loaded summary and consistent op-by-op format make it scannable. It earns its length because it documents eight operations with distinct parameter sets; a shorter version would lose necessary detail.

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

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

Given the tool's complexity (8 ops, many parameters, no annotations, and a generic schema), the description is quite complete. It covers all ops, parameter semantics, defaults, and the canonical call shape. It also has an output schema, so return values don't need to be described. Minor gaps: it doesn't specify error behavior or what happens when a camera_path is invalid, and the 'properties' parameter for configure is open-ended. But overall, an agent has enough to call 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?

Schema description coverage is 0%, so the description must compensate for the schema's lack of parameter documentation. It does so extensively: each op's parameters are listed with types, defaults, and semantics (e.g., drag_margins: {left,top,right,bottom} fractions [0,1], smoothing_speed=5.0, zero_transform=True). The description adds meaning far beyond the bare schema, which only defines op, params, and session_id. It doesn't document every possible property key for configure, but it gives representative examples and enum 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 opens with a clear statement of the tool's domain ('Camera2D / Camera3D authoring') and enumerates the specific operations (zoom, FOV, projection, smoothing, follow). Each op is listed with a verb and resource, making it easy for an agent to distinguish this 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?

The description provides explicit guidance for when to use the tool (camera authoring) and even tells the agent when NOT to use it: transforms (position, rotation, scale, transform, global_*) should be set via node_set_property, not here. It also explains the canonical call shape and compatibility alias. It doesn't explicitly name alternative tools for every op, but the exclusion for transforms is a strong usage signal.

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

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

With no annotations, the description carries full burden and explicitly acknowledges that it 'Writes / removes client config files.' It also discloses the status values returned and the compatibility alias behavior for flat parameters. It does not mention permissions or reversibility, but the core side effects are clearly stated.

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 efficiently structured: a one-sentence purpose, a bulleted operation list, and a compact call-shape note. Every section adds necessary information, and the most important mutation warning appears in the first sentence.

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

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

Given an output schema and no annotations, the description is sufficiently complete for calling the tool correctly: it describes each operation, parameter semantics, call shape, and compatibility behavior. No critical aspect needed to invoke the tool is missing.

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

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

Schema description coverage is 0%, so the description compensates well: it explains op values via the ops list, defines 'client' as an id from status(), and clarifies the canonical call shape. The session_id parameter is only noted as top-level, not semantically explained, but its purpose is fairly self-evident.

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: 'Configure AI clients to use this Godot AI MCP server.' It then enumerates three concrete operations (status, configure, remove), making it distinct from sibling manage tools and unambiguous about scope.

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

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

The description gives clear operational context by defining each op and explicitly directing users to call status() first to obtain valid client ids for configure/remove. It does not explicitly compare against alternative tools, but the workflow within the tool is well specified.

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 that all write ops are undoable via EditorUndoRedoManager, that sibling CSG shapes combine automatically, and that size/position/material are set separately. It also outlines return values for each op. It does not mention failure modes or prerequisites like needing an open scene (though 'currently edited scene' implies it). Strong transparency for a mutating 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 structured with a brief intro, a pointer to related tools, and a bulleted list of ops with parameter details and returns. Every sentence provides value: undoability, grouping behavior, cross-tool hints, and op signatures. It is long but well-organized and front-loaded with the core purpose. No 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 two sub-operations, multiple parameters, and an existing output schema, the description covers all necessary context: what it does, how to invoke it (including call shape), parameter enums and defaults, return values, and cross-references to other tools for node properties. It even explains the automatic combination behavior. Nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is 0%, and the description fully compensates. It documents every parameter for both ops: parent_path (empty = root), name, shape (with enum values), operation (with enum values), and path. It also explains the canonical call shape and flat-parameter alias. This goes far beyond the minimal schema, giving the agent all needed parameter semantics.

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

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

The description states a specific verb ('authoring') and resource (CSG shapes), and enumerates the two concrete operations (csg_create, csg_set_operation). It clearly distinguishes from sibling tools like node_create and scene_manage by focusing on boolean-shape creation and operation setting. The purpose is 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 gives clear context on when to use this tool (for CSG authoring) and even routes follow-up property setting to node_set_property / material_manage. It also clarifies the automatic combination behavior of sibling CSG shapes and suggests CSGCombiner3D for explicit grouping. However, it does not explicitly state when *not* to use this tool (e.g., 'for regular nodes use node_create'), leaving some inference to the agent. Lacks explicit exclusions, hence 4.

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 behavior. It explains that params are forwarded unvalidated, that op and session_id remain top-level, and mentions the canonical call shape. It doesn't detail error handling or side effects, but the key behavior (unvalidated forwarding) is disclosed.

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

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

The description is well-structured, starting with the core purpose, then usage details, then canonical shape. It uses bullet-like phrasing and packs information efficiently, with minimal 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 (op-based, with dynamic params), the description covers essentials: both operations, parameter requirements, canonical call shape, batch integration, and preference for first-class alternatives. The output schema is present, so return format isn't needed. Overall, this is a comprehensive definition.

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

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

Schema has 0% coverage, but the description partially compensates by explaining the 'params' parameter and that op has enum values. However, it does not explain the session_id parameter beyond mentioning it is top-level, and the flexible params object needs more detail about how it is used.

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 lists or invokes custom tools from third-party addons. It distinguishes itself from sibling tools by focusing on custom addon tools, which is unique among the listed siblings.

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

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

The description gives explicit guidance on when to use op='list' vs op='invoke', how to address custom tools in batch_execute, and notes that some custom tools are registered first-class and should be preferred. This is excellent usage guidance.

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

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

With no annotations, the description carries the full disclosure burden and handles it well: quit is 'graceful' and deferred to the next frame, logs_clear is opt-in for the user-facing Debugger dock, selection_set replaces the selection, and game_eval enumerates specific error codes and their causes. This gives an agent a strong mental model of side effects and failure modes.

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

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

The description is long but well-structured: a one-line summary, a resource-forms note, and a bulleted op list. Each bullet earns its place, especially the game_eval error taxonomy, which is dense but necessary. The canonical call shape is placed at the end where it ties the format together.

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 multi-operation nature, this description is complete: it covers every op in the schema, defines parameter semantics, explains error behavior, and specifies invocation conventions. Since an output schema exists, the absence of return-value prose is acceptable.

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

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

Schema description coverage is 0%, so the description must supply all parameter meaning, and it does. Each operation's parameters are explained with types and defaults—selection_set(paths), monitors_get(monitors=None), logs_clear(clear_debugger_errors=False), game_eval(code)—and the call-shape paragraph clarifies where op, params, and session_id belong.

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 concrete summary of what the tool covers—editor selection, performance monitors, quit, log clearing, and game eval—and then enumerates each operation with a verb and resource. This makes the tool's scope immediately recognizable and distinguishable from more specialized siblings like editor_state, logs_read, and 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?

It gives clear guidance on invoking operations, including the canonical call shape and the flat-parameter alias. It also advises preferring resource forms for active-session reads, which helps route usage. However, it does not explicitly state when to choose this tool over closely related siblings such as editor_state or logs_read.

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 that the reload kills the server, that the WebSocket transport drops, that the response shape differs by launch mode, that there is a 90-second timeout, and that PLUGIN_DISCONNECTED is raised with recovery diagnostics. This is exemplary behavioral disclosure for a destructive/disruptive 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 well-structured with clear mode separation and bullet-like formatting. It is longer than average, but every sentence earns its place by explaining critical behavioral differences and recovery steps. Slightly verbose in the timeout explanation, but justified 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 fully covers the tool's behavior, both response shapes, the failure mode, and the recovery procedure. The output schema exists, so return values are already structured. For a tool with this level of operational complexity, nothing an agent needs to call it correctly and handle the aftermath is missing.

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

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

Schema description coverage is 100%, so the schema already documents the single optional session_id parameter. The description does not add extra meaning about the parameter beyond what the schema provides, but it doesn't need to. 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 opens with a specific verb and resource: 'Reload the Godot editor plugin.' It then immediately distinguishes the two operational modes (plugin-managed vs externally launched), which clearly separates this tool from siblings like editor_manage or session_manage. The purpose is unambiguous and the tool's unique behavior is front and center.

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 explains when each behavior applies: plugin-managed default install vs externally launched server. It also tells the agent what to do after the reload (reconnect and call session_manage(op='list') to find the new session_id). This is strong usage guidance that routes the agent through the correct post-condition workflow.

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?

Since no annotations are provided, the description carries the full burden and delivers: error shapes (EDITOR_NOT_READY with data, NODE_NOT_FOUND, GAME_HELPER_TIMEOUT), fallback behavior (cinematic falls back to first Camera3D), stale-frame handling for backgrounded games, and compatibility constraints. It also discloses that AABB metadata is always returned and what include_image does. This is thorough 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 long but well-structured, starting with a one-line summary, then a 'Picking a source' section with clear bullets for each source, followed by parameter clarifications. Every sentence provides unique value, but the length might be slightly intimidating; however, given the tool's complexity, it is justified and efficiently formatted with bullet lists.

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 10 parameters, no output schema, and no annotations. The description covers all necessary context: source behavior, error codes with data, fallbacks, compatibility, return format (MCP ImageContent, metadata), and special notes for backgrounded games. Parameters like user_prompt and session_id are adequately explained. Nothing an agent needs to call it correctly is missing.

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

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

The schema already describes all 10 parameters with 100% coverage, so the baseline is 3. The description adds valuable semantic context: fov ranges ('Tight 20-30 = zoom; 60-75 = context'), view_target reframing, coverage capturing perspective + orthographic references, and source-specific constraints. This enhances understanding beyond the schema without redundancy.

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

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

The opening sentence states the exact action and resources ('Capture a screenshot of the Godot editor viewport or running game'). It immediately distinguishes between editor and game captures, and the four named sources make the scope crystal clear. No sibling tool does screenshots, so there is no ambiguity.

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

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

The description provides explicit selection criteria for each source: 'use for 2D scenes' (viewport_2d), 'switch to cinematic if the scene has a Camera3D', and game source only when running. It also states explicit exclusions, e.g., viewport_2d is not compatible with view_target/coverage/elevation/azimuth/fov. Error states include actionable next steps, guiding the agent on retry or alternate sources.

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 discloses a non-obvious side effect ('refreshes the server's session readiness cache'), explains the authoritative game_status.status versus raw is_playing, and details the 'break' state and required recovery action. This goes beyond a simple read and prevents misuse.

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?

Front-loads the purpose in one sentence but then includes a long block of alternate invocation forms, code-mode adapter call signatures, and issue reference. Most content is relevant, but the description is denser than necessary and some details (e.g., Issue #262) could be omitted.

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 state-read tool with an output schema and one optional parameter, the description covers purpose, alternatives, side effects, and field semantics. Existing output schema covers structured returns, so no critical invocation information is missing.

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

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

The only parameter, session_id, is fully documented in the schema with default and semantics (optional, empty=active session); schema coverage is 100%, so the description does not need to repeat it. It adds no additional parameter-specific detail.

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?

First sentence states a specific verb and resource: 'Get current Godot editor state: version, readiness, open scene, play state.' It also distinguishes itself from dedicated current-scene access by directing to readResource('godot://scene/current') and acknowledges the editor_manage(op='state') alias, so an agent can identify what this tool is for.

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

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

The description gives explicit routing: prefer godot://editor/state for active-session reads, mentions editor_manage(op='state') for clients wanting a rolled-up tool, and directs 'dedicated current-scene data' to readResource. It also recommends using editor_state as a recovery step after EDITOR_NOT_READY, providing a concrete when-to-use scenario.

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

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

With no annotations, the description carries full behavioral burden and meets it thoroughly: write_text performs a single-file update rather than a full scan, reimport reports skipped_non_imported without evidence of parsing, scan is single-flight, move/rename preserve UID sidecars but refuse certain references, all mutations are non-undoable, and partial errors must not be blindly retried. This goes far 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 but justified by eight distinct operations, each with non-obvious semantics. It is well structured with op bullets, a separate mutation contract section, and a canonical call shape note; no filler or redundant restatement of the schema is present.

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

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

Covers operation semantics, return fields for read_text/reimport/scan, error outcomes, mutation side effects, when scans are required, and the calling convention. Since an output schema exists, detailed return shapes need not be repeated; the description provides the contextual behavior an agent needs to call and interpret results correctly.

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

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

Schema coverage is 0% because params is an opaque additionalProperties object, so the description must document every op's parameters and does so explicitly: read_text(path), write_text(path, content=''), reimport(paths), search(name, type, path, offset, limit), move(path, new_path), rename(path, new_name), and remove(path, force, permanent). The canonical call shape is also stated.

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

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

States a specific resource scope ('Project filesystem access via the Godot editor's EditorFileSystem') and enumerates eight concrete operations with verbs like read_text, write_text, reimport, scan, search, move, rename, and remove. This clearly distinguishes the tool from script/resource/scene-focused siblings.

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

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

Provides explicit when-to-use guidance: reimport is 'intended for imported assets', scan is recommended after adding class_name scripts, and script_patch/script_create are named as the alternative for receiving fresh script diagnostics. It also specifies operational constraints like 'direct call, not batch_execute' and 'call scan afterward' for directory mutations.

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 meets it thoroughly. It discloses debugger-bridge behavior, suspend/resume idempotence, next_frame verification and focus handoff, the direct-session fallback's visual limitation, frame-based timing, focus-independence, and rejection of malformed mouse positions. This is rich behavioral context beyond a simple mutation/read hint.

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 necessarily so for a multi-op tool, and it is well-structured: a one-line purpose, prerequisite context, grouped ops with consistent formatting, and a closing canonical-call note. The summary is front-loaded, and each op entry earns its place by adding behavior or parameter detail not available in the schema.

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

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

Given the tool's complexity, 0% schema coverage, and no annotations, the description is unusually complete: prerequisites, all 13 ops, parameter formats, timing semantics, failure/rejection behavior, and execution restrictions are covered. An output schema exists, so return-value details are not required here, and the description still notes response behavior for key operations like next_frame and input_sequence.

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

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

Schema description coverage is 0%, so the description must compensate, and it does extensively. It defines each op's parameters, defaults, accepted value formats (e.g., position as {x, y} or [x, y], event enums like 'motion' | 'button'), and the canonical call shape with op/session_id top-level. The step schema for input_sequence and the 'flat parameters alias' are also explained, making the generic params object actionable.

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: 'Runtime game inspection and input simulation' targeting 'the running game process through Godot's EngineDebugger bridge.' It then enumerates concrete ops with distinct verbs and payloads, so an agent can tell this tool from editor-side tools. It also names the prerequisite project_run and editor_state, reinforcing its runtime-focused identity.

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

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

It gives explicit preconditions: start the project with project_run and poll editor_state until game_capture_ready=true. It also gives when-not guidance ('Cannot run inside batch_execute') and explicitly prefers input_sequence over separate input_action calls whenever timing matters, including the rationale about network latency. It provides alternatives and context clearly.

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 that write operations are undoable via EditorUndoRedoManager, that item=-1 erases a cell, and that fill performs a single undo action. It also explains the canonical call shape and compatibility alias. These behavioral traits go beyond the schema and are useful for the agent.

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

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

The description is well-structured with a concise overview followed by a bulleted list of operations, each with parameters and return values. It front-loads general context (scene-relative paths, undoability, item discovery) before detailing each op. Every sentence adds value, and the structure makes it easy to scan.

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

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

The tool is complex with multiple operations and many parameters. The description covers all necessary information: how to call, what each op does, parameter meanings, return values, the canonical call shape, and the compatibility alias. It also explains how to discover valid item ids. Nothing essential is missing for an agent to invoke it correctly.

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

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

Schema description coverage is 0%, so the description must fully explain parameters. It does so comprehensively for each operation, defining path, item, coordinates, orientation (0..24), and rect dimensions. It also explains return values for each op, covering all parameters and their semantics.

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

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

The description clearly states the tool's purpose: 'GridMap authoring (set items, fill 3D regions, clear, read cells + library items).' It lists specific sub-operations and differentiates from siblings like tilemap_manage by focusing on GridMap nodes and their operations. The verb+resource is 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 description explains when to use the tool: for GridMap nodes in the currently edited scene, with guidance to use gridmap_list_library_items to discover valid item ids before placing cells. It also clarifies that all operations target nodes by scene-relative path. However, it does not explicitly state when NOT to use this tool versus alternatives, but the context is clear enough.

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 does so thoroughly: persistence side effects, builtin-vs-user actions, deadzone validation and rejection error, removal of unloaded persisted actions, and event-type-specific value mappings are all disclosed. This gives an agent a reliable model of what each operation changes.

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 earned: each operation has a compact bullet with parameter details and constraints, and the canonical call shape is stated at the end. The structure is scannable and front-loaded with the overall domain before diving into 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?

For a multi-operation tool with high complexity and a schema that covers none of the operation-specific parameters, the description is remarkably complete. It covers all ops, their parameters, constraints, side effects, and the call envelope; an output schema exists, so not detailing return values is acceptable.

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

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

The input schema provides only a top-level op enum and an opaque params object, so parameter documentation is entirely the description's job. It delivers per-operation parameter lists, types, defaults, allowed ranges, and concrete examples (e.g., keycode name strings, mouse button indices, JoyButton/JoyAxis values), far exceeding what the schema offers.

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 resource ('InputMap actions and bindings (keyboard, mouse, gamepad)') and its persistence target ('project.godot'), and enumerates six concrete operations. It does not explicitly contrast itself with sibling tools like resource_manage, but the InputMap domain is distinct enough that an agent can tell what this tool is for.

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 clear operational context: it recommends the godot://input_map resource form for active-session reads, instructs that bind_event requires the action to already exist, and highlights idempotent alternatives (ensure_action, ensure_binding). It stops short of explicitly saying when not to use this tool or naming a specific preferred sibling alternative.

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 to lean on, the description fully carries behavioral disclosure: buffer sizes, retention across runs, run_id/cursor semantics, truncation behavior, boot-time error caveats, filtering to .gd/.cs, and the meaning of include_details. This is exceptionally transparent about edge cases and response fields.

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 the complexity of four sources plus cursor/run tracking justifies most of the length. It is logically organized by source and then by tail pattern, though some repetition of run_id/current_run_id/stale_run_id across sections could be trimmed.

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

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

Given the tool's high complexity, the description covers every parameter, source behavior, retention rule, edge case, and response field relevant to calling it correctly. An output schema exists, so not over-explaining return types is appropriate; the narrative adds the operational context an agent needs.

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?

Though the schema already covers all parameters, the description adds substantial meaning: buffer sizes per source, how since_run_id and since_cursor interact with offset, when truncated appears, and what include_details actually enriches. Only session_id is not elaborated beyond the schema, but the overall enrichment is extensive.

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

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

Opens with a specific verb and resource ('Read recent log lines from the Godot editor, plugin, or running game') and further enumerates four distinct sources. No sibling tool covers log reading, so there is no risk of confusion with the listed 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?

Provides explicit guidance on when to prefer each source, including the editor-source trigger ('when the editor Output or Debugger Errors panel shows red/yellow rows but other sources turned up nothing'). It also explains the default source and gives concrete tail/polling patterns for game and editor logs.

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 is exceptionally transparent. It repeatedly discloses side effects and constraints: 'not undoable' for several ops, 'generated source is parsed through the engine's shader compiler before saving', 'parse errors reject the write with diagnostics and leave any existing file untouched', 'Result is validated in memory, then saved atomically', 'Existing destination directory required', and precise limits ('256 nodes, 1024 connections total'). These behavioral details go far beyond a basic mutation warning.

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 scope overview, resource forms, then a bulleted list of ops with code-style signatures and explanatory notes. It is appropriately detailed for the tool's complexity (16 ops), and the information is front-loaded with the core purpose. Some repetition exists (e.g., 'not undoable' appears multiple times), but the overall organization makes it navigable and information-dense.

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 16 operations, no annotations, and 0% schema coverage, the description covers essentially everything an agent needs: each op's behavior, return values (e.g., shader_get returns 'full source, shader_type, uniforms, render modes, #include list'; shader_validate returns 'valid plus errors/warnings'), prerequisites, failure modes, and the canonical call shape. It also notes the fallback validation behavior across renderers, which is a subtle edge case. There is no significant missing 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?

The input schema has 0% description coverage, so the description must compensate entirely. It does so comprehensively: each op is shown with full signatures, parameter meanings, defaults, constraints, and even structural details (e.g., stages entries, varyings fields, slot values, type enums). For example, visual_shader_create_graph explains the structure of stages, node IDs, port names, and limits. The description fully compensates for the schema's lack of parameter documentation.

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

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

The description states the tool's scope with specific resource types: 'Material authoring (StandardMaterial3D, ORMMaterial3D, ShaderMaterial, CanvasItemMaterial), raw shader source (.gdshader / .gdshaderinc), and VisualShader graph authoring/editing.' It names the exact resources and verbs (create, edit, inspect, assign, etc.), and the title is generic but the description fully disambiguates it from sibling tools like resource_manage or script_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 intra-tool sequencing guidance (e.g., 'Use before visual_shader_edit', 'Use create(type="shader", ...) then assign separately'), but it never compares this tool to alternative sibling tools. There is no explicit statement about when to use material_manage versus resource_manage or script_manage, so the usage is implied by scope rather than explicitly differentiated.

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 behavioral burden and does so thoroughly. It discloses asynchronous baking, the 30s deferred reply deadline, abort-on-source-edit behavior, cancellation restoring the old region resource, force_sync effects, undo/redo behavior, and the read-only nature of path_get with force_sync=False.

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 earns its place by adding a constraint, limit, or behavioral guarantee. The intro front-loads the tool's scope, the op bullets are scannable, and the canonical call shape is stated at the end without 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 and the presence of an output schema, the description is remarkably complete: it covers prerequisites, hard input limits, asynchronous execution, cancellation semantics, sync behavior, undo/redo, resource forms, and return values for path_get. The remaining parameter ambiguities are minor and do not undermine overall usability.

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 inline op signatures are the only parameter documentation. They cover every parameter with defaults and explain several meaningfully, such as from_point formats, region_path selection, and force_sync side effects. However, a few parameters remain underspecified, notably bake's `path` target and the exact behavior of path_get's `optimize` and `navigation_layers`.

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 names the exact domain: 'Bounded 3D mesh-only navigation baking and 2D/3D path queries.' It then enumerates two concrete ops with signatures—bake and path_get—so an agent can immediately understand the tool's scope and distinguish it from scene, mesh, or gridmap management siblings.

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

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

The description gives explicit when-to-use and when-not-to-use guidance: bake requires NavigationMesh root-children source mode and mesh-instance/both geometry settings, rejects groups, colliders, CSG, GridMap, and obstacles, and explicitly says 2D baking is unsupported. It also states 'call directly, not in batch_execute' and explains how path_get selects a region versus the edited scene root's world map.

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, and it discloses the core mutation (node is created and added to a parent), the PackedScene path, and the precedence rule that scene_path overrides type. It does not go into side effects such as scene dirty state, undo behavior, or required scene-open prerequisites, but it is substantially more transparent than a bare mutation statement.

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 short, front-loaded with the key action, and organized into a summary plus a detail sentence. The only minor wart is the redundancy between 'Create (spawn)' and 'Creates a node' in the following sentence.

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

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

For a six-parameter tool with complete schema descriptions and an output schema, the combined definition covers all parameters, both creation modes, parent-relative placement, and the scene guard parameter. It does not explicitly state prerequisites such as having an edited scene open, but the schema and output schema largely fill the remaining context, so it is close to 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?

All six parameters already have schema descriptions (100% coverage), so the baseline is 3. The description adds value beyond the schema by stating that type and scene_path are mutually exclusive and that scene_path wins when both are present; it also clarifies that the node is added to the parent. It doesn't add constraints on node class names or path formats.

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 starts with a specific verb and resource: 'Create (spawn) a new node in the scene tree.' It then gives the two creation modes (type-based node vs PackedScene instantiation), making it clearly distinct from sibling inspection/manipulation tools like node_find and 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 opening sentence clearly signals the intended use case: creating/spawning nodes in the scene tree. It also explains the two mutually exclusive construction modes (type vs scene_path), which guides call configuration. It does not explicitly compare against sibling tools or list when not to use it, 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 provided, the description carries the full burden of behavioral disclosure. It does mention that at least one filter is required, filters AND together, and results are paginated, which are key behavioral traits. However, it does not explicitly state that this is a read-only operation or disclose any side effects, though 'find' implies read-only. The description covers the most important constraints but could add explicit safety 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 two sentences with no wasted words. The first sentence states the purpose and the second adds essential constraints, front-loading the most important information. It is concise and well-structured.

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

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

Given the presence of an output schema and the simplicity of the tool, the description covers the essential aspects: purpose, filter combination, requirement of at least one filter, and pagination. It does not explain the output format, but the output schema handles that. It could mention session handling or defaults, but those are in the schema. Overall, it is complete enough 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?

The schema covers all parameters with descriptions, but the tool description adds meaningful semantics: it explains that filters AND together and that at least one filter must be provided, which are not in the schema. This extra context helps the agent understand how to combine the name, type, and group parameters correctly.

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 finds nodes in the scene tree by name, type, or group, which is specific and distinguishes it from siblings like scene_get_hierarchy that retrieve the whole tree. It doesn't explicitly name an alternative, but the purpose is unambiguous and covers the core 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?

The description implies usage for searching nodes but does not explicitly state when to prefer this over alternatives like scene_get_hierarchy or node_get_properties. It mentions filtering and pagination, which hints at its role, but there is no direct guidance on alternatives or exclusions.

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

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

Despite no annotations, the description thoroughly discloses behavior: it details response size, the total_count vs count difference, unknown_fields handling, null-value inclusion, and script serialization. This exceeds minimal requirements.

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 detailed but well-structured, with the main purpose first, followed by usage tips and behavior specifics. Some redundancy exists, but it remains organized and readable.

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 absence of annotations, the description covers all necessary aspects: usage context, parameter behavior, response semantics, and edge cases. With an output schema present, it is effectively complete.

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

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

Schema coverage is 100%, so parameters are well-documented in the schema. The description adds contextual notes about 'fields' (response size cut) and 'path' (not runtime paths), but these are enhancements rather than necessities.

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 retrieves node properties, identifies the resource form, and differentiates from siblings like node_set_property. It provides specific details about the returned data structure.

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

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

The description explains when to use this tool (active-session reads) and advises using the 'fields' parameter for large response cuts, but does not explicitly name alternative tools for similar operations.

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

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

With no annotations, the description carries the full burden and does so thoroughly: it discloses that delete is undoable, scene root cannot be deleted or duplicated, rename has collision and character rules, reparent preserves children and forbids descendant moves, and the scene_file guard returns EDITED_SCENE_MISMATCH. This is strong behavioral detail for a mutation-heavy 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 well organized with an intro, resource forms, per-operation bullets, a scene_file guard note, and call-shape guidance. It is dense but generally purposeful; however, the resource-form block overlaps with the get_children/get_groups operations and includes a 'properties' form not represented in the op list, creating minor redundancy and ambiguity.

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 nearly complete for a tool with this many operations: it covers each operation's semantics, constraints, the optional scene_file guard, and the canonical call envelope, while output schema covers return values. It lacks a concrete request example and does not clarify exactly how the resource forms relate to the op-based API, preventing a higher 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%, but the description effectively replaces the missing parameter docs by specifying every operation signature with arguments and defaults, e.g., duplicate(path, name='', scene_file='') and move(path, index, scene_file=''). It also documents the canonical {'op': ..., 'params': ...} call shape and the flat-parameter compatibility alias, giving an agent enough information to construct valid calls despite the permissive 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 the resource as the node tree and enumerates a concrete set of verbs: delete, duplicate, rename, move, reparent, group management, and hierarchy reads. It is clear about the tool's scope but does not explicitly differentiate it from sibling node tools like node_create or node_set_property, so it stops short of a 5.

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

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

The description provides a 'prefer for active-session reads' note and per-operation constraints, but it does not say when to choose node_manage over alternatives such as node_find, scene_get_hierarchy, or node_set_property. Usage context must be inferred from the operation list rather than being explicitly stated.

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

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

With no annotations provided, the description carries the full burden, and it delivers: it discloses coercion behavior per type, the PROPERTY_NOT_ON_CLASS failure mode, serialization semantics for built-in resources, and clearing via null/"". This far exceeds a simple mutation warning.

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 it is front-loaded with the core action and verification instruction, then organized as a bulleted coercion list. The resource-sharing detail is dense but earns its place because that is where agents commonly fail.

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 availability of an output schema plus fully described parameters, the description covers every hard part: property-name discovery, type coercion, resource lifecycle, and sibling routing. No critical operational gap remains.

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%, but the description still adds substantial meaning beyond the schema's type definitions. It explains the exact accepted shapes for Vector2/3, Color, NodePath, Resource, StringName, Array, and Dictionary, which the schema alone does not convey.

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 and resource with no ambiguity about the action. It also names complementary siblings like node_get_properties and resource_manage, making clear that this tool is the write operation, not a reader or resource manager.

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 tells the agent to verify property names with node_get_properties before writing and warns against guessing, which is concrete when-to-use guidance. It also provides an alternative resource_manage workflow for shared resources, clarifying when not to pass a raw dict directly.

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

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

With no annotations provided, the description carries the full burden and does so thoroughly. It discloses side effects (single undo action, auto-created ProcessMaterial and QuadMesh), runtime-only behavior, invalid-override handling returning INVALID_PARAMS, and type-specific vector requirements. This is strong 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 well-structured with a front-loaded scope and a clear operation-by-operation breakdown. There is some redundancy, notably GPU gravity formatting stated twice, and the length is high, but each section contributes necessary detail for a seven-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?

For a complex tool with a sparse schema and no annotations, the description is remarkably complete: it covers operation signatures, property groupings, preset names, override routing, error behavior, and call shape. The output schema exists, so return-value details are already handled, and the pointer to the Godot reference for the full property list is acceptable.

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

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

Schema description coverage is 0%, so the description compensates fully. It documents every op's parameters, type enum values, property groups, preset names, override structure, and per-type constraints like GPU gravity requiring {x, y, z} or [x, y, z]. This goes well beyond the minimal input 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 immediately scopes to 'Particle systems (GPUParticles2D/3D, CPUParticles2D/3D)' and enumerates precise operations (create, set_main, set_process, set_draw_pass, restart, get, apply_preset). This clearly distinguishes it from sibling tools like node_create 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 gives clear operational context: all write ops create nodes plus sub-resources in one undo action, restart is runtime-only and not undoable, and the canonical call shape is specified. It does not explicitly state when not to use this tool versus alternatives, but it provides enough context for tool selection.

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

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

With no annotations, the description carries the full behavioral disclosure burden and does so thoroughly. It discloses stop() idempotency and the was_running=false success behavior, strict rejection of extra params, configuration-key refusal, persistence to project.godot, and main-scene path validation. This is the kind of operational detail an agent needs before invoking a mutating 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 organized, front-loaded, and uses clear headings and call-shape examples. It is somewhat long, but that length is justified by four distinct operations and the need to document validation and parameter restrictions. A few phrases, like the flat-parameter compatibility alias, could be trimmed without much loss.

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 four-operation mutating tool with no annotations, the description is nearly complete: it covers operation semantics, parameter constraints, persistence behavior, and the canonical invocation shape. The presence of an output schema means return values do not need to be documented in prose. It still does not mention prerequisites like whether a project must already be open, or what error behavior an agent should expect on failure.

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 compensate, and it does. Every op signature is spelled out: stop() takes no params, settings_get(key), settings_set(key, value), and set_main_scene(path), with notes on where session_id belongs and which keys are rejected. The params field itself is generic in the schema, so this documentation is essential and complete.

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

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

The description states a concrete scope: stopping a running project and reading/writing project.godot settings, with each operation listed as verb+target. It explicitly references sibling tools like project_run and autoload_manage, making the boundary between this tool and nearby tools clear. The initial 'run/stop' wording is slightly broader than the actual ops, but the detailed op list immediately resolves that ambiguity.

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

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

The description gives useful routing guidance: prefer the resource form for active-session reads, use set_main_scene/autoload_manage for refused keys, and use project_run(mode="main") for running the project. It does not, however, provide a global decision rule for when project_manage should be chosen over project_run or game_manage in general. The exclusions it does provide are concrete and actionable.

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 behavioral burden. It thoroughly discloses idempotency, was_already_running behavior, all game_status values ('live', 'not_live', 'no_helper', 'stopped', 'break'), helper_live/session_active semantics, break recovery steps, and the recommendation to poll editor_state. This is exemplary transparency for a runtime-control 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 long but dense and well-structured: purpose, modes, idempotency, status meanings, and recovery actions are all front-loaded in logical order. Every sentence contributes to correct invocation or interpretation of results, with no 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 there are no annotations and the tool has complex runtime behavior, the description is remarkably complete. It covers all modes, edge-case statuses, failure handling, and follow-up actions, while the presence of an output schema covers raw return-value shape. Nothing essential for correct usage appears missing.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters adequately. The description adds useful semantics around mode selection and the custom-requires-scene dependency, but autosave and session_id are not elaborated beyond the schema. This meets the baseline but adds limited parameter-level value.

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

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

The description opens with a specific verb+resource ('Run (play) the Godot project from the editor') and immediately clarifies the three modes: main, current, and custom. It also references project_manage for stopping/scene-switching, helping differentiate this tool from related siblings. The purpose is unambiguous and operationally specific.

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 Modes list gives clear selection criteria, and the description explicitly says to call project_manage(op='stop') first when switching scenes. However, it does not explicitly state when to prefer project_run over test_run or other launch-related siblings. It offers solid context but not full when-not 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 carries the full burden, and it does so extensively: read-only operations are labeled (get_info "Read-only"), mutating operations are qualified (assign/create "Undoable"), limits are disclosed (depth 0..3, 64 KiB limit, 2048 triangles, 6144 vertices, 1024 paths), and refusal conditions are explicit ("refused before anything is written", "unmarked legacy bodies or broken provenance links are refused"). It also documents canonical call shape and batch execution constraints, going well beyond a surface-level summary.

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 for a twelve-operation tool: a one-line overview, a bulleted op list with consistent signatures, a canonical call shape, and a compatibility note. The detailed physics_shape_generate section is dense but every sentence conveys a distinct constraint or behavior. No filler or tautological phrasing is present.

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 absence of annotations, and the free-form params schema, the description is remarkably complete. It explains each op's purpose, parameter options, side effects, limits, undo behavior, and even the canonical invocation shape. Since an output schema exists, the lack of per-op return descriptions beyond the one shown is acceptable.

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

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

The input schema has 0% description coverage and only exposes a free-form params object, so the description must fully compensate. It does: every operation lists its parameters with defaults, accepted enum values, and behavioral meaning (e.g., shape_type short forms versus Godot class names, environment presets, fill modes, noise types). This gives an agent everything needed to construct valid calls.

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

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

The first sentence states specific verbs and a clear resource domain: "Resource (asset) search, inspection, assignment, and creation." It further distinguishes the tool by enumerating specialized authoring families (Curve, Environment, physics shapes, gradient/noise textures) and listing twelve concrete operations. This gives an agent a precise model of what the tool does and how it differs from node/scene/material management siblings.

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

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

The description provides strong context for when to use the tool: it covers resource search, inspection, assignment, and creation, and it even routes users to dedicated ops within the tool ("For specific families (Curve, Environment, etc.) prefer the dedicated ops"). It does not, however, explicitly state when to prefer a sibling tool such as node_set_property, material_manage, or filesystem_manage, nor does it name exclusions. Clear context, but no explicit 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?

No annotations are provided, so the description carries the burden. It discloses the return shape (paginated, flat, fields), depth behavior, and resource form. While it doesn't explicitly state 'read-only' or describe error behavior, the verb 'Get' plus 'Returns' makes the non-mutating nature 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?

Three concise sentences with the core action first, followed by output details and a resource-form note. The resource-form line is helpful context but not strictly necessary for tool invocation.

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 read-only hierarchy getter, the description covers purpose, output, depth, and pagination, and an output schema is present to document return values. It doesn't mention error cases (e.g., no open scene) or session-targeting subtleties, but these are not critical given the 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 description coverage is 100%, so the baseline applies. The description's 'Walks up to the specified depth' reiterates the depth parameter rather than adding much new, and 'paginated' vaguely aligns with limit/offset but does not explain their interaction.

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

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

Clearly identifies a specific operation ('Get') on a specific resource ('the scene tree hierarchy from the open scene'). The output details (paginated flat list with name, type, path, child count) further distinguish it from sibling node inspection 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 clear context: it is for reading the hierarchy of the open scene, and the resource form note says to prefer it for active-session reads. However, it never explicitly contrasts it with alternatives like node_find or node_get_properties, so an agent must infer when this is the right choice.

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 important behavioral traits: create writes the initial root immediately but later mutations remain in editor memory until scene_save or save_as is called; save_as saves to a new file path; get_roots lists open scenes and flags the edited one. It also explains the canonical call shape and compatibility alias. This is strong behavioral disclosure, though it doesn't cover error cases or side effects like overwriting existing files.

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 brief intro, resource form note, and a bulleted op list. It's front-loaded with the tool's purpose and the resource form preference. The canonical call shape note is useful but slightly verbose. Overall, every section earns its place, though the op list could be tightened.

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

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

Given the tool has an output schema and 3 parameters, the description covers the main operations, their parameters, and key behavioral caveats. It doesn't explain return values (output schema covers that) or error conditions, but for an authoring tool with multiple ops, the description is reasonably complete. The main gap is lack of explicit when-to-use vs siblings, but the resource form hint partially covers it.

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. It explains the op enum values and their params: create(path, root_type='Node3D', root_name=''), save_as(path), get_roots(). It also explains root_name defaults to filename basename when empty. This adds significant meaning beyond the schema, though it doesn't document session_id or the exact shape of params for each op in full detail.

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: scene authoring with three specific operations (create, save_as, list open roots). It distinguishes itself from siblings by explicitly mentioning resource form godot://scene/current and godot://scene/hierarchy and noting 'prefer for active-session reads', which differentiates it from scene_open, scene_save, and scene_get_hierarchy.

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

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 this tool: for scene authoring operations and active-session reads via resource form. It doesn't explicitly state when NOT to use it or name alternatives, but the resource form hint and op list imply the usage boundaries. It could be stronger with explicit exclusions, but it's adequate.

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 important behaviors: the no-op case, force_reload behavior (discarding in-memory edits), the reply timing (only after editor switches, with switched flag), and the settle states ('timeout', 'not_waited'). It also handles synchronous contexts. This is rich behavioral detail beyond what any annotation might provide. Slight deduction because it doesn't explicitly mention permissions or side effects (e.g., does opening purge unsaved changes in other scenes?), but it's quite 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 moderately sized but packs a lot of necessary information. It's structured with paragraphs and list-like formatting (with backticks for parameters and field names). It front-loads the core purpose and then explains edge cases. While it could be slightly more concise (some might argue the synchronous context paragraph is dense), it's well-organized and every sentence carries meaning. Not a 5 because it lacks a summary or roadmap, but it's good.

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 that the tool has an output schema (though not shown in the prompt, it's indicated as present), the description doesn't need to explain return values. It covers all aspects needed for an agent to use it correctly: what it does, when to use force_reload, what the settle flags mean, how to handle synchronous contexts, and how to verify success. The complexity is moderate (3 params, one required), and this description is complete for the task. It even warns about follow-up writes, which is important for sequencing.

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

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

Schema coverage is 100%, so the schema already documents all parameters with descriptions. The description adds significant value by explaining the semantics of force_reload in context (discarding edits, file authority) and the meaning of the switched and settle fields. It also clarifies the no-op condition dependent on path. This goes beyond the schema's basic parameter descriptions, earning 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 tool clearly states its purpose: 'Open an existing scene file (.tscn) in the editor.' It uses a specific verb, resource, and file type. While sibling tools like scene_save, scene_manage, and scene_get_hierarchy are related, the description hints at its distinct role (opening) but doesn't explicitly differentiate from siblings like scene_manage (which might also involve opening). It's clear enough but doesn't name alternatives, so it doesn't quite reach a 5.

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

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

The description provides excellent usage guidance. It explains when force_reload is appropriate ('when the file on disk is the authority'), warns about synchronous contexts (batch_execute) returning immediately, and advises re-checking editor_state before follow-up writes when switched is false. It even notes that if path is already the current scene, it's a no-op preserving in-memory state. This gives clear when-to-use and cautionary guidance, though it doesn't explicitly name alternative tools for opening vs managing. Still, it covers usage conditions thoroughly.

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 states the tool saves to the existing path, implying a write operation, but it does not mention potential side effects like file overwriting, preconditions (e.g., an open scene), or failure modes if the scene lacks a path. This is a moderate gap for a persistence 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 two sentences with zero fluff. The first sentence states the core purpose, and the second provides essential context about when to use it. It is perfectly sized and front-loaded.

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

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

For a simple tool with one optional parameter and an output schema, the description covers the main purpose and usage context. However, it omits important operational details such as what happens if no scene is open or if the save fails, which could affect correct usage. The absence of annotation coverage makes this gap more significant.

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

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

Schema description coverage is 100%, so the session_id parameter is fully documented in the input schema. The description adds no extra meaning beyond the schema's explanation of the optional session targeting. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description clearly states the specific action: 'Save the currently edited scene to disk.' It further distinguishes this tool from sibling mutation tools by explaining that it persists in-memory changes to the existing path, which differentiates it from node/property mutation tools that only affect the in-memory scene.

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 instructs to call this tool after using node/property mutation tools to persist changes to disk, providing clear context for when it should be used. It doesn't name alternative save mechanisms or explicitly state when not to use it, but the usage context 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 provided, the description carries the full burden of behavioral disclosure. It explicitly warns that the tool 'replaces any existing script on the node' and states it is 'undoable,' which is valuable safety-relevant 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 two sentences with no wasted words. It front-loads the primary action, then immediately states the key behavioral consequences. Every sentence earns its place.

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

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

The description is complete for a simple attach operation: it states the action, the destructive replacement behavior, and undoability. The full input schema and existing output schema cover the remaining technical details. It could be slightly stronger with explicit sibling differentiation, but nothing critical is missing.

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

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

Schema description coverage is 100%, so the schema fully documents all parameters. The description does not add extra parameter semantics, but it doesn't need to; the baseline of 3 applies because the schema handles the burden.

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 and resource: 'Attach a script to a node in the scene tree.' This clearly distinguishes it from sibling tools like script_create or script_patch, which serve different purposes. It is not a tautology of the tool 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?

The description implies usage: use this when you want to attach a pre-existing script to a node. However, it does not explicitly state when to choose this over alternatives like script_create or script_manage, nor does it mention any exclusions or prerequisites.

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 excellently: it discloses overwrite behavior, editor registration, the data.cleanup.rm sidecar difference for new vs overwritten files, .gd parse validation and in-place refresh, .cs non-compilation with diagnostics_status='not_checked', and the dotnet_editor capability check. This is a thorough 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 dense but every sentence earns its place: scoping, side effects, per-extension behavior, diagnostics, and fallback routing. It is well-structured with a clear summary up front followed by relevant details, avoiding fluff while covering critical edge cases.

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 enough complexity that a brief description would be inadequate, but this one covers all decision-relevant aspects: accepted extensions, overwrite semantics, cleanup metadata, validation differences, diagnostics, and the alternative for non-script writes. An output schema exists, so return-value documentation is not the description's job, and nothing essential is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaningful semantics: path extension determines validation behavior, content is parsed for .gd but stored as text for .cs, and empty content creates a blank file. It does not add much about session_id beyond the schema, but the extension-specific behavior enriches the path and content parameters.

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

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

The description opens with a specific verb and resource: 'Create a script file on disk' and explicitly scopes to GDScript or C#, distinguishing it from generic file writes. It clearly differentiates from relevant siblings like script_patch, script_attach, and script_manage by emphasizing creation and on-disk registration.

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 clear context for when to use the tool (creating .gd/.cs scripts) and explicitly routes unsupported extensions to filesystem_manage op='write_text'. It does not explicitly contrast with script_patch or script_manage, but the creation-focused wording and overwrite semantics imply the boundary.

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 of behavioral disclosure. It states that detach is undoable, that C# support is text-only, that Godot AI does not build .NET or report C# compiler errors, and that the find_symbols response includes a 'language' field. This is strong transparency, though it does not cover all edge cases or failure modes.

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

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

The description is organized with a summary, a bulleted operation list, a language-support section, and a call-shape note. It front-loads the key purpose and keeps each section scannable. There is some length due to necessary caveats, but no major 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, the description covers the essential operational and contextual details: three ops, path format, language limitations, and call shape. It does not describe response values in depth, but the output schema exists to handle that. The only notable gap is lack of explicit comparison with script_patch/script_attach for routing decisions.

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. It does so by documenting each op's parameter (path), the resource form 'godot://script/{path}', and the canonical call shape with flat-parameter compatibility. It stops short of detailing the exact path type or the optional session_id parameter, but the core semantics are well covered.

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

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

The description clearly states the tool's scope: 'Script (.gd / .cs) reading, detachment, and outline.' It enumerates three specific operations (read, detach, find_symbols), each with a distinct verb and resource. This differentiates it from sibling tools like script_create, script_patch, and script_attach.

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

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

The description gives practical usage context, such as preferring the 'godot://script/{path}' resource form for active-session reads and clarifying that logs_read will not capture .NET compiler output. It also directs users to the editor Build panel or dotnet build for C# errors. It does not explicitly name sibling alternatives for script editing, so the guidance is clear but not exhaustive.

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 exact byte matching, failure modes, filesystem scan triggering, GDScript vs C# reload behavior, diagnostics handling, and the fact that the edit is not undoable via Ctrl+Z.

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 every sentence earns its place, covering purpose, failure modes, language-specific behavior, reload semantics, and undo limitations. It is front-loaded with the core action and then expands into necessary details.

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 an output schema and full parameter coverage, the description supplies the missing behavioral context: failure conditions, reload behavior, filesystem scan side effect, and non-undoability. An agent has enough information to invoke it correctly without consulting 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 description coverage is 100%, so the schema already documents all five parameters. The description reinforces exact-match behavior and mentions empty-deletes semantics, but adds only marginal precision 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 names a specific verb and resource: an anchor-based string-replace edit on .gd or .cs files. It clearly distinguishes itself from siblings like script_create, script_attach, and script_manage by describing an in-place patch operation.

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 behavioral conditions are explicit: exact match, failure on zero or multiple matches, and different post-edit behavior for .gd vs .cs. However, it never names alternatives or explicitly says when script_patch should be chosen over script_create, script_attach, or script_manage, so the routing is left to inference.

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

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

With no annotations, the description carries the behavioral burden and mostly succeeds: it explains exact-match precedence, which fields substring hints match against, and the ambiguity error listing candidates. It could add a note that the previously active session is replaced, but the state-transition is already clear from 'Set the active...'

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 key statement is front-loaded in the first sentence, followed by two compact sentences that fully explain matching rules. No filler or redundant repetition of the schema.

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

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

For a one-parameter state-selection tool with an output schema and full schema parameter coverage, the description is sufficient: it explains what the operation does, how the parameter is interpreted, and what happens on failure. Nothing essential is missing.

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

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

The parameter schema provides the format and examples, and the description adds important semantics beyond it: matching against short name/project_path/session_id, exact-id precedence, and the requirement that a substring resolve to exactly one session. This resolves ambiguity that the schema alone leaves open.

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 object: 'Set the active Godot editor session for subsequent tool calls.' This clearly distinguishes session_activate from sibling tools like session_manage, which would handle listing/creating/managing sessions rather than selecting the active one.

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

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

It states the context of use: before other tool calls that should target a chosen editor session. It does not name an alternative or an explicit when-not-to-use, but the 'subsequent tool calls' framing plus the exact/substring semantics give enough guidance for selection.

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

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

No annotations are provided, so the description carries the burden. It discloses that the tool lists sessions and includes metadata fields, plus the server-global exclude_domains. It does not mention side effects, read-only nature, or any potential performance implications. Since it's a listing operation, the lack of explicit read-only disclosure is a minor gap, but the description is reasonably transparent about what it returns.

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 resource form, operation list, and canonical call shape. It is concise and front-loads the key information. The metadata field list is long but necessary for completeness. No redundant 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?

The description covers the list operation thoroughly, including metadata fields and the exclude_domains response. However, it does not explain the purpose of session_id or params in the context of listing, nor does it clarify if there are other operations beyond list. Given the output schema exists, return values are covered, but the parameter semantics gap remains.

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 does not explain the parameters beyond the canonical call shape. It mentions 'op' and 'session_id' remain top-level, but does not explain what session_id is for or how params should be structured. The description adds some context about the call shape but fails to compensate for the lack of schema descriptions.

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

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

The description clearly states the tool lists every connected Godot editor with metadata, and the resource form is given. It is distinguishable from siblings like session_activate, which implies activation rather than listing. However, the title 'Session Manage' is broad and the description focuses on the list operation, so it doesn't fully clarify what other operations might exist.

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

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

The description implies usage for listing sessions and mentions a resource form preference, but it does not explicitly state when to use this tool versus alternatives like session_activate or editor_state. It also doesn't mention any prerequisites or context where listing is appropriate. The guidance is mostly implicit.

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

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

With no annotations, the description carries the full behavioral burden. It discloses that connect/disconnect are undoable, that list hides editor-internal connections by default, and that editor_connection_count reveals hidden entries. It also documents the canonical call shape and the flat-parameter compatibility alias, which are non-obvious behavioral details.

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 a one-line summary, then uses compact bulleted ops with consistent formatting. Every sentence adds useful invocation information, and the compatibility note is justified by the intentionally permissive params schema.

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

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

All three operations are fully specified, the call shape is explicit, and the output schema handles return values. The description provides enough context for correct invocation despite the very generic input schema and absence of annotations.

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

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

Schema description coverage is 0%, so the description must compensate. It does so thoroughly by providing exact per-op signatures, explaining the include_editor default, and defining how params should be structured. The names and supplied context are sufficient for an agent to invoke each operation.

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

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

The description opens with a specific resource ('Signals' in Godot) and the three operations it supports: list, connect, and disconnect. It is immediately clear what the tool does, though it does not explicitly contrast itself with sibling tools.

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

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

The op list and examples make the intended usage reasonably inferable, but the description never states when to use this tool versus an alternative or when not to use it. The include_editor guidance is useful but is parameter-level guidance, not tool-selection 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 provided, so the description carries the full burden of behavioral disclosure. It explains that the tool re-fetches the last run's payload, does not re-execute, returns full results, and that verbose=True includes every individual result. It also documents call-shape aliases. It stops short of mentioning auth or active-session failure behavior, but the core behavior is transparent.

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

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

The description is compact and well-structured: purpose, resource form, op specification, and call-shape rule. Every sentence adds useful information, and the most important details are 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?

For a single-op tool with an output schema, the description covers the operation, its non-executing behavior, the verbose flag, and the canonical call shape. It could more explicitly define session_id and name the alternative execution tool, but the active-session context and test_run reference cover most practical needs.

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. It explains the op as results_get(verbose=False) and defines verbose behavior. However, session_id is only mentioned as remaining top-level; its actual role is left implicit through 'active-session reads'. This is a partial but not complete compensation for the missing schema documentation.

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' and explicitly states it re-fetches the most recent test_run payload. It distinguishes itself from test_run by noting 'no re-execution', so an agent can immediately identify this as a read/results tool rather than an execution tool.

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

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

The description says 'prefer for active-session reads', giving a clear context for when to use this tool. It also implies the alternative by contrasting with test_run via 'same shape as test_run' and 'no re-execution', though it does not explicitly name an exclusion or say 'use test_run when you need execution'.

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 does so thoroughly. It discloses the 300s timeout and TEST_RUN_TIMEOUT behavior, the risk of a single test blocking the main thread for 20s+, the cache_warning about stale preloads, the scene_warning about main scene assumptions, and the edited_scene response field. This is rich behavioral context beyond what any schema 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 every sentence earns its place: discovery mechanism, output format, cache warning, timeout behavior, batch_execute restriction, and scene warning. It is front-loaded with the core purpose and then layers caveats. Slightly dense, but appropriate for a tool with this many behavioral nuances.

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 (5 optional params, no required params, output schema present, no annotations), the description covers all critical operational aspects: what runs, how to filter, what the response contains, timeout behavior, safety during long runs, and environmental prerequisites (main scene). An agent has enough to invoke it correctly and interpret results.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaning by explaining the default summary vs verbose output, the substring matching behavior for test_name/exclude_test_name, and the suite filtering concept. It doesn't detail every parameter's edge cases, but it adds value beyond the schema's terse descriptions.

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

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

The description states a specific verb ('Run GDScript test suites'), a resource ('inside the connected Godot editor'), and the mechanism (discovers test_*.gd, instantiates, runs test_* methods). It clearly distinguishes itself from siblings like test_manage and project_run by focusing on executing tests in-editor.

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

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

The description gives explicit when-to-use context: run suites, filter by suite/test_name, use verbose for full results. It also provides exclusions: not allowed inside batch_execute, and warns about stale preload caches requiring editor restart. It names alternatives indirectly (test_manage for partial results, scene_open for main scene) and gives clear re-run 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 zero annotations, the description carries the full behavioral burden and succeeds: it discloses validation semantics ('a non-numeric or non-finite value is refused with a structured error before anything is applied'), atomicity ('refused call leaves the theme and undo history untouched'), persistence semantics ('Slot changes are persisted immediately... the previous slot is restored, and no undo entry is committed'), and per-op undo behavior (stylebox_override 'lands in the scene's undo history'). This goes well beyond anything the schema could express.

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 the length is proportionate to the 10 sub-operations it must document. It is front-loaded with purpose and cascade behavior, organizes ops as a bulleted list with nested parameter notes, and closes with the canonical call shape. No filler sentences; every sentence earns its place.

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

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

Given the tool's high complexity (10 ops, polymorphic params, persistence and undo guarantees) and the absence of annotations, the description leaves nothing essential to inference: params, value formats, validation/rollback behavior, and the call envelope are all specified. An output schema exists to cover return values, so the description's silence on success-return shape is acceptable.

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

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

Schema coverage is 0% — the schema only declares op/params/session_id with a permissive params object and op enum. The description fully compensates by documenting every op's parameters in detail: color value formats ('#rrggbb'/'#rrggbbaa', named, or {r,g,b,a}), region formats ('{position, size} or [x,y,w,h]'), axis-stretch enums ('stretch' | 'tile' | 'tile_fit'), and per-side key conventions ('all' + per-side keys). An agent can construct a correct params dict from the description alone.

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

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

Opens with a specific scope — 'Theme authoring (Godot's stylesheet-like resource for Controls)' — and immediately adds a distinguishing behavior ('Cascades down a Control subtree when assigned via theme_apply'). The verb+resource pairing is specific enough to stand apart from siblings like material_manage, resource_manage, ui_manage, and material-related tools, so an agent can tell what domain this tool owns.

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 opening sentence establishes clear context for when to use the tool: authoring Godot Control themes, which implicitly distinguishes it from general-purpose resource_manage, ui_manage, and material_manage. Internal op routing is strong (e.g., stylebox_override is contrasted with set_stylebox_flat as a pattern used 'without mutating the theme'). It stops short of explicitly naming sibling tools with when-not-to-use conditions, so cross-tool exclusion guidance is left to inference.

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

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

With no annotations provided, the description carries the full behavioral burden. It discloses that all write operations are undoable, that operations target scene-relative TileMapLayer paths, and that specialized .tres files renumber source IDs. It does not cover error conditions or permission requirements, but for an editor authoring tool this is substantial 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 long but well organized: a brief overview, a critical source-ID remapping warning, and a flat list of operations with signatures and returns. The length is justified by the tool's complexity, though some redundancy exists between the overview and the op list.

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

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

For a multi-op tool with no annotations and no schema-level parameter documentation, this description is complete. It covers target paths, coordinate systems, source-ID remapping pitfalls, undo behavior, return shapes, and the required call envelope. An agent has enough to select and invoke any of the four 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 must compensate, and it does thoroughly. It documents each op's parameter list, explains source_id, atlas_col/atlas_row semantics, gives specialized .tres remapping examples, and describes return values. It also clarifies the canonical call shape versus the flat compatibility alias.

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).' This clearly distinguishes the tool from sibling tools like tileset_manage or gridmap_manage by naming the exact target resource and operation families.

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: all operations target TileMapLayer nodes in the currently edited scene by scene-relative pathjans, and it explains when source-id remapping matters. However, it does not explicitly state when to prefer this tool over sibling tools or when not to use it, leaving some selection judgment to the agent.

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 of behavioral disclosure. It explicitly states both operations are read-only, do not modify resource or project files, read directly without UI interaction, and includes scaling behavior, return shapes, and error codes. This is exceptional transparency for an unannotated 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 long but tightly structured: signatures, parameter docs, return values, and error codes are separated into scannable bullet sections. The visual-inspection workflow guidance is placed where it is most useful, and every sentence adds operational information rather than padding.

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-operation read-only atlas inspection tool with no annotations, this description is complete: it covers invocation shape, per-parameter semantics, return formats, error taxonomy, and use-case routing. An agent has everything needed to select and call either op 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's params field is opaque (additionalProperties: true, 0% schema description coverage), so the description must compensate. It fully does: for each op it documents tileset_path as a required res:// path, source_id as required and >= 0, and max_size with default and behavior, plus the returned JSON structure and error conditions.

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 'TileSet management — atlas inspection tools' and then enumerates two concrete operations with full signatures and behaviors. It clearly states what the tool does (inspect TileSet atlas resources) and distinguishes its visual-inspection path from editor_screenshot, so an agent can tell it apart from siblings.

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

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

The 'Atlas image workflow' section explicitly tells agents to use tileset_get_atlas_image instead of editor screenshots when they need to visually inspect tiles, and explains why: it reads directly from the resource with no UI interaction or editor state. This is explicit when-to-use and when-not-to-use guidance with a named alternative.

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 discloses important behaviors: bbcode parsing defaults on, set_richtext is undoable, build_layout validates before mutating atomically, and draw_recipe defaults to clear_existing=True. It does not cover persistence/lifecycle effects or what happens on error, but the main side effects are made visible.

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 the length is justified by five operations and their enums; it is front-loaded with a purpose statement and organized as a scannable Ops list. Minor redundant CanvasLayer/Control caveats in set_anchor_preset and build_layout keep it from being perfectly tight.

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?

It is highly complete for a minimal-schema tool with no annotations: target types, defaults, enum values, atomicity, and the invocation envelope are all covered. The remaining gap is the underspecified nested shape of draw_recipe ops, which an output schema does not resolve; otherwise the agent has enough context to invoke most ops 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%, and the description compensates with documented signatures, defaults, enums, and the build_layout tree spec. It falls short of fully specifying draw_recipe's op-object required fields (beyond naming line/rect/arc/etc.) and some build_layout fields such as anchor_margin, so an agent still has to guess some nested argument shapes.

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, 'UI / Control authoring (HUD, menus, layouts, vector decoration)', states the domain, and the Ops list gives five specific verb+resource pairs: set_anchor_preset on Controls, set_text on text-bearing nodes, set_richtext on RichTextLabel, build_layout for UI subtrees, and draw_recipe for vector drawing. This clearly distinguishes ui_manage from the generic node_manage/theme_manage siblings.

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

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

Each op provides concrete applicability guidance, e.g. 'Target must be a Control', 'CanvasLayer is the canonical HUD parent but is not a Control', and which node types set_text works on. It also gives the canonical call shape and flat-parameter compatibility. However, it never explicitly contrasts ui_manage with sibling tools or states when not to use it, so it stops short of full exclusion guidance.

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