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

The description goes beyond the annotations by disclosing that files are copied into res://, main_scene is set and opened if declared, project templates override bundled ones, and omitting template lists available options. It does not contradict the annotations, and it adds meaningful behavioral context for a tool that is not read-only.

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, with the primary action and effect front-loaded. Every sentence contributes useful information, including scope, override precedence, and the no-argument listing behavior, without redundancy or filler.

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

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

For a tool with two optional parameters, no output schema, and no nested objects, the description covers the main behaviors, parameter implications, and override semantics. It does not explicitly describe the return value or failure modes, but the listing hint and clear effect make it sufficiently complete for correct invocation.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds value by clarifying that omitting the 'template' parameter triggers a listing behavior and that project templates override bundled ones, which informs how the 'template' parameter is resolved.

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 a specific verb ('Instantiate'), a resource (bundled or project template into res://), and the concrete effect (copies files, sets/opens main_scene). It also clarifies the generic applicability across template kinds and the override behavior, making it easy to understand 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 provides clear context for when to use the tool: to instantiate bundled or project templates into res://, with project templates taking precedence. It also gives a practical usage hint ('Call with no template to list available templates'), though it does not explicitly contrast with sibling tools like instance_scene or open_scene.

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

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

Annotations show readOnlyHint=false (modifying) and destructiveHint=false, but description adds the critical 'undoable' trait, which is not in annotations. This extra context helps the agent understand the reversible nature of the operation, going beyond what annotations provide.

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

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

A single, well-structured sentence that is immediately informative. Every word adds value; no redundant or extraneous content.

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

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

The tool is simple with 2 required params and no output schema. The description covers the core semantics but omits details like what happens if the node doesn't exist, if the script is already attached, or error conditions. Adequate but not thorough for a modifying action.

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 description must compensate. It clarifies that 'path' expects a res:// URL, which is helpful, but does not explain 'target' (likely a node path) or any constraints. The partial compensation is insufficient given both parameters are required and undocumented in schema.

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

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

The description clearly states the action (attach), the resource (script with res:// path), the target (node in open scene), and an important characteristic (undoable). It distinguishes itself from sibling tools like write_script or validate_script which serve different purposes.

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

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

The description implies when to use (to attach a script to a node) but provides no explicit guidance on when not to use or alternatives among the many sibling tools. The context is clear but lacks 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?

Description discloses key behavioral traits: stops on first failure with default true, rolls back scene edits via editor undo history, does not roll back file/resource writes, and clarifies that per-step 'ok' only means handler completion. These nuances go well beyond the annotations and are critical for correctly using the 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?

Description is front-loaded with the core purpose, then packs defaults, rollback semantics, usage suggestion, and verification warning into a compact paragraph. Every sentence carries information; no filler or repetition.

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

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

For a powerful meta-tool with no output schema, the description covers execution order, failure behavior, rollback scope, per-step success meaning, and recommends verification steps. Nothing essential for an agent to decide whether and how to invoke batch_execute 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?

Input schema already documents all three parameters at 100% coverage, so the baseline is 3. The description adds behavioral meaning for 'rollback' ('scene edits...rolled back...file/resource writes are not') and for 'stop_on_error' ('Stops at the first failure'), plus the steps shape, elevating it above schema-only repetition.

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

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

Description opens with a clear verb and resource: 'Run several tool calls in one request, in order.' It explicitly frames the tool as a batch/meta executor and gives a concrete structural example ('steps = [{tool, args}]), distinguishing it from 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?

Explicit guidance appears: 'Use to collapse multi-step authoring...into one atomic call,' and it warns to verify effects with a trailing read-back step. It does not explicitly say when not to use batch_execute compared to separate calls, but the sequencing/failure semantics imply that.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false; the description adds meaningful context: isolated scratch output, no effect on the editor's loaded assembly, package restore on first build, and typical incremental build time. This goes beyond the annotation flags and discloses the tool's safety and performance characteristics, with no contradictions.

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

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

Four tightly packed sentences, front-loaded with the main purpose. Every sentence earns its place: purpose, safety, auto-detection, prerequisites, performance, and usage trigger. No filler or redundant restating of the tool name.

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

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

For a compile-check tool with two optional parameters and no output schema, this description is complete: it states purpose, output format, safety profile, system requirements, performance expectations, and when to use it. An agent has all the context needed to call 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?

The schema already documents both parameters fully (100% coverage). The description adds useful guidance by saying the .csproj is auto-detected from the project if omitted, which clarifies the optional csproj parameter's behavior beyond the schema text.

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 'Compile-check' plus the resource 'C#/.NET Godot project', names the underlying command `dotnet build`, and specifies the return format (structured diagnostics with file:line:col + CS-code). It also differentiates itself from the GDScript compile-gate (write_script), which does not cover C#.

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 last sentence explicitly states when to use it: 'Use after editing .cs'. It also contrasts with write_script's GDScript compile-gate by noting it does not cover C#, so an agent understands this tool is the C# alternative. Mention of the .NET SDK requirement and isolated build helps the agent decide if the conditions are right.

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

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

The description goes well beyond the annotations (destructiveHint: true) by detailing argument coercion rules, error behavior ('Wrong types or counts return an ERROR (never a silent no-op)'), and return format ('Returns the result as JSON'). This gives the agent a clear picture of how the tool behaves, which is particularly valuable for a generic method invocation 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 efficiently structured: one sentence for the core purpose, one for argument formatting, one for error handling, and one for the return value. Every sentence adds concrete information, and there is no redundant or filler content. It is appropriately sized for the tool's 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?

Given the tool's complexity and lack of output schema and parameter descriptions, the description provides a strong foundation: it covers inputs, coercion, error handling, and output. However, it does not fully specify the format for 'target' and 'method' parameters, nor does it mention when the destructive hint might apply in practice. Slight gaps remain, but the description is substantially 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?

With 0% schema description coverage, the description carries the full burden for parameters, and it does so well for 'args' by explaining accepted formats for vectors, colors, and object params. However, 'target' and 'method' are only implicitly described as 'resolved object' and the method name, leaving some ambiguity about their exact format (e.g., whether target is a node path or resource path).

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

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

The description clearly states the tool's function: 'Invoke a method on a resolved object.' This is a specific verb+resource combination that distinguishes it from sibling tools like set_property or runtime_get_property, which handle property access rather than method calls. The scope is well-defined with additional details about argument coercion.

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

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

The description provides clear context on what the tool does, but does not explicitly state when to use it over alternatives or provide exclusions. It implies usage for calling methods on objects, but does not mention scenarios like setting properties or other sibling operations, leaving the 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?

Annotations (readOnlyHint=false, destructiveHint=false) indicate a non-read, non-destructive operation. The description adds 'undoable' context, enhancing transparency. However, it does not disclose potential side effects such as validation or node existence requirements, leaving some behavioral gaps.

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

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

Two concise sentences that front-load the core action and critical context (undoable, node path format). Every word serves a purpose 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?

The description explains the persistence and undoability, and hints at parameter format, but omits details about signal and method parameters, return values, and error conditions. For a 4-parameter tool with no output schema, this leaves moderate gaps.

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

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

Schema description coverage is 0%, so the description must compensate. It only explains 'from' and 'to' as node path/name, but provides no semantics for 'signal' or 'method'. This is insufficient for an agent to understand all parameter roles.

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

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

The description clearly states the action: 'Connect a node's signal to a method on another node'. It specifies the verb (connect) and the resources (node's signal, method on another node), distinguishing it from siblings like disconnect_signal and call_method.

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 persistent connections with 'persisted into the scene (undoable)' and clarifies that from/to are node paths/names. It does not explicitly contrast with alternatives like disconnect_signal or call_method, but the context is clear enough for an AI 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?

Annotations indicate readOnlyHint=false and destructiveHint=false, but the description adds the important behavioral trait 'undoable', which is beyond the annotations. It also clarifies the operation is not destructive despite being a write.

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

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

The description is extremely concise with two short sentences. Information is front-loaded, with no redundant or unnecessary words.

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

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

Given the simplicity (3 params, no output schema), the description meets basic needs but lacks details on error scenarios (e.g., invalid class), duplicate name handling, or return value. It does not fully compensate for the missing output schema.

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

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

The description adds limited value beyond the input schema: it reiterates the parent default but does not explain the 'name' parameter or provide additional syntax/format guidance for 'type' (though schema gives an example). Schema description coverage is high but still missing details for 'name'.

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 verb 'Create' and resource 'node', with specific context: 'of the given class', 'add it to the open scene', and 'undoable'. This distinguishes it from sibling tools like delete_node or duplicate_node.

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

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

The description explains the 'parent' parameter's default behavior but does not provide explicit when-to-use, when-not-to-use, or alternatives among siblings, such as instance_scene or other creation methods.

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

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

The description aligns with annotations (destructiveHint=true) by stating it saves to a path, implying file creation. However, it does not disclose whether existing files are overwritten, permission requirements, or error states. With annotations already indicating destructiveness, the description adds minimal behavioral context beyond reinforcing the creation action.

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

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

The description is a single 20-word sentence that conveys the main action and optional feature. It is front-loaded with the key verb and resource. No unnecessary words, but could be more structured (e.g., separate optional parameters). Still, it earns its place.

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

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

Given the tool's simplicity (3 params, no output schema), the description covers the core function. However, it lacks details on overwrite behavior, error handling, and return value. Compared to sibling 'set_resource', it should clarify that it creates new files. The description is adequate but not fully comprehensive.

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

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

The schema covers only 33% of parameters (path has description). The description compensates by mentioning 'class' and 'path' implicitly, and adds that properties is an optional dict for initial values. It also clarifies that path should end in .tres/.res, which is useful semantic detail not in the schema. While not exhaustive, it adds value beyond the schema for 2 of 3 params.

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

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

The description clearly states the action (create), the resource type (Resource of given class), and the destination (res:// path ending in .tres). This distinguishes it from siblings like 'set_resource' which likely updates existing resources. The verb+resource+destination pattern 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?

No guidance on when to use this tool versus alternatives like 'set_resource', 'write_file', or 'instance_scene'. It does not specify prerequisites, error conditions, or scenarios where this tool should be avoided. The description lacks any usage context beyond the basic operation.

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

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

Annotations already mark it destructive, and the description adds 'undoable', which is a behavioral trait not covered by annotations. This helps the agent understand the operation is reversible.

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

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

The description is a single sentence with no wasted words, but it omits critical parameter semantics. While concise, it sacrifices completeness for brevity.

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 deletion tool with one parameter and no output schema, the description should at least specify the expected format of 'target' and potential side effects on child nodes. It is underwhelming.

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 sole parameter 'target' has no description in the schema or the tool description. With 0% schema description coverage, the description fails to explain what value the parameter expects (e.g., node path, name).

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

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

The description clearly states the action ('Remove a node from the open scene') and the undoability. It differentiates from siblings like create_node, duplicate_node, rename_node, etc.

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

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

The description provides no guidance on when to use this tool versus alternatives such as reparent_node or duplicate_node. It lacks context for prerequisites or typical use cases.

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

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

Annotations already indicate readOnlyHint=true and destructiveHint=false, confirming a safe read. The description adds that it returns signatures of properties and methods, which is useful but does not heavily elaborate beyond what is obvious from the name and annotations.

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

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

Two sentences, zero filler. The first sentence clearly states the action and output, making 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?

With no output schema, the description could explain the return format (e.g., JSON structure). It mentions 'with signatures' but does not describe the structure, leaving some ambiguity for a complex tool.

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

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

Schema coverage is 50%; the 'inherited' parameter has a description. The description implies 'class' is the class name (e.g., 'Node2D') but does not specify format or provide examples, partially compensating but not fully.

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 verb 'List' and the resource 'a class's properties and methods (with signatures)', and explicitly connects to sibling tools 'set_property' and 'call_method'. It distinguishes itself from siblings like 'find_classes' by positioning itself as the discovery key for full domain coverage.

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 context: before calling 'set_property' or 'call_method'. However, it does not explicitly state when not to use it or mention alternatives like 'find_classes' for just listing class names.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the tool is known to be safe. The description adds meaningful behavioral context: it resolves live nodes during gameplay, reports the scope in the answer, and clarifies that edited-scene and running-game paths share syntax but differ in meaning. This goes well beyond the annotation baseline.

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, but every clause adds value: the first states the core action, the second explains target variants, live resolution, the runtime_get_property relationship, and the scope-reporting behavior. No redundancy or filler.

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

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

For a single-parameter read-only tool with no output schema, this description is complete: it explains the input format, the resolution logic, the fallback, and the return behavior (JSON properties with scope indication). It gives the agent all necessary information to select and invoke the tool correctly.

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

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

The input schema provides only a bare 'target' string with 0% description coverage, so the description carries full responsibility. It thoroughly explains what target can be: a res:// path, a node name/path in the open scene, or a class name with fallback to describe_class. It also explains live-node resolution, fully compensating for the schema's lack of 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 opens with a specific verb and resource: 'Dump a live object's properties as JSON.' It clearly distinguishes itself from sibling tools by defining the target resolution scope (res:// path, node path, class name fallback) and explicitly connecting to runtime_get_property for live-node resolution.

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

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

The description provides clear context on when to use the tool by enumerating accepted target types and noting fallback behavior to describe_class. However, it does not explicitly state when NOT to use this tool or name a preferred alternative for getting class definitions or single properties, 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?

The description adds 'undoable' which communicates revertibility, a useful behavioral detail. It also states 'previously connected' which sets a precondition. This adds context beyond the readOnlyHint=false and destructiveHint=false annotations.

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

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

The description is a single, focused sentence with no extraneous words, earning a high score for structure.

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

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

For a tool with 4 required parameters and no output schema, this description is too thin. It does not explain parameter roles, what 'undoable' means precisely, or what happens if the signal isn't connected.

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

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

The schema descriptions cover 0% of parameters, and the description offers no parameter semantics. The parameter names (from, to, signal, method) provide weak hints but are undefined, so the agent must infer meaning.

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

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

The description uses the specific verb 'Disconnect' and the resource 'signal', making the tool's action clear. The qualifier 'previously connected' sets scope and distinguishes it as the inverse of connect_signal among 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 phrase 'previously connected' implies the tool should be used when undoing a signal connection, but it does not explicitly name alternatives or exclusions, leaving the usage guidance 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?

Even though readOnlyHint and destructiveHint annotations already cover safety, the description goes far beyond them by disclosing what the tool reports, including config freshness, runtime-bridge liveness, context cost by effort tier, and editor behaviors that affect automation. It also surfaces a non-obvious consequence: with auto-reload off, scripts 'wait behind a modal the human must click.'

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 and long, but every clause contributes meaningful behavioral or usage information. The core purpose is front-loaded, though the single extended sentence could be better structured as a list for faster parsing.

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 no-parameter diagnostic tool with an output schema, the description fully covers purpose, usage, what to expect, and why it matters. It even includes cost-awareness context and specific environmental conditions that affect calling other tools, leaving no meaningful gap.

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

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

This tool has zero parameters and the schema reflects that, so there are no parameter semantics for the description to add. Per the baseline for tools with no parameters, this earns a 4 rather than a 3 because there is no possible parameter gap.

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

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

The description names the tool as 'Beckett self-diagnosis' and states it 'one call answers why can't the agent see or do X?', providing a specific verb, resource, and observable outcome. It also distinguishes the tool from siblings by describing it as the broad diagnostic entry point rather than a subsystem-specific 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 explicitly says 'Run this FIRST when unable to see or perform an action' and tells the agent to prefer targeted siblings like logs_read for logs or game_logs for runtime output. This gives clear when-to-use and when-not-to-use guidance with named 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?

Adds meaningful behavioral details beyond annotations: the operation is undoable, duplicates children recursively, and keeps the same parent. Annotations only indicate it is not read-only and not destructive, so this extra context is valuable for agent prediction.

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?

One efficient sentence with all key information: action, recursive behavior, parent placement, undoability, and optional name. No fluff, front-loaded with the core purpose.

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

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

The description covers the essential behavior: same-parent duplication, children included, undoable, and optional naming. Minor gaps remain: no mention of default naming if 'name' is omitted, and no return value info, but these are not critical for a straightforward duplication operation.

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

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

With zero schema description coverage, the description clarifies both parameters: 'name' is the optional copy name, and 'target' is the node to duplicate (implied by 'Duplicate a node'). While target format is not explicit, the meaning is clear enough for a two-parameter tool.

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 ('Duplicate') and resource ('a node (with its children) under the same parent'). It clearly distinguishes from sibling tools like create_node (new node), move_node, and reparent_node by specifying same-parent duplication and child inheritance.

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 context: use this tool when you need to copy an existing node and its subtree in the same location. However, it does not explicitly mention alternatives or when not to use it, leaving the agent to infer from sibling names.

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

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

Annotations already mark it read-only and non-destructive. The description adds useful behavioral context: it searches by name substring, includes both engine and project types, and supports a base-class filter. It doesn't discuss result format, but it signals that describe_class is needed for details, which further clarifies 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?

Three sentences, each earns its place. Main action is front-loaded, the optional base parameter is explained with an example, and the intended pairing with describe_class is stated. No redundant information.

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

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

For a read-only search tool with three optional parameters and no output schema, the description covers the essential semantics and the follow-up workflow (pair with describe_class). It could specify the return type (e.g., list of class names), but the 'discovery entry point' phrasing makes that reasonably inferable.

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

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

Schema covers all three parameters with descriptions (100% coverage), so baseline is 3. The description adds meaning beyond the schema by explaining the 'base' parameter with a concrete example (base=Node2D) and framing the query as matching both engine and project class names. That additional context justifies 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?

Description states a specific verb ('Search') and resource ('classes by name substring'), and explicitly scopes the search to engine classes plus project types. It also positions itself as 'The discovery entry point', distinguishing it from related tools like describe_class.

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 clearly indicates when to use it—as the discovery entry point—and names describe_class as the next step, giving an explicit workflow. It doesn't explicitly contrast with find_methods or search_files, but the class-specific scope and pairing instruction provide sufficient guidance.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds behavioral context beyond annotations: results are invokable via call_method, and the optional class restriction includes inherited members. This extra information is valuable and does not contradict the annotations.

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

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

The description is two short sentences, front-loaded with the verb and resource, and contains no filler. Every phrase adds value, making it highly concise and well-structured for quick comprehension.

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

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

Given the tool's simplicity (3 params, no output schema, annotations covering safety), the description sufficiently covers purpose, key parameters, and a workflow hint. It explains the optional class restriction and the invokability of results, making the tool's behavior clear 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?

With 0% schema description coverage, the description partially compensates by explaining 'query' as a name substring and 'class' as an optional restriction including inherited. 'max' is not described, but its purpose is intuitive from its name and common usage. The description adds meaning for the two core parameters, though not exhaustive.

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

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

The description clearly states the tool's function: 'Search methods by name substring' and notes an optional class restriction. It distinguishes itself from sibling tools like find_classes (which searches classes) and call_method (which invokes methods) by focusing on method name search.

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

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

The description implicitly indicates usage: find methods by name to later call them, reinforced by 'Any result is invokable via call_method.' While it doesn't explicitly contrast with alternatives, it provides a clear workflow context. No exclusion criteria are given, but the primary use case is evident.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds meaningful behavioral detail: it matches both native classes and custom class_name scripts, warns that is_class alone misses custom nodes, defines name as substring, sets path/recursive/max defaults, and clarifies 'LIVE'/'RUNNING' scope. This goes well beyond the structured annotations.

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

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

The description is dense but efficient: it front-loads the primary purpose and output, then quickly enumerates parameter meanings. Every clause adds useful information, and there is no filler or repetition.

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

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

For a query tool with five optional parameters and no output schema, the description covers the tool's purpose, output format (paths), parameter semantics, defaults, and scope. The annotations handle the read-only/destructive safety profile, so nothing critical is missing for correct invocation.

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

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

Schema coverage is 0%, but the description compensates by explaining every parameter: 'class' matches native/custom classes, 'name' is a substring, 'path' is the scope root, 'recursive' and 'max' are explicitly described with the default for max. This is strong compensation for the schema's lack of 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 ('Find'), a specific resource (LIVE nodes in the RUNNING game), and query criteria (type and/or name), and it names the output (paths for runtime_* tools). This clearly distinguishes it from siblings like get_scene_tree or find_classes by emphasizing live runtime nodes.

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 context for when to use this tool: when you need live node paths for runtime_call/runtime_get_property/runtime_set_property. It also explains what 'class' and 'name' matching do, which helps the agent decide if this tool fits. It does not explicitly exclude alternatives, but the use case is well scoped.

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 readOnlyHint=true, the description transparently discloses a side effect: 'clear=true empties the buffer after reading.' It also explains the real-time/no-file-logging behavior, level filtering effects, and default limits, going well beyond what the annotations convey.

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

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

The description is dense but every clause earns its place: purpose, distinguishing comparison, and all parameter semantics are packed into a compact paragraph. It is front-loaded with the most important fact and does not waste words.

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

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

With no output schema and sparse parameter schemas, the description carries a heavy burden and meets it. It explains what output is captured, how to filter levels, how to limit and filter results, and how to clear the buffer. Nothing essential is missing for an agent to call the tool correctly.

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

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

Schema coverage is only 25%, with only the level parameter documented. The description compensates fully: level behavior is explained (error default, warning adds warnings, all adds print/stderr), limit default is given as 100, filter is described as substring, and clear's buffer-emptying effect is 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?

The description opens with a specific verb and resource: 'Read the RUNNING game's captured output off the runtime channel.' It enumerates exactly what is captured (script errors with stack traces, push_error/push_warning, print) and explicitly distinguishes itself from the file-based sibling logs_read.

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

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

The description directly states when this tool is the right choice: it is 'the play->see-error->fix signal' and covers the 'blind spot logs_read (file-based) can't reliably cover.' This gives the agent a clear comparative decision rule without needing to inspect either tool's implementation.

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

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

Annotations already provide readOnlyHint=true and destructiveHint=false, and the description is consistent with a read-only operation. The description does not add extra behavioral context such as return format or error handling, but given the tool's simplicity, the annotations are sufficient.

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

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

The description is a single sentence of seven words, with no redundant information. It is front-loaded and concise, earning full marks for structure.

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

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

This is a very simple tool with no parameters, no output schema, and annotations covering its safety. The description fully specifies the tool's function, leaving no gaps in understanding.

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

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

The tool has zero parameters, and the baseline for 0 params is 4. There is no parameter information needed, and the description does not need to compensate for any schema gaps.

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 specifies the action 'Return' and the resource 'running Godot engine version info', clearly distinguishing it from sibling tools like get_scene_tree or get_performance_monitors. It is a precise, unambiguous statement of 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 clearly indicates when to use this tool (when you need version information) and given its simplicity, no exclusions or alternatives are necessary. The context is clear enough for an agent to select this tool appropriately.

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

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

Annotations only declare readOnlyHint and destructiveHint, so the description carries the behavioral burden. It transparently discloses that values are real engine counters rather than estimates, that editor-target sampling windows are refused, and that duration_s>0 returns per-monitor min/avg/p95/max stats. This goes well beyond what annotations alone 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?

Three dense sentences with no filler. The resource and action are front-loaded, the key behavioral differentiator ('never estimates') appears early, and the pointer to help(tool=...) is a deliberate, useful routing rather than unnecessary prose.

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 4-parameter schema, read-only annotations, and an output schema, the description covers the important choices: target mode, duration semantics, and the editor refusal. The only deferred content is the detailed sampling/refusal reasoning, but the description explicitly names the help command for it. A small omission is that the prose leaves out the 'auto' target value present in the schema, though the schema itself documents 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 coverage is 100%, so the baseline is 3. The description additionally clarifies target's default behavior ('game default with a play session') and explains the consequence of duration_s>0 (sampling over time with per-monitor statistics). This is genuine added meaning, though interval_ms and series remain documented only in the schema.

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

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

The description opens with 'Profiling: read Performance monitors' and enumerates the exact metric families (fps, frame time, memory, counts, draw calls, video mem, physics), so an agent immediately knows the specific resource and verb. It also adds the qualitative distinction 'measured engine counters, never estimates,' which separates this from other read-style tools.

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

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

The description gives clear usage context: target can be game or editor, game is the default with a play session, duration_s>0 triggers time-sampled collection, and an editor-target window is refused. It points to help(tool=...) for the sampling rules and refusal reasoning. It does not explicitly name sibling alternatives, but the profiling context and target rules are enough to guide invocation.

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

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

Annotations already declare readOnlyHint true and destructiveHint false, so the safety profile is known. The description adds value by specifying exactly what state is reported (scene playing, channel connected), which is useful behavioral context beyond the annotations.

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

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

A single, front-loaded sentence that communicates the tool's purpose with no wasted words. It is appropriately sized for the tool's simplicity.

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

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

For a tool with no parameters and no output schema, the description adequately explains the return value's semantics. It tells the agent what information will be reported, making the tool complete for its low complexity.

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

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

There are zero parameters, so the baseline is 4 per the rubric. The description correctly focuses on output meaning since no parameters exist to explain.

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 'Report' and clearly identifies two distinct pieces of information: scene playing state and runtime channel connection state. This precisely distinguishes it from sibling tools like get_scene_tree or play_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 implies a clear use case: when an agent needs to know if a scene is playing or if the runtime channel is connected. It does not explicitly state exclusions or alternatives, but the context is clear enough for straightforward selection.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description aligns with this by saying 'Read'. The description adds the detail about property path syntax but does not disclose additional behavioral traits such as return format or error behavior. With annotations present, this is acceptable but not outstanding.

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

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

The description is a single sentence that communicates the core purpose and the key parameter usage without wasted words. It front-loads the primary action and resource.

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

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

Given the tool's simplicity (2 params, no output schema), the description provides sufficient information for basic usage: what the tool reads and how to pass the property path. It could be enhanced by describing the return value, but the read operation's intent is clear enough for this context.

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

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

Schema description coverage is 0%, so the description is the only source of parameter meaning. It clarifies that 'setting' is the property path and 'name' is an accepted alias, which meaningfully compensates for the schema's lack of descriptions. However, it does not enumerate all possible values or explain why both fields exist beyond the alias statement.

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: 'Read a ProjectSettings value by its property path'. It specifies the resource (ProjectSettings) and the operation (read), and distinguishes it from the sibling 'set_project_setting' by using 'Read'.

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

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

The description gives clear context on how to use the tool, including the property path format and that 'setting' is the primary parameter with 'name' as an accepted alias. It does not explicitly mention when not to use it or point to alternatives, but the read/write distinction from siblings is implicit in '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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description need not repeat safety. It adds the context of a 'static scan' and enumerates the exact data collected, which helps the agent predict behavior without contradicting annotations.

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

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

The description is a single sentence that front-loads 'Project overview' and lists the metrics compactly. No fluff or irrelevant 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?

For a zero-parameter tool without an output schema, the description conveys the breadth of return data. It could be slightly more explicit about the output format (e.g., a structured object), but the listed items make the return value largely predictable.

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

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

The tool has zero parameters, so the baseline is 4. The description adds no parameter-specific semantics, but none are needed since the schema already covers everything (empty properties).

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 provides a project overview with specific metrics (file/script/scene/resource counts, GDScript lines, autoloads, main scene, input-action count, Godot version). It distinguishes itself from sibling tools like get_godot_version by offering a broader 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 phrase 'Project overview' implies a clear use case for a high-level summary, and 'Read-only static scan' indicates safe, non-interactive usage. However, it does not explicitly name alternatives or exclusion criteria, so it falls short of full guidance.

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

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

Annotations already mark the tool as read-only and non-destructive, and the description adds meaningful behavioral context: it returns a tree with node_count, may set a truncated flag, applies default limits, and can collapse identical leaf siblings. This goes well beyond the annotations and gives the agent a clear model of the tool's 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 compact, front-loading the core purpose before diving into parameter details. Each sentence adds necessary information: purpose, token warning, parameter semantics, and return shape. There is no filler or repetition.

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

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

For a tool with no output schema and zero schema descriptions, the description is remarkably complete. It explains the live/runtime distinction, scoping constraints, all parameters with defaults, collapse behavior, and the return object shape. An agent has enough context to invoke this tool 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 description coverage is 0%, so the description carries the full burden—and it delivers. Every parameter is explained: path, depth, max_nodes, max_children, and collapse, including defaults and example usage. This is exemplary parameter documentation for an otherwise bare schema.

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

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

The description clearly states the tool dumps the live scene tree of the running game, with a specific verb and resource. It explicitly identifies itself as the runtime counterpart of get_scene_tree, which distinguishes it from a likely sibling. This is precise and easy for an agent to disambiguate.

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 practical guidance: scope the query to avoid token limits, and explains the control parameters. It references get_scene_tree as the counterpart, implying a usage distinction, but does not explicitly state when to prefer this tool over alternatives. The guidance is strong but not fully 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral detail about the return content (name/class/script, nested), which goes beyond the annotations and helps set expectations for the response.

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

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

The description is a single, front-loaded sentence that uses a specific verb and resource. Every word adds value, and there is no redundancy or filler.

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

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

For a simple, parameterless, read-only tool, the description adequately explains what the tool does and what the output contains (name/class/script, nested). No output schema is present, so the description carries the responsibility for return-value context, and it does so clearly.

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

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

The tool has zero parameters, and the baseline is 4. The description clarifies that the tool operates on the currently open scene, which is an implicit context parameter, but since there are no explicit parameters, the schema and description together are fully sufficient.

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

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

The description clearly states the action ('Return'), the target resource ('node tree'), and the specific context ('scene currently open in the editor'). It distinguishes from the sibling tool get_remote_tree by specifying 'in the editor', which is a unique qualifier.

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

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

The description provides clear context for when to use the tool: when needing the node tree of the currently open editor scene. It does not explicitly mention alternatives or exclusions, but the 'in the editor' phrasing implicitly separates it from remote/runtime tools like get_remote_tree, so the usage 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?

Annotations already establish the read-only, idempotent, non-destructive nature of the tool. The description adds behavioral context by explaining that the output is a syntax catalogue and worked examples, and that bare help() returns a documentation index, which is useful beyond the annotation hints.

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

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

Two concise sentences deliver the core purpose, usage pattern, and fallback behavior without wasted words. The most important information is front-loaded.

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

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

For a simple meta-tool with one optional parameter, the description fully covers invocation, output behavior, and fallback usage. No output schema is present, but the description adequately conveys what the tool returns.

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 description already fully covers the tool parameter and the omit-for-index behavior at 100% coverage. The description reinforces this but does not add meaning beyond the schema, so the baseline score of 3 is appropriate.

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

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

The description clearly identifies this as a meta-tool providing full syntax, argument catalogues, and worked examples for other tools. It specifies both the bare help() form and the help(tool="NAME") form, making its purpose unmistakable.

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

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

The description gives explicit guidance: call help(tool="NAME") before an uncertain call, and use bare help() to see what is documented. This is direct, actionable, and leaves no ambiguity about when to use the tool.

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

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

The description adds 'undoable' which is not conveyed by the annotations (readOnlyHint=false, destructiveHint=false). This provides useful behavioral nuance about reversibility. It does not contradict annotations.

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

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

A single sentence that is front-loaded with the verb and contains no filler. Every word contributes value, making it highly concise and well-structured.

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

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

With three parameters, no output schema, and sparse annotations, the description is too brief. It omits prerequisite details beyond 'open scene', how parent and name are used, and error/edge-case behavior. The tool is under-specified for an agent to use reliably.

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 only 33% (only 'scene' is described). The description does not explain the 'name' or 'parent' parameters, and the 'scene' hint in the description largely repeats the schema. It fails to compensate for the low schema coverage.

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

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

The description clearly states the action (instantiate), the resource (a packed scene with res://*.tscn), and the target (as a child in the open scene). This distinguishes it from siblings like open_scene or create_node.

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

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

The phrase 'in the open scene' implies the prerequisite of an open scene, providing clear context. However, it does not explicitly mention alternatives or when not to use this tool, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds the behavioral constraint that paths are restricted to res:// directories, which is useful. It does not mention sorting, recursion, or hidden files, but for a read-only list operation this is acceptable.

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

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

The description is a single, compact sentence that front-loads the action and resource. Every word contributes meaning, with no redundancy or filler.

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

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

For a simple read-only listing tool with one parameter and no output schema, the description provides the essential facts: what is listed (entries) and where (res:// directory). While it doesn't state return format or recursion, these are less critical for such a well-scoped operation.

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

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

Schema description coverage is 0%, so the description must compensate. It does by indicating the 'path' parameter should be a res:// directory, giving meaning to the otherwise bare string parameter. However, it does not explicitly map the parameter name to this semantics or address the optional/required nature.

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 'List entries (dirs + files) of a res:// directory' uses a specific verb 'List' and clearly identifies the resource and scope (res:// directory, dirs + files). This distinguishes it from sibling tools like search_files or read_file, making the tool's purpose unambiguous.

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

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

The description clearly implies when to use the tool: whenever an agent needs to enumerate directory contents under res://. No explicit exclusions or alternatives are stated, but the context is sufficiently clear for a straightforward listing operation.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, establishing this as a safe read operation. The description adds behavioral context by detailing the output structure ('target node + method'), going beyond what annotations provide. It does not mention any side effects, which is consistent with the read-only 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 a single, concise sentence that conveys the core purpose and output details without unnecessary words. It is well-structured and immediately understandable.

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

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

For a simple tool with one parameter and no output schema, the description is mostly complete: it states what is listed (signals) and the output structure (connections with target node and method). Minor ambiguity remains about whether all signals are returned or only ones with connections, but overall it is sufficient for the tool's simplicity.

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

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

With 0% schema description coverage, the description must compensate for the parameter 'target'. It implies that 'target' refers to the node whose signals are listed, but it does not specify the expected format (e.g., node path, name) or provide explicit parameter guidance. This partial compensation is not fully sufficient for a parameter with no 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 uses a specific verb ('List') and resource ('a node's signals and their current connections'), clearly distinguishing this tool from siblings like connect_signal, disconnect_signal, and call_method. It precisely states what the tool does without 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 implies usage context ('List a node's signals') without explicitly stating alternatives or exclusions. The purpose is clear enough to know when to use it, but no direct comparison to sibling inspection tools is provided, so it doesn't fully meet the 'alternatives' criterion.

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

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

Annotations already mark the tool as read-only and non-destructive. The description adds useful operational context: file logging is off by default, the result will indicate how to enable it, and this reads the editor/played game log file. It does not contradict the annotations, though it could clarify the success return format.

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: the core action and scope come first, followed by explicit sibling guidance and a terse parameter list. Every sentence contributes meaningful information 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?

For a simple read-only tail tool with optional parameters, the description covers the non-obvious pieces: the fallback role, the file-logging prerequisite, and the distinction from game_logs. Since there is no output schema, a bit more detail about the successful return shape would make it fully complete, but 'tail' strongly implies returned log lines.

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

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

Schema coverage is 100%, and the description mostly repeats what the schema already says: level, filter, lines, and path override. It adds no significant new parameter semantics beyond the schema, so the baseline of 3 applies.

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

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

The description clearly states a specific verb ('Tail') and resource (Godot's log FILE), and explicitly contrasts it with game_logs as the runtime channel. This differentiates it from siblings like read_file and game_logs without needing to inspect schemas.

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

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

It explicitly says to prefer game_logs for real-time runtime errors, describes this tool as a fallback, and warns that file logging must be enabled. This gives concrete when-to-use and when-not-to-use guidance.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context by specifying that sampling occurs 'over several frames' and that it returns a 'sample series', which is not evident from annotations alone. It does not contradict annotations.

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

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

The description is a single, front-loaded sentence that begins with the verb 'Sample' and includes the key purpose. It is concise, with no redundant words, and every phrase earns its place.

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

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

The tool has no output schema, four parameters with no descriptions, and no mention of failure conditions, return format details, or how the sample series is structured. The description is minimal and leaves significant gaps for an agent attempting to invoke this tool correctly, especially without parameter explanation.

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

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

The schema has zero description coverage for all four parameters, so the description must compensate. It only vaguely references 'a node's property' and 'over several frames' without explicitly defining path, property, samples, or interval_ms. The numeric parameters and their units are left entirely implicit, which is insufficient.

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 samples a node's property over multiple frames in the running game, with a specific purpose of detecting movement or changes. This verb+resource+context structure distinguishes it from siblings like runtime_get_property, which reads a single value, and render_probe, which deals with rendering.

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

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

The description implies when to use it ('detect movement/changes') and clearly conveys its temporal sampling nature, but it does not explicitly mention alternatives or situations where it should not be used. This gives clear context without exclusions, matching a score of 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?

Annotations declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, indicating a mutation that is not destructive. The description adds the useful behavioral detail that the operation is 'undoable', which goes beyond the annotations. It does not discuss edge cases like invalid indices, but the undoable note adds meaningful 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 a single sentence that immediately states the action and scope, with no filler. It is concise and front-loaded.

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

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

For a tool with two required parameters and no output schema, the description is sparse. It omits parameter format details, index semantics, and any error/return behavior. Given the low schema coverage and lack of annotations beyond the basics, more detail is needed for reliable usage.

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 clarify the meaning of 'target' and 'to_index'. It does not specify that target is likely a node path/name, nor does it explain whether to_index is zero-based or what happens on out-of-range values. This leaves the parameters under-explained.

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 ('Reorder') and identifies the resource ('a node within its parent') and the operation's focus ('to a new child index'). This clearly distinguishes it from the sibling reparent_node, which moves a node to a different parent.

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

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

The phrase 'within its parent' implies the tool is for reordering siblings, not reparenting, but it does not explicitly say when to use this tool versus reparent_node or other node operations. No exclusions or alternatives are mentioned, only an implied scope.

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

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

The description adds the behavioral detail that it makes the scene the edited scene, which goes beyond the annotations. However, it does not mention potential side effects like handling unsaved changes, which is a mild gap for an operation that changes editor state.

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

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

The description is a single, front-loaded sentence that states the action, the parameter format, and the outcome in a concise manner. Every word contributes, with no filler or redundant information.

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

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

Given the low complexity (one parameter, no output schema, simple action), the description covers the essential aspects: what it does, how the path is specified, and the result. It could mention error behavior, but for a straightforward editor command, this is largely sufficient.

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

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

The schema only provides the parameter name 'path' with a string type and no description (0% coverage). The description compensates by specifying the format as a res:// path, which adds meaningful semantics beyond the bare schema.

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

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

The description uses a specific verb ('Open') and resource ('scene'), and explicitly identifies the res:// path format and the editor context. The parenthetical clarifies that it sets the edited scene, distinguishing it from sibling tools like instance_scene or play_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 clearly implies usage for editing a scene in the editor, distinguishing it from playing or instancing. It provides context that this tool is for making a scene the current edited one, though it does not explicitly state when not to use it or name alternatives.

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

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

Annotations only carry generic hints, so the description carries the burden. It discloses the wait-then-logs flow, that on_ready property writes are queued and applied when the game connects, and the restart-boundary limitation. No contradiction with annotations.

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

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

Every sentence adds a distinct fact: action, target resolution, wait/log check, on_ready timing, and pointer to full shape. Dense but no filler and logically ordered.

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 three-parameter action with no output schema and weak annotations, it covers invocation, target selection, post-conditions, and the advanced on_ready use case. It leaves precedence between scene and current implicit and does not state a return value, but neither is critical for this command.

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 67% and leaves current undocumented, but the description explains all three parameters: res:// scene, current=true open scene, and on_ready property writes with retry behavior via help. This adds meaning the schema lacks.

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 the action explicitly ('Play a scene in the editor') and resolves all three play-target cases (specific res:// path, current scene, main scene). This separates play_scene from siblings like open_scene and stop_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?

Provides clear post-conditions: wait for play_started and check logs for errors. It also identifies on_ready as the mechanism for runtime writes that batch_execute cannot apply across the restart boundary, though it does not name other alternatives like open_scene explicitly.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds the scoping constraint of res:// or user:// paths, which is useful, but does not elaborate on error handling or return behavior. This is adequate given the annotations.

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

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

The description is a single concise sentence with no filler. It front-loads the action and resource, and every word contributes meaning.

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

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

For a read operation with one parameter and strong annotations, the description covers the essential information: what it reads and from where. No output schema exists, but the tool's simplicity means the description is sufficient for an agent to select and invoke 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?

The schema provides no description for the 'path' parameter (0% coverage), so the description must compensate. The phrase 'by res:// (or user://) path' clarifies the expected format, which is essential for correct invocation. It does not explain whether the path is case-sensitive or how to reference files outside these schemes, but the key semantic is provided.

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

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

The description clearly states the tool reads a text file, using the specific verb 'Read' and identifying the resource type ('text file') and path scheme ('res:// or user://'). This distinguishes it from sibling tools like read_script or logs_read.

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

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

The description implies the tool is for reading text files from Godot's res:// or user:// paths, but it does not explicitly contrast it with alternatives such as search_files or read_script. There are no exclusions or explicit when-not-to-use conditions, so the guidance is only 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?

Annotations declare readOnlyHint=true and destructiveHint=false, and the description adds the res:// scope. However, it does not disclose return format, error behavior, or encoding. The description aligns with annotations.

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

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

The description is one concise sentence, front-loading the verb and resource. Zero wasted words.

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

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

For a simple read tool, the description is minimal but lacks explicit return value and usage context. Given no output schema, the agent must infer the return content. The description is adequate for basic use but leaves some gaps.

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

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

The schema provides only a 'path' string with no description. The description clarifies that the path is relative to res://, which compensates partially, but it does not specify path format or any constraints.

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

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

The description clearly states the tool reads a script/text file and specifies the source location as res://. This is specific and distinguishes it from similar sibling tools like read_file.

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

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

No guidance is provided about when to use this tool instead of alternatives like read_file, search_files, or write_script. The description only states the function without any context 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?

Annotations already indicate readOnlyHint=false and destructiveHint=false. The description adds 'undoable,' a behavioral trait not captured in annotations, clarifying that the mutation is reversible. 'In the open scene' further scopes the operation. This provides valuable context beyond the structured 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 one sentence, efficiently conveying the purpose and a key behavioral trait. It is front-loaded with the action and resource, with no wasted words or redundant information.

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

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

For a simple tool with two parameters and no output schema, the description provides the essential information: what it does, where (open scene), and a behavioral note (undoable). The missing parameter details are a minor gap, but overall the description is sufficient for an agent to understand and invoke the tool correctly in most cases.

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

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

Schema description coverage is 0%, and the description does not explain the parameters 'target' and 'name.' While their names are somewhat self-explanatory, the description adds no explicit semantics or usage details. It relies entirely on the parameter names, which is insufficient given 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 action: 'Rename a node in the open scene.' It identifies the verb (rename), resource (node), and scope (open scene), distinguishing it from sibling tools like move_node or delete_node. The 'undoable' qualifier adds specificity without 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 context 'in the open scene' implies when to use the tool, but no explicit alternatives or exclusions are given. It does not mention when not to use it or compare to similar operations like reparent_node or duplicate_node. This is adequate but not comprehensive.

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

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

Annotations already declare the tool read-only and non-destructive. The description adds useful behavioral detail by explaining that it returns a 'warnings' list naming the broken stage or a verdict that geometry reaches the camera. It also points to help(tool=...) for the full stage list, which is helpful context beyond the annotations.

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

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

The description is compact and front-loaded with the tool's purpose, followed by output behavior and a clear usage directive. The illustrative scenario sentence adds color but does not waste much space, and the help pointer is efficient.

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 adequately covers the high-level purpose, return value, and when to use the tool, and the annotations cover safety. However, the five optional parameters are left mostly undefined and there is no output schema, so an agent may struggle to construct a correct call beyond a simple path-based probe.

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 only 20%, with just 'path' documented. The description does not explain 'nth', 'name', 'class', or 'under', and it does little to clarify how these optional parameters identify the node being probed. Since the schema is sparse, the description should compensate but does not.

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 a diagnostic tool for determining why a 3D node is or is not visible, and distinguishes it from pixel-based tools by saying 'as data instead of pixels'. It also names the exact scenario it addresses, making it easy to differentiate from screenshot or UI inspection 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 strong situational guidance: 'USE THIS BEFORE tuning lighting, fog, exposure or palette on anything you cannot clearly see.' It does not explicitly name alternatives or exclusions, but the 'instead of pixels' phrasing and the strong directive make the intended usage clear.

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

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

The description adds valuable context beyond annotations by noting the operation is undoable, which is a safety-relevant behavior not captured by the annotations. It also scopes the action to the open scene, providing operational context. No contradiction exists with the annotations.

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

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

The description is a single, compact sentence that immediately front-loads the core action and context. Every word contributes value with no redundancy or filler.

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

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

While the simple mutation and the 'undoable' note provide some context, the description omits how to identify nodes, what happens if the new parent is invalid, and alternative conditions that could affect invocation. For a tool with no output schema and sparse annotations, this leaves noticeable gaps.

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

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

The description implies that 'target' is the node being moved and 'new_parent' is the destination, adding some meaning beyond the bare string types in the schema. However, it does not specify how to reference nodes (e.g., NodePath, name, or ID), and with 0% schema coverage, this lack of operational detail leaves room for incorrect usage.

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 verb 'Move', the resource 'node', and the specific operation 'under a new parent' in the open scene, effectively distinguishing it from siblings like move_node which likely handles transforms. It 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 provides no guidance on when to use this tool vs alternatives like move_node, rename_node, or delete_node. It does not mention any preconditions, exclusions, or explicit contexts where reparent_node is preferred, leaving the agent to infer usage from the name alone.

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

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

Annotations already signal readOnly and non-destructive. The description adds useful behavioral context: selectors resolve fresh every call, so no re-fetch is needed, and the tool returns both the value and the matched/resolved path. This goes beyond the annotation safety profile without contradicting it.

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

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

Three tight, front-loaded sentences cover purpose, addressing, and live-resolution behavior. Every sentence contributes information; there is no padding or repetition.

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

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

For a read-only runtime property accessor, the description gives enough for an agent to make a correct basic call: choose path or selector, provide a property, and expect value+resolved path. The missing 'under' parameter and lack of exact value formatting keep it from being fully complete.

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

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

With 0% schema description coverage, the description must carry the parameter-load. It explains path, class, name, text, and nth, but it omits 'under' entirely and does not clarify what kind of value 'property' expects beyond the tool's name. This is a clear gap for a tool with seven 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 concrete verb and resource: 'Read a property of a node in the RUNNING game.' It precisely defines the addressing modes (path or live selector) and emphasizes that it targets the running game, distinguishing it from tree/snapshot-oriented siblings like get_scene_tree and get_remote_tree.

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

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

It clearly states when to use this tool: when you need a property's current value from the live game, and it gives practical guidance to prefer fresh selectors over stale @Node@NN paths. It does not explicitly name alternatives or say when not to use it, but the usage context is clear.

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

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

Annotations already indicate readOnlyHint=false and destructiveHint=false, so the agent knows this is a mutating but non-destructive operation. The description adds the save-as context but doesn't disclose further behaviors like overwrite behavior or error conditions, which is acceptable given the simple nature of the tool.

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

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

Two short sentences deliver both the primary function and the parameter usage with zero redundancy. The description is perfectly sized for the tool's simplicity.

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

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

For a tool with one optional parameter and no output schema, the description explains what the tool does and how to use the parameter. It doesn't describe return values or edge cases, but these are not essential for such a simple operation, making the description complete enough.

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

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

Schema coverage is 0%, so the description must compensate, and it does by explaining that 'path' is the res:// destination for save-as. This gives the parameter meaningful context beyond just a type, though it doesn't explicitly state that the parameter is optional.

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

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

The description uses the specific verb 'Save' with the resource 'the scene currently open in the editor', clearly distinguishing it from sibling tools like open_scene, play_scene, and instance_scene. It also explicitly mentions the save-as behavior, which differentiates it from a plain save.

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 clearly states when to use the optional 'path' parameter for save-as, implying that omitting it performs a regular save to the current scene path. It doesn't explicitly name alternatives or exclusions, but the context is clear and sufficient for basic usage.

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

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

Discloses several non-obvious behaviors beyond the readOnlyHint annotation: the bare-call max_dim cap of 1280, PNG-only restriction for editor captures, annotate behavior with numbered Set-of-Mark boxes and legend return, and the pointer to help for token/delivery controls. This is rich, useful behavioral context.

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

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

The description is compact and front-loaded, with each sentence earning its place. The closing 'Token dials + delivery: help(tool="screenshot")' is terse and slightly cryptic, which keeps it just short of a perfect structure score.

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 10-parameter image-capture tool with no output schema, the description covers the core output (image and optional legend), target variants, the dimension cap default, the PNG-only constraint, and a cheaper alternative. It delegates delivery details to help rather than spelling them out, which is a minor completeness gap.

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

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

Schema description coverage is 100%, so the baseline is 3; the description adds value by explaining parameter interplay: a bare call applies max_dim=1280, and passing scale, region, max_dim=0, format, or save_to opts out of that default. It doesn't fully document every parameter, but it does meaningful semantic work above the schema.

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

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

States a specific action and resource: 'Capture an image the agent can see.' It immediately distinguishes game capture from editor viewport capture, names defaults, and explicitly calls out ui_snapshot as the cheaper functional alternative. This leaves little ambiguity about what the 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?

Provides concrete selection guidance: use target=game for the running game and target=editor for the 2D editor viewport. It also tells the agent when not to use it ('For pure functional state ui_snapshot is cheaper'), which is exactly the kind of alternative routing a tool description should offer.

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

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

Annotations mark this as destructive, and the description correctly aligns by describing an edit operation. It goes beyond annotations by disclosing atomicity ('Atomic + safe') and the guarantee that 'nothing is written if any anchor is missing/ambiguous or (for .gd) the result fails to compile', which is valuable for an agent assessing 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 three sentences: purpose, data format, and safety/usage guidance. Each sentence is information-dense 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?

For a tool with complex nested edit items, the description covers the input format, constraints, failure behavior, and guidance for alternative tools. It does not explain return values, but no output schema exists and the behavior (success/failure) is implied by the atomic guarantee.

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 brief descriptions for path, edits, and validate, but the description adds crucial detail: the exact structure of edit items ({find, replace[, all]}, {append}, {prepend}), the 'find must match EXACTLY once unless all:true' constraint, and the compile-check behavior of validate (default true, .gd only). This substantially enriches the schema information.

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

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

The description opens with 'Surgically edit an existing res:// file without rewriting it whole', which specifies a clear verb (edit), resource (res:// file), and scope (existing file, targeted edits). It explicitly contrasts with write_script, distinguishing itself from a sibling tool.

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

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

The description includes 'Prefer this over write_script for small changes', directly telling the agent when to choose this tool over an alternative. It also implies that large rewrites should use write_script, and the atomicity warning gives context for safe usage.

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

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

Annotations already declare read-only and non-destructive. The description adds useful behavior beyond annotations: search scoped to res://, regex support via regex=true, and output format as file:line matches. This provides meaningful context about how the tool behaves.

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

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

Two short sentences, front-loaded with the verb and resource, no redundant wording. Every word 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?

No output schema, so the description must explain return values. It mentions 'file:line matches' but lacks specifics on exact data structure, max parameter behavior, and edge cases like no matches. Adequate for a simple search tool, but with gaps.

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

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

Schema description coverage is only 25% (only ext described). The description clarifies query as a substring or regex pattern and explains regex=true toggles regex mode, but max is left unexplained and ext is not elaborated beyond the schema. Partial compensation for low schema coverage.

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

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

Description clearly states it searches file contents under res:// for a substring or regex, and returns file:line matches. This is a specific verb+resource+scope and distinguishes from siblings like read_file (reads entire files) and find_nodes (searches scene tree).

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

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

No explicit when/when-not guidance for selecting this tool over alternatives like find_classes or find_methods. The purpose is clear, so usage is implied, but no exclusions or alternative recommendations are provided.

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?

Although annotations are neutral, the description adds rich behavioral context by explaining what each debug mode visually reveals (e.g., 'unshaded = albedo only', 'wireframe = is the geometry even there'). It also shows the workflow of switching then screenshotting, making the tool's behavior transparent.

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

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

The description is long but every sentence serves a purpose: it front-loads the core action, defines each mode with practical implications, and ends with a clear recommendation. No redundant or filler content.

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

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

For a single-parameter tool with no output schema, the description is fully complete. It covers what the tool does, how to use it, what each mode means, and how it relates to the sibling tool render_probe. The user has everything needed 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?

Even though schema coverage is 100%, the description goes beyond listing enum values by explaining the diagnostic meaning of each mode (e.g., 'overdraw = transparency cost', 'normal_buffer = flipped or NaN normals'). This adds substantial value for correct parameter selection.

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

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

The description clearly states the action: 'Switch the RUNNING game's viewport debug draw mode'. It specifies the resource (viewport debug draw) and distinguishes itself from sibling tools by noting that render_probe answers the same question in numbers.

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: 'Reach for this FIRST when the picture is wrong'. It also describes the diagnostic role of each mode and names the alternative (render_probe), offering clear context for choosing this tool over 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?

Annotations already indicate destructive behavior (destructiveHint=true). The description adds that the change persists to project.godot, which is key context beyond the annotations. It also clarifies parameter aliases (setting/name). No contradiction.

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

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

The description is two sentences: the first states the action and persistence, the second explains parameter usage with an example. No fluff, front-loaded, and every sentence contributes.

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

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

The tool is simple, and the description covers its purpose and main parameter. However, the input schema lists only 'value' as required, yet the description implies a path must be provided without explicitly stating that 'setting' or 'name' is necessary. This could lead the agent to invoke the tool without the required path. There is no output schema, so return behavior is not described.

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 no descriptions (0% coverage). The description compensates by explaining that the property path goes in 'setting' and that 'name' is accepted, with an example mapping path to value. It does not explicitly describe the 'value' parameter, but the example implies its role. This is meaningful guidance.

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

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

The description clearly states the tool's function: 'Set a ProjectSettings value and persist project.godot.' It also provides a concrete example with a property path. This distinguishes it from siblings like get_project_setting (read) and set_property (generic setter).

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 setting persistent project settings, but it does not explicitly contrast with alternative tools such as set_property or get_project_setting. There is no 'when not to use' guidance. The example helps, but selection criteria are not stated.

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

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

Annotations declare readOnlyHint=false and destructiveHint=true, so the agent already knows this is a mutating operation. The description adds valuable context by noting the operation is 'undoable' and detailing value coercion for vectors. This goes beyond the annotations and helps anticipate behavior.

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

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

The description is two sentences with no filler. The first sentence states the purpose immediately, and the second provides essential coercion detail. Every word earns its place, making it highly concise and well-structured.

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

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

For a simple setter with three required parameters and no output schema, the description covers the core aspects: what it does, undoability, and value coercion. It lacks explicit return-value information, but with no output schema that is acceptable. It is sufficient for an agent to select and invoke the tool correctly, though 'resolved object' could be more explicitly defined.

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 describes 'value' as any JSON value, leaving target and property undocumented. The description partially compensates by explaining that the target is a resolved object and providing coercion rules for values. However, it does not clarify the expected format of the property parameter, leaving some ambiguity.

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 verb 'Set' and the resource 'property on a resolved object', which identifies a specific operation. It distinguishes from sibling tools like set_project_setting or set_resource by focusing on object properties. The phrase 'resolved object' is specific enough for the Godot context.

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

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

The context is clear: use this tool when you need to set a property on a resolved object. It doesn't explicitly name alternatives or exclusions, but the mention of 'resolved object' and value coercion implies the intended use case. This is strong implied guidance, though not as explicit as naming 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?

Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description adds the behavioral note that the operation is 'undoable' and clarifies that it can either load an existing resource or mint a new inline sub-resource. This provides useful context beyond the structured 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 front-loaded with the main purpose, followed by parameter guidance and examples in just two sentences. Every sentence earns its place, with no wasted words.

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

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

Given no output schema, the description covers key aspects: the two distinct modes, examples, and the undoability. It is complete enough for an agent to select and invoke the tool correctly, though it could be slightly more explicit about mutual exclusivity or required parameter formats.

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 description compensates for the 50% schema coverage by explaining the relationship between 'resource' and 'class' (OR) and providing concrete examples. It implicitly clarifies that 'target' is a node and 'property' is a property name, though not explicitly, which adds value beyond the schema.

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

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

The description clearly states 'Assign a resource to a node's property' with specific verb and resource, and differentiates from siblings like set_property and create_resource by focusing on resource assignment. The examples further clarify the intended use.

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

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

The description provides context via examples (e.g., setting Sprite2D.texture or RectangleShape2D) and explains the two parameter modes, but it does not explicitly state when to use this tool over alternatives or list exclusions. Usage is implied rather than explicitly contrasted with sibling tools.

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

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

Annotations indicate the tool is not read-only and not destructive, and the description clearly states it stops the play session, aligning with that. However, little additional context is provided about side effects, permissions, or error conditions, leaving the description to carry minimal behavioral detail.

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

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

The description is a single, short sentence that gets straight to the point. No unnecessary words or redundant information.

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

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

For a simple action tool with no parameters and no output schema, the description fully captures the tool's purpose. Combined with the sibling list, the usage context is clear and no other details seem necessary.

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

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

The tool has zero parameters and the schema has no properties, so there is nothing to explain. The baseline for zero parameters is 4, and the description correctly avoids inventing 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 uses a specific verb ('Stop') and resource ('the running play session'), clearly distinguishing it from siblings like play_scene and get_play_state. It unambiguously states the tool's function.

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

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

The description implies the tool is used to end a play session, but it does not explicitly mention when to use it relative to alternatives or provide any exclusions. There's no guidance on scenarios like when no play session is running.

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

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

Annotations already show readOnlyHint=true and destructiveHint=false; the description adds useful behavioral context: it operates on the 'RUNNING game', returns semantic state that pixels cannot convey, and includes 'per-control honesty flags'. This goes beyond the annotation bare minimum without contradicting them.

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

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

Dense, information-rich and mostly front-loaded with purpose and usage guidance. The trailing sentence 'Every field, and the free since_hash re-read: help(tool="ui_snapshot")' is awkwardly phrased and slightly cryptic, but the overall length is justified by the amount of useful routing information.

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

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

Despite having no output schema, the description enumerates the core return contents and semantic fields, and the schema covers all 5 parameters. It could be more complete by describing the shape of a returned snapshot or what 'honesty flags' mean, but an agent can confidently select and call this tool for functional UI checks as written.

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?

Input schema has 100% description coverage, and every param is individually documented (path, max_nodes, occlusion, since_hash, interactive_only). The description adds only a small extra note about 'free since_hash re-read', so it does not meaningfully extend what the schema already communicates.

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

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

The description clearly identifies the tool's purpose: a 'one-call UI snapshot of the RUNNING game' returning visible Controls as structured data, with an explicit list of fields (path, class, text, rect, semantic state, honesty flags). It also distinguishes it from screenshot and names the composite workflow it replaces, so an agent can differentiate it 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?

Provides explicit usage guidance: 'For FUNCTIONAL UI checks this replaces screenshot + find_ui_elements + get_control_rect + runtime_get_property; keep screenshot for visual/render bugs.' This directly answers when to use this tool versus alternatives and even gives an exclusion case.

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

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

Annotations already mark the tool as read-only, but the description adds meaningful behavior: it validates without writing, returns compile status, handles already-registered class_name correctly, and explains the v1.9 fix for the old false positive. This gives an agent important expectations about edge cases and version-specific 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 information-dense with no filler. The core fact that this tool does not write is front-loaded, followed by parameter usage and then a necessary edge-case caveat. Every clause earns its place without being verbose.

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-parameter tool with read-only annotations, the description covers what the tool returns, when to use it, how to use both parameters independently and together, and a notable behavioral quirk. Nothing needed to invoke it correctly appears to be 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 only 50% because content has no description, but the description compensates fully. It explains that content is the source to validate, path is the res:// file to validate or the destination when content is supplied, and that passing both catches cross-file class_name duplicates. This adds meaning the schema lacks.

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

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

The description states a specific verb and resource: parse/compile GDScript without writing it. It clearly distinguishes itself from write_script by emphasizing that this is a pre-write validation step, and 'Returns whether it compiles' makes the core purpose unmistakable.

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

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

The description explicitly says to use this tool before write_script to catch hallucinated APIs, giving a concrete usage condition. It also explains the special case where content is destined for an existing file and path must be passed, which is actionable guidance beyond the schema.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds that it works on the 'RUNNING game' and has a timeout, but it does not explain timeout behavior (e.g., error vs. return) or how path resolution works. The added context is modest but not unseen in annotations.

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

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

The description is two concise sentences with no redundancy. The primary purpose is front-loaded, and the usage hint is separated clearly. Every word contributes to understanding.

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 blocking read-only tool with annotations covering safety, the description covers core purpose and usage. It lacks details on timeout behavior and return value, but these are not critical for a synchronization primitive. It is adequately complete for guiding selection and basic invocation.

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

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

Schema description coverage is 0%, so the description must compensate. It mentions 'path/name' for the path parameter and 'timeout' for timeout_ms, but does not explain the format of path (e.g., absolute scene path vs. name) or the unit/default for timeout_ms. This is insufficient for an agent to construct correct 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 clearly states the tool blocks until a node appears in the running game or times out. This specific verb ('Block') plus resource ('node') and outcome ('appears... or timeout') distinguishes it from siblings like wait_until, which is likely a generic wait.

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

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

The description explicitly says 'Use after play_scene to sync before driving', providing clear context for when to use it. It does not explicitly list alternatives or exclusions, but the stated use case is unambiguous enough for an 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?

The description discloses the blocking limit (1.5s), why that limit exists (main-thread frames), and the retry behavior. Annotations already mark it read-only, and the description adds meaningful context without contradicting them. Missing: it doesn't clarify how timeout_ms relates to the stated 1.5s cap.

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

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

Every sentence adds value: purpose, blocking constraint and rationale, retry behavior, then a compact condition list. It is dense but perfectly sized for the tool's 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 covers the core contract well (wait, poll, block limit). It does not describe the success return value or the `timeout_ms` parameter, and it offers no cross-reference to sibling wait_for_node, which would help complete the picture for an agent.

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

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

With 0% schema coverage, the description must explain parameters. It defines the required `condition` parameter clearly and includes a compact syntax. However, the optional `timeout_ms` parameter is never mentioned, leaving its meaning and relationship to the 1.5s limit undocumented.

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

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

The description states a clear action ('Wait for a condition') and enumerates the accepted condition values (play_started, play_stopped, game_connected, seconds:N, file_exist:res://path). It does not explicitly distinguish from the sister tool wait_for_node, but the condition list makes the scope reasonably concrete.

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 practical guidance: blocks at most ~1.5s, if not met retrn 'not yet' and call again. It does not mention alternatives like wait_for_node or state when not to use this tool, but the context for repeated polling is clear.

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

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

Annotations already indicate destructiveHint=true, but the description adds valuable behavioral context: it refreshes the editor filesystem, open scenes remain stale until manually reloaded unless auto_reload_scenes is set, and scripts auto-reload. These are meaningful side effects that go beyond the annotation and help the agent anticipate consequences.

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 information-dense with no filler. It opens with the core behavior, then covers side effects and reload caveats, and ends with routing guidance. Every sentence contributes to correct invocation or expectation setting.

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-parameter tool with no output schema, the description covers most essentials: allowed paths, traversal protection, editor refresh, open-scene reload behavior, and alternatives. It does not mention overwrite behavior or whether parent directories are created, and it does not describe the return value, but these are minor gaps given the clear scope.

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?

With 0% schema description coverage, the description must compensate, and it partially does: it clarifies that path must be under res:// or user:// and that traversal is guarded. Content is only described as text, which is fairly evident from the tool name and writing a text file, but no encoding or length constraints are provided. Overall, the path semantics are meaningfully enriched.

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

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

The description states a specific verb and resource: writing a text file under res:// or user:// with path-traversal guarding. It also distinguishes itself from sibling scene tools by explicitly recommending create_node / set_property / save_scene instead of writing .tscn text. This is unambiguous and helps an agent select the right 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 gives clear when-to-use guidance, including the caveat about open .tscn files requiring human reload and the preference for scene tools over raw .tscn writes. It also notes that scripts reload automatically, so writing scripts is safe. This explicitly routes the agent away from write_file in certain cases and toward 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?

The description goes beyond the destructiveHint by explaining the validation-before-write behavior, refusal of non-compiling GDscript, and the as-is handling of non-.gd files. No contradiction with annotations.

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

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

Two dense sentences with no wasted words. The validation caveat is front-loaded, and the sibling routing is placed in the same breath.

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 write tool with no output schema, the description plus schema sufficiently covers the invocation: path, content, validation behavior, and the build_csharp alternative. It doesn't state overwrite semantics, but the destructiveHint already signals that risk.

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

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

Schema covers path and validate, but not content. The description adds meaning by clarifying that content is GDscript or arbitrary text, and that validate controls compilation checking. This compensates for the 67% schema coverage.

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

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

The description states a specific verb ('Write'), a resource ('GDscript or other text file under res://'), and the destination. It distinguishes itself from compile-checking via build_csharp, though it doesn't explicitly contrast against write_file.

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

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

It provides clear usage context: GDscript is validated by default, non-.gd files are written as-is, C# should be handled with build_csharp, and validate=false forces the write. This is actionable guidance, though it doesn't enumerate all sibling alternatives like write_file.

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