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

No annotations are provided, so the description carries the burden. It communicates that results reflect the exact installed engine version and that queries are read-only ('Look up'). It does not disclose pagination/truncation behavior, but the verb and scope make side-effect-free lookup clear.

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

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

Two sentences, front-loaded with the core action, and supported by a crisp list of return contents. The second sentence is a direct, no-waste usage tip.

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 6 parameters and no output schema, the description covers the core lookup semantics and result contents, while schema fills in param constraints. It doesn't mention response formatting or pagination, but the default limit and offset are in the schema, so the information is recoverable.

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 already covers query, kind, project, and inherited well; the description adds meaning by tying returned categories to the kind selector but leaves limit/offset unexplained. With 4 of 6 params having schema descriptions, the description is adequate but not highly additive beyond 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 verb 'Look up' plus resource 'Godot class in the installed engine' is specific, and the list of contents (methods, properties, signals, enums, inheritance) distinguishes it from generic search or list tools. It also brands itself as an authoritative API reference with exact engine version, which differentiates it from sibling tools.

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

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

The line 'Use this instead of recalling the API' gives a clear trigger condition for reliance on this tool, while 'installed engine' scopes it to version-accurate lookups. It doesn't explicitly contrast sibling tools, but the intended 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?

With no annotations, the description carries the burden of behavioral disclosure. It transparently states that it adds files under addons/godot_assistant and enables the plugin, and explicitly mentions install or remove. However, it doesn't elaborate on reversibility of uninstall or permission requirements.

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

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

The description is two sentences, front-loaded with the main purpose, and every sentence adds value—purpose, optionality, scope, and side effects. No wasted words.

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

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

For a simple tool with no output schema and optional parameters, the description covers the main behavior and side effects adequately. It doesn't explain the status action's return format or prerequisites (e.g., project detection from --project), but the schema covers some of that.

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 project with a description, but the action parameter (install/status/uninstall) has no schema description and the tool description doesn't explain it. Since schema coverage is only 50% and the description adds no parameter-level meaning, the action semantics (especially what 'status' does) remain unclear.

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 installs or removes the optional Godot addon that enables live features, listing specific capabilities (inspecting, simulating input, screenshotting, driving play/stop). This specific verb+resource combination distinguishes it from sibling tools like run_project or editor_control.

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 'Everything else works without it,' providing a clear 'when-not-to-use' signal by indicating the addon is optional and only needed for live features. It doesn't name an alternative tool, but no direct alternative exists among siblings.

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

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

With no annotations provided, the description carries the full burden. It discloses the bridge_install requirement and the fact that it can launch the editor, which is useful, but it does not detail side effects (e.g., save overwriting files, play/stop affecting the running project) or error behavior. It provides some behavioral context but not comprehensive disclosure.

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

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

The description is two sentences, front-loaded with the core function, then a compact list of actions and a prerequisite. Every phrase earns its place, with no redundancy.

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

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

Given the tool has multiple actions, no output schema, and no annotations, the description provides a solid overview of the action space, but it omits a couple of enum values (reload_scene, state specifics) and return/error expectations. Still, for a control tool with a self-explanatory enum, it is reasonably complete.

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

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

All parameters already have descriptions in the schema (100% coverage), so the baseline is 3. The description's list of actions loosely maps to the action enum but does not add new meaning beyond what the schema provides.

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

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

The description opens with a specific verb-resource pair ('Drive a running Godot editor') and enumerates concrete capabilities (open scene, save, play/stop, select nodes, rescan), which clearly distinguishes it from sibling tools like run_project or scene_tree. The additional note about launching the editor further clarifies its scope.

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

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

The description implies usage for controlling a Godot editor and notes the bridge_install prerequisite, but it does not explicitly contrast with alternative tools or state when not to use it. It offers context but no exclusions or direct sibling comparisons.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It mentions presets must exist but does not explain that building writes output files, may overwrite existing files, or what the list action returns. The mutation behavior is under-disclosed.

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

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

The description is two concise sentences, front-loaded with the core purpose. It has no wasted words and reads clearly.

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 5-parameter tool with no annotations or output schema, the description is adequate but has gaps: it does not disclose side effects, output expectations, or when the project parameter is needed. The schema covers parameter semantics well but does not compensate for missing behavioral context.

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

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

The input schema describes all parameters, so the baseline is 3. The description adds meaning to the action enum by clarifying 'build one' as an export/build operation and gives a prerequisite for presets, providing some 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 the tool lists export presets or builds one, identifying the resource and actions. It does not explicitly differentiate from sibling tools like run_project, and 'build one' is slightly ambiguous, but the overall purpose is understandable.

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

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

The description implies use when working with Godot export presets and provides a prerequisite (presets must be created in the editor). However, it does not give explicit guidance on when to use this tool versus alternatives or state any 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?

With no annotations, the description carries the full burden. It discloses meaningful behavioral traits: errors/warnings are parsed, deduplicated, shown with file:line, and repeated per-frame errors are collapsed. This goes beyond the schema. However, it does not mention non-destructive reading (clear defaults to false) or return format, which keeps it from a 5.

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

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

The description is two sentences, front-loaded with the main action ('Read console output'), and every phrase adds value. No fluff or redundant phrasing.

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

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

For a tool with 5 parameters, no output schema, and no annotations, the description gives a good high-level overview but leaves gaps: it doesn't explain return structure, pagination (limit/offset), or the buffer-clearing effect of 'clear'. The parsing/dedup details help, but an agent would still need to rely on the schema for several misunderstandings.

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 60% (clear, project, severity have descriptions; limit and offset do not). The description adds context about errors/warnings parsing that relates to the severity parameter, but does not compensate for the undocumented limit/offset parameters. It is adequate but not exemplary.

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

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

The description uses a specific verb ('Read'), clearly identifies the resource ('console output'), and scopes it to the 'running (or last) session'. It also distinguishes itself from sibling tools like run_project and stop_project by describing output processing (parsed, deduplicated, file:line). No ambiguity about what this 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 phrase 'from the running (or last) session' implies usage after launching a project, but there is no explicit when-to-use or when-not-to-use guidance. Sibling tools like run_project hint at the workflow, but no alternatives are named or excluded. Usage is implied rather than explicitly stated.

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

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

With no annotations, the description carries full behavioral disclosure burden. It transparently lists the specific checks performed (version, project detection, bridge state, processes) and the context for use. It stops short of explicitly stating the tool is read-only or non-destructive, though 'health check' strongly implies this.

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 outlines the checks performed; the second provides usage guidance. Every word contributes value.

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

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

For a simple status tool with one optional parameter, the description is complete. It tells the agent what will be checked and when to use it, while the schema handles parameter specifics. No output schema is needed because the description lists the reported check categories.

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

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

The only parameter 'project' is fully documented in the schema with a description and optionality note, so schema coverage is 100%. The tool description adds no additional parameter semantics beyond the schema, so a middle score is appropriate.

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

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

The description clearly states the tool performs an environment and project health check, enumerating specific aspects (Godot version, project detection, bridge state, running processes). This distinguishes it from sibling tools like run_project or editor_control by positioning it as a diagnostic/status 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 instructs the agent to 'Start here when anything is unexpected, or to confirm setup,' providing clear guidance on when to invoke this tool first. It implies this is a preliminary check before using more specific tools, which is effective usage guidance.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'find and fix' and the cause of unimported assets, but it does not explain what reimport actually does, whether it modifies project files, or any side effects. The 'fix' action is vague about consequences, leaving significant behavioral ambiguity.

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

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

The description is two sentences: the first is an action-oriented summary, and the second adds essential context and a call-to-action. Every sentence earns its place, with no fluff or repetition.

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

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

There is no output schema and no annotations, so the description must explain return values and behavior. It does neither for pagination (limit/offset), reimport effects, or what 'check' vs 'reimport' return. While it covers the primary use case, the missing operational details make it incomplete 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 only 50% (only 'action' and 'project' have descriptions). The tool description does not compensate by explaining 'limit', 'offset', or important parameter interactions. The description adds no parameter-level meaning beyond what the schema already states, which is insufficient for the low coverage.

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

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

The description uses a specific verb+resource ('Find and fix assets') and clearly states the tool's scope (assets Godot has not imported yet). It distinguishes this from sibling tools by mentioning the exact error symptom and the action of importing, making its 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 gives a clear trigger: 'Call this after adding files outside the editor.' It also provides diagnostic context ('No loader found for resource') that helps the agent know when this tool is relevant. However, it does not explicitly state when not to use it or name alternatives, so it falls short of a 5.

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

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

With no annotations provided, the description carries the full burden. It only states the basic action and filter options, but does not disclose output format, pagination behavior, recursion, case sensitivity, or permission implications. The schema hints at limit/offset but the description adds no behavioral context beyond the obvious read-only nature.

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

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

The description is two sentences, front-loaded with the core functionality, and every word earns its place. No fluff or repetition.

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

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

The tool has six parameters and a clear schema, but no output schema. The description does not explain return values or edge cases like the 'project' parameter inference. For a simple list tool it is adequate, but it would benefit from mentioning output format or how glob matching works. It is neither incomplete nor exceptionally complete.

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

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

Schema description coverage is 100%, so the baseline is 3. The description mentions 'kind' with the enum values and 'optional glob' (pattern), but this mostly duplicates the schema. It adds minimal additional meaning beyond what the schema already provides.

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

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

The description clearly states the tool lists project files and enumerates specific kinds (scenes, scripts, resources, images, audio, models), which is a specific verb+resource combination. However, it does not explicitly differentiate from sibling tools like 'search' or 'scene_tree', so it misses the full discriminator credit.

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?

'Use to orient in an unfamiliar project' provides a clear use case, but there is no explicit when-not-to-use or named alternative. This is clear context without exclusions, so it fits the 4-level.

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

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

With no annotations, the description carries the transparency burden. It discloses that the scene file is rewritten, which is a useful side-effect warning. However, it does not mention the potential loss of script references when force is true, nor does it state that changes are permanent. This is a notable gap for a write operation.

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

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

The description is only two sentences, with the primary purpose front-loaded. Every clause adds value: batching guidance and the rewrite side-effect. No fluff.

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

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

The tool is relatively simple, and the schema covers parameter semantics thoroughly. The description covers the key behavioral aspects (single save, rewrite). However, it does not mention what the tool returns (no output schema), nor does it call out the force/script-reference risk in the main description, though the schema does. This is adequate for the complexity.

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

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

The schema provides 100% coverage for all four parameters, with detailed descriptions for each (e.g., force, nodes order, parent default). The description adds little beyond batching guidance, so the baseline of 3 is appropriate.

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

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

The description clearly states the tool adds one or more nodes to a scene in a single save. The verb 'Add' and resource 'nodes to a scene' are specific, and the 'single save' detail distinguishes it from modifying or inspecting 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 advises batching related nodes and warns that each call reloads and rewrites the scene file, implying that batching reduces overhead. However, it does not explicitly mention alternatives like node_modify for modifying nodes or scene_create for creating scenes, so it stops short of a 5.

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

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

With no annotations provided, the description carries the burden for behavior disclosure. It describes the return content and the selective inclusion of non-default properties, which is useful. However, it does not explicitly state that the tool is read-only or that it requires a loaded project, leaving some behavioral ambiguity.

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

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

The description is a single, well-structured sentence that is front-loaded with the core purpose and followed by concrete details. No filler or redundancy.

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

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

Given the tool's simplicity and the schema's coverage, the description provides a good summary of return contents. It lacks an explicit mention of the include_defaults toggle and how to discover node paths, but these are partially covered by the schema and sibling tools.

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

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

The schema already documents 75% of parameters; the description adds no explicit parameter semantics. It indirectly references the include_defaults behavior via 'properties that differ from their defaults' but does not elaborate on parameter usage or syntax.

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: 'Full detail for one node' and enumerates the specific attributes (type, inheritance chain, script, groups, signal connections, properties). This specific verb+resource distinguishes it from sibling tools like scene_tree or runtime_inspect, though it does not explicitly name them.

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

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

The description implies when to use the tool (when needing comprehensive information about a single node) but provides no explicit guidance on when not to use it or alternatives. It does not mention other tools like scene_tree for tree traversal or runtime_inspect for runtime state.

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

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

With no annotations, the description must disclose behavioral traits. It adds the useful note 'All operations are applied then saved once,' indicating atomic batch save. However, it does not discuss error handling, partial application behavior, or the destructive implications of delete/reparent beyond listing those actions.

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

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

The description is two sentences, front-loaded with the core purpose, and includes a concise behavioral note. Every word adds value, with no redundancy or fluff.

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

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

The tool is complex (4 parameters, 9 operation types), but the description does not mention return values, error behavior, or whether changes persist to disk beyond 'saved once.' The schema covers parameters, but the overall context feels incomplete for an agent to confidently invoke this tool.

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

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

The input schema already provides descriptions for most parameters (action, node, to, name, group, index, script, properties). The description recounts the operation list but does not add new semantic details beyond the schema. It neither compensates for uncovered parameters nor enriches the existing field 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 clearly states 'Apply a batch of edits to a scene' and enumerates specific operations (set properties, rename, delete, reparent, reorder, attach/detach scripts, manage groups). This distinguishes it from sibling tools like node_add (single add) and node_inspect (read-only).

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 batch modification use case but does not explicitly address when to use it versus alternatives such as node_add for single additions or node_inspect for inspection. There is no mention of exclusions or prerequisites, leaving the selection logic to the agent.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. 'Read this' implies a non-mutating operation, and the description clarifies the informational scope, but it does not explicitly state read-only behavior, return format, or any side effects.

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

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

Two sentences, front-loaded with the tool's purpose and ending with a practical directive. Every word earns its place, no redundancy.

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

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

The tool has only two optional parameters and no output schema, so the description should explain what is returned. It lists content categories but doesn't describe the response shape or format, leaving a moderate completeness gap for an agent consuming the result.

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

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

The schema covers 100% of parameters (include and project) with descriptions, so the baseline is 3. The description adds context by enumerating important sections but doesn't add new parameter-level detail beyond the schema.

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

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

The description clearly identifies the tool as providing project settings relevant to coding (main scene, autoloads, input actions, physics layers, file counts). It uses the imperative 'Read this' to signal retrieval, but does not explicitly name a sibling alternative or use a verb like 'get/list', so it doesn't fully distinguish from 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?

Provides explicit guidance to read before generating gameplay code, establishing a clear use case. It lacks exclusionary language or alternative tool mentions, but the context is sufficient for when to use it.

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

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

No annotations are provided, so the description must disclose behavior. It only states the general create/read/edit operations without explaining side effects, overwrite behavior, read return format, or required project context. The overwrite parameter exists in schema but is undocumented in the description.

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

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

Two sentences, front-loaded with the core purpose, includes a helpful workflow tip. No redundant wording.

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 six parameters, no annotations, and no output schema, the description is too brief. It fails to explain return behavior for read, the role of overwrite, or how properties are applied, leaving an agent without enough guidance 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 67%, leaving action and overwrite undocumented. The description adds no parameter-specific meaning; it lists resource types but does not explain action semantics, overwrite default, or properties mapping. The schema's enum and default provide limited context, but the description does not compensate for the 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 uses a specific verb phrase 'Create, read or edit' with a clear resource type 'Godot resource files (.tres)' and lists example resource categories (materials, themes, curves, tilesets, physics shapes, input/animation data), distinguishing it from sibling scene/node/script tools. The 'Use api_reference first' hint further clarifies its role in the workflow.

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 implies when to use: for .tres resource files, and advises using api_reference first. However, it does not explicitly exclude alternatives or state when not to use it, e.g., vs node_modify for scene nodes.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It transparently explains that it captures output, can run foreground or background, and mentions the polling pattern. It does not explicitly mention restart behavior, but that is covered in the schema for the replace parameter.

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, front-loaded with the main purpose and followed by a clear usage distinction. Every sentence adds value with no redundancy.

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

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

For a tool with 7 parameters and no output schema, the description covers the core behavior and references get_output for follow-up. Combined with the detailed schema, it provides sufficient context for the agent, though it could mention return format beyond 'log'.

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 baseline is 3. The description adds value by providing a workflow for wait_seconds (quick check vs. leave running and poll), which goes beyond the parameter's raw schema description.

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

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

The description clearly states the tool launches the game and captures output, with the ability to run the main scene or a specific scene. It distinguishes itself from siblings by explicitly referencing get_output for polling, making the purpose unambiguous.

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

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

The description gives clear guidance on two usage modes: using wait_seconds for a quick log check, or omitting it to keep the game running and poll with get_output. This provides context for when to use this tool and how to interact with a sibling, though it does not explicitly state 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?

With no annotations, the description carries the burden. It states the read-only nature and the prerequisite bridge_install, but doesn't mention failure modes or potential performance impacts. This is adequate for a simple read operation.

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

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

Three concise sentences, front-loaded with the main purpose. Every sentence adds value: what it does, why it matters, and a prerequisite.

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 or annotations, so the description must provide more. It gives a high-level list of output types but lacks return format or error behavior. Adequate for a straightforward read tool but with 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?

Schema coverage is 80%, so the baseline is 3. The description adds context about output contents (world positions, FPS) that relates to the 'what' parameter, but doesn't explain max_depth or return structure 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 a specific verb and resource: 'Read the live state of the running game' and lists concrete contents (node tree, property values, FPS). It distinguishes from sibling tools by emphasizing runtime truth versus the scene 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 context for when to use the tool—whenever runtime state is needed—and contrasts with the scene file. It lacks explicit alternatives or when-not-to-use instructions, but the implied usage is strong.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It discloses the uid:// assignment, which is a useful side-effect, but does not mention overwrite behavior, error conditions, or whether the operation is irreversible. This provides some transparency but is incomplete.

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, front-loaded with the primary action and adding a key behavioral detail. No extraneous information.

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

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

Given the high schema coverage and no output schema, the description does not need to explain return values. It provides the core purpose and a unique side effect, and the schema covers parameter details. It is adequate for a simple creation tool, though it omits overwrite conflict behavior.

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 high (83%), so the schema already documents most parameters. The description reinforces the meaning of root_type and script but adds no new semantic details beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states the tool's function: creating a new .tscn scene file with a configurable root node type and optional script, plus a uid:// assignment. This distinguishes it from siblings like script_create (which creates scripts) and node_add (which modifies existing scenes).

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 conveys the primary use case—creating a new scene from scratch—and implies it's for new files rather than modifying existing scenes. However, it does not explicitly name alternatives or state when not to use it, so it lacks exclusion criteria.

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 crucial behavioral trait that the instance is not a copy and that later edits to the source propagate. This goes beyond the schema and gives the agent an accurate mental model. No annotations are present, so the description carries the burden; it does not mention side effects like file modification or reversibility, but the core non-copying behavior is well conveyed.

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

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

The description is two sentences, front-loaded with the core action, and includes a helpful Godot analogy ('prefabs'). Every word earns its place with no redundancy.

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

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

For a tool with 8 parameters, a nested properties object, and no output schema, the description is brief but the schema fills in most parameter details. However, the 'force' parameter is undocumented, and there is no mention of what the tool returns or how success is indicated. The description gives the essential conceptual model but relies heavily on the schema for complete usage context.

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

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

Schema coverage is high (88%), so most parameters are already described. The description does not add parameter-specific syntax or details; it only references 'scene' and 'instance' implicitly. The 'force' parameter lacks any schema description or explanation in the description, but overall the schema handles the semantics adequately.

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

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

The description clearly states the action: 'Place one scene inside another as an instance (not a copy)'. It also highlights the key distinction from copying and explains the propagation behavior, which differentiates it from scene creation or node addition 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 implies when to use this tool: when you want instancing so that edits to the source propagate. It does not explicitly exclude alternatives or list when not to use it, but the context is clear enough for an agent to infer appropriate 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?

With no annotations, the description carries the full burden of behavioral disclosure. It explicitly states this is a read operation ('Show', 'Read') and discloses the content included in the result (types, scripts, sub-scenes, groups). It also embeds a workflow recommendation, but does not detail potential limitations like depth handling, which is covered by the schema. Overall, it is transparent for a simple read tool.

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

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

The description is a single sentence that front-loads the core purpose and ends with an actionable usage tip. Every word contributes value; 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 tool's simplicity, the absence of annotations, and no output schema, the description provides a complete contract: it states what the tool returns (node hierarchy with types, scripts, sub-scenes, groups) and when to use it (before editing). This is sufficient for an agent to understand the tool's role and capabilities.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not add parameter-specific semantics beyond the schema; parameters like 'scene', 'project', and 'max_depth' are already well-documented. The description's content is orthogonal, focusing on output rather than input 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 shows a scene's node hierarchy with specific details (types, attached scripts, instanced sub-scenes, groups). The verb 'Show' and resource 'scene's node hierarchy' make the purpose explicit and distinct from sibling tools like node_inspect which focus on a single 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 'Read this before editing any scene' provides an explicit when-to-use directive, positioning this as a prerequisite read operation before any scene modifications. It does not name alternative tools, but the context is clear enough for an agent to select it during scene editing workflows.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It usefully states that scene rendering is offscreen and requires no setup, and that game/editor modes need bridge_install. However, it does not disclose potential side effects on a running game, return format, or any other behavioral traits beyond these setup requirements, which is a notable gap.

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

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

The description is well-structured and concise, consisting of four short sentences that each serve a distinct purpose: hook, scene behavior, game/editor behavior, and usage advice. It is front-loaded with the main purpose and immediately communicates the critical source distinction, with no wasted words.

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

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

For a 7-parameter tool with no output schema and no annotations, the description should clarify what the tool returns (e.g., an image path or binary) and any further prerequisites (like the project parameter). It mentions bridge_install but not the project parameter or how the captured image is delivered to the caller. The core functionality is clear, but these omissions reduce completeness.

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

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

The schema covers 71% of parameters with descriptions, leaving width and height undocumented. The description adds meaningful context for the 'source' parameter by explaining what each source does (offscreen vs running game vs editor) and the bridge_install requirement. However, it does not compensate for the missing width/height descriptions or add details for other parameters, so its added value is limited.

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 'See what a scene actually looks like' and clearly outlines three distinct capture sources (scene, game, editor) with their specific behaviors. This not only states the tool's purpose but also distinguishes it from siblings by focusing on visual verification, explicitly contrasting with the console which cannot display visuals.

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 direct usage guidance: 'Use this to verify layout and visuals' and notes that the console cannot show them, implying this is the primary tool for visual checks. It also provides a prerequisite (bridge_install for game/editor modes). However, it doesn't explicitly mention when not to use an alternative, though the console is implied as insufficient.

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

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

No annotations are present, so the description must disclose behavioral traits. It does add context about stub generation and optional scene attachment, but it omits any mention of overwrite behavior or effects on existing files. This leaves a gap in the tool's safety profile, so a 3 is appropriate.

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 the first stating the core purpose and optional behavior, and the second offering a clear usage tip. No filler words; every part 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 8 parameters and no output schema or annotations, the description provides a high-level overview that captures the tool's primary function and key options. The schema covers parameter details, so the description doesn't need to enumerate all of them; however, it could mention prerequisites like the `project` parameter, but that's in the schema. A 4 is fair.

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 88%, so the schema already documents most parameters. The description adds meaning by explaining the `content` parameter's role (real code vs stub) and the combined attach-to-scene behavior, adding value beyond the parameter list. Therefore 4.

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

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

The description uses a specific verb 'Write a new GDScript file' and clearly names the resource type. It also distinguishes itself from sibling tools like script_validate by focusing on creation, and notes the optional scene attachment behavior.

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

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

The description implies usage for creating scripts, with no explicit alternatives or exclusions. Since it's the only script-creation tool among siblings, the context is clear, but there's no direct 'use this when...' or 'instead of...' guidance, so I rate it 4 rather than 5.

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

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

With no annotations provided, the description carries the full burden. It discloses the tool's action (parse-check), scope (one file or whole project), and a key performance characteristic (faster than launching). It implies read-only behavior via 'parse-check', which is sufficient for a simple validation tool.

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

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

Two sentences, front-loaded with the core action and resource. Every word earns its place, with no filler or redundancy.

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

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

The tool is simple (2 optional parameters, no output schema). The description covers the main action, scope, and recommended usage scenario. Combined with the schema, it provides everything an agent needs to invoke the tool correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds minimal semantic meaning beyond the schema, only slightly clarifying the path/project relationship ('one file or the whole project'), which is already covered by the schema's own 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 uses a specific verb 'Parse-check' with a resource 'GDScript' and states the outcome 'report errors with file and line'. It clearly distinguishes itself from sibling tools like script_create (creation) and run_project (execution).

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 recommends running after editing scripts and before running the game, and notes it is faster than launching. This provides strong contextual guidance, though it does not explicitly name alternative tools or when-not-to-use scenarios.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It mentions the return format (file:line) but does not explicitly state read-only nature, pagination behavior, or any auth/permission requirements. The non-destructive nature is implied but not stated.

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

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

The description is three concise sentences, front-loaded with the core action. Every sentence adds relevant information, and there is no repetition of schema 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 search tool, the description adequately covers the purpose, search scope, and output format. It does not explain pagination or case sensitivity defaults, but these are represented in the schema, and the missing output schema is partially offset by 'Returns file:line'.

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 50% (kind, query, project documented), but limit, offset, and case_sensitive are undocumented. The description does not compensate for these missing parameters, adding little beyond naming the file kinds that map to the kind parameter.

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

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

The description clearly states it greps across scripts, scenes, and resources, and lists what it finds (symbol definitions, node types, signal names, TODOs). This distinguishes it from siblings like list_files and 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?

Usage is implied by the verb 'Grep' and the description of what it searches, but there is no explicit guidance on when to use it versus alternatives like list_files. No exclusions or alternative tool mentions 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?

No annotations are provided, so the description carries the burden. It discloses two key behaviors: persistence into the .tscn exactly as the editor writes it, and the requirement that the receiving method must exist. This adds meaningful context beyond the schema, though it does not cover side effects of optional parameters.

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

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

Two concise sentences, front-loaded with the core purpose, and no filler. Every phrase adds value.

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

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

Given the tool has 10 parameters, 3 required, and no output schema or annotations, the description is too brief. It fails to mention the action parameter controlling connect vs disconnect, the project parameter, or the optional flags. The core purpose is clear, but many operational aspects are left unaddressed.

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 50%, so the description must compensate. It adds only a constraint about the method being required to exist, but does not explain parameters like force, deferred, one_shot, action, to, or from. This leaves half the parameters under-documented.

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: 'Connect or disconnect a signal between nodes in a scene.' It uses a specific verb and resource, and mentions persistence, distinguishing it from sibling tools like node_add or 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?

The description provides clear context for the tool's usage (connecting/disconnecting signals) but does not explicitly mention alternatives or when not to use it. It implies a specific use case without 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?

No annotations are provided, so the description carries full behavioral burden. It discloses that input goes through Godot's input system and 'reacts exactly as it would to a real device', plus the bridge_install dependency. This explains the mechanism and side-effects better than a simple 'simulate input' would.

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 short sentences, each with distinct purpose: purpose, behavior, prerequisite. No fluff.

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

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

The tool has 12 parameters and no output schema, but the schema's robust descriptions and constraints compensate. The description provides high-level context (running game, Godot input system) that the schema lacks. It doesn't explain parameter combinations, but the schema's 'kind' description advises preferring '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 75%, and the schema already includes descriptions for the main parameters (x, y, key, kind, action, button, pressed, project, strength). The description enumerates input kinds but doesn't add syntax or modifier details beyond the schema, so a baseline of 3 is appropriate.

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

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

The description uses the specific verb 'Send' with resource 'synthetic input to the running game', and enumerates the input types (action, key, mouse move, click). This clearly distinguishes it from editor-control or project-management sibling tools by focusing on runtime input simulation.

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

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

It states 'Requires bridge_install and a running game' as a prerequisite, giving clear context for when the tool can be used. It doesn't explicitly name alternative tools, but the running-game scope implicitly separates it from editor tools.

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

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

With no annotations, the description carries the full burden. It does disclose a useful behavior: 'return the final output summary'. However, it does not mention the 'all' option or any side effects of stopping (e.g., unsaved changes), leaving some behavioral ambiguity.

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

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

The description is one concise sentence, front-loaded with the action and outcome, with no redundant words 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 stop tool with two parameters, the description covers the core action and return value but misses the parameter-specific behavior (the 'what' choices). Given the lack of output schema and annotations, a bit more detail about the 'all' option and process behavior would round it out.

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% (project has a description, what does not). The description fails to add meaning to the 'what' parameter, omitting the 'all' option entirely. It does not compensate for the gap left by the schema, making parameter understanding weaker.

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 ('running game or editor') with the scope 'started by this server', clearly distinguishing it from sibling tools like run_project. It also states the return value, making the purpose unambiguous.

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

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

The description provides no explicit guidance on when to use this tool versus alternatives such as run_project or get_output. The only hint is the phrase 'started by this server', which implies it is the counterpart to run_project but does not say so directly or mention any exclusions.

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