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

Annotations declare destructiveHint=false, but the description advertises 'delete' animation, 'remove_track', 'overwrite?=true' and 'replace?=true' defaults that replace existing data. This contradicts the destructiveHint annotation even though the description notes all edits are undoable.

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 necessary for a 14-action, 38-parameter tool. It is front-loaded with a one-sentence summary and organized as an action list, though the bullets are extremely dense and repeat some schema detail.

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

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

Given the complexity and lack of an output schema, the description covers return content for list/get/tree_info and explains mutation behavior and undoability. Some minor return/error details for edit and delete are absent, but the core operational picture is complete.

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

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

Schema coverage is already 97%, but the description adds action-specific parameter mapping that the schema cannot express: which parameters apply to create vs tree vs sprite_frames, defaults, nested key/track object shapes, easing values, sheet slicing options, and example values. This is rich semantic guidance beyond the input schema.

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

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

The description opens with a specific verb and resource set: 'Animate anything: build AnimationPlayer animations... SpriteFrames... AnimationTree state machines' and enumerates every action. It clearly distinguishes the animation domain from sibling tools like node, scene, or signal.

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

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

Each action is given clear context: create builds a complete animation, list returns one or all players, tree builds an AnimationTree and replaces an existing tree_root. It does not explicitly state when to prefer this tool over sibling tools, but the action-level guidance 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?

Annotations declare openWorldHint=false, but the description explicitly describes searching external CC0 libraries and calling AI generation APIs (OpenAI, ElevenLabs, Meshy) — clearly networked/open-world operations. This direct contradiction overrides the otherwise useful behavioral details.

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

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

Long but appropriately so for 11 actions. The overview is front-loaded, followed by compact action bullets. Each line provides necessary parameter or behavioral detail with no obvious filler.

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

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

Given 11 actions, 17 parameters, nested objects, and no output schema, the description covers required API keys, defaults, return behavior (job id for polling), and file destinations. It is complete enough 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 100% but the schema descriptions are generic; the description supplies action-specific parameter semantics: enum-like values for kind/shape, defaults (limit=10, resolution='1k', wait_seconds=60), path conventions, and parameter combinations per action. This adds substantial meaning beyond the schema.

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

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

States a specific verb+resource: 'Get art and audio into the game', and enumerates all actions clearly. It does not, however, explicitly differentiate from sibling tools such as resource, audio, or files.

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?

Gives clear per-action context: placeholders for prototypes without keys, free libraries for real assets, AI generators when keys are available. It stops short of naming when to use this tool instead of siblings or when not 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?

Annotations only declare the safety profile (readOnly=false, destructive=false, openWorld=false), while the description adds substantial extra behavior: bus edits are saved to default_bus_layout.tres and are undoable, remove_bus reroutes senders to Master, loop=true modifies import settings so it loops everywhere, overwrite defaults to true, and Master cannot be re-sent. This is rich disclosure 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 one-paragraph overview is front-loaded, and the action list is organized per-action with parameters inline, which is efficient for an 8-action tool. It is dense and long, but nearly every clause carries actionable detail rather than filler.

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

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

Given 8 actions, 48 parameters, nested objects, and no output schema, the description covers every action's inputs and side effects (undo, file writes, import reimports) so an agent can invoke each correctly. Nothing essential for correct invocation is missing.

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

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

Schema coverage is 100%, so the schema baseline is 3, but the description adds real value the schema lacks: the full effect-type list (reverb, delay, lowpass, ...), property aliases (cutoff->cutoff_hz, mix->wet, gain->volume_db), and preset-override semantics ('Preset values can be overridden individually'). These go beyond per-parameter descriptions.

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

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

The opening sentence states a specific verb+resource scope (audio buses, players, stream info, looping, procedural SFX) and names concrete artifacts like default_bus_layout.tres and .wav output. It is clearly distinguishable from sibling tools such as animation, shader, and particles.

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

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

Each action is documented with its parameters and usage context, e.g. generate_tone is motivated ('so prototypes have sound without any assets') and player type selection is explained ('1d at scene root for music, 2d/3d under a Node2D/Node3D entity'). It does not, however, explicitly name external alternatives or state when NOT to use a given action.

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 the safety profile (readOnly=false, destructive=false, openWorld=false); the description goes further by disclosing transaction semantics: atomic=true is default, the batch stops at the first error and undoes prior work, and it operates on editor-side tools. It does not explain result reporting or how non-atomic partial failures are surfaced, which is the main remaining 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?

Front-loads purpose and transaction behavior in two tight sentences, then separates the action's parameter shape into a compact list. No redundant filler relative to the information conveyed.

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 exists, and the description covers the transaction rollback behavior, default atomicity, and method addressing needed to invoke it correctly. It omits what a caller receives on success/partial failure, which matters for a batch executor, keeping it just below fully complete.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning the schema lacks: the 'method' field's required '<tool>.<action>' format and the list of valid tool namespaces, plus restating the atomic default. This is genuine added value over the bare string/boolean definitions.

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

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

States a specific verb and resource ('Run many editor operations in one round trip as a single transaction') and immediately distinguishes itself from the sibling tools it composes by naming the '<tool>.<action>' method scheme. An agent can tell this apart from exec/run/node without opening any schema.

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?

Gives a clear use case ('build a whole level or UI in one go') and implicitly frames the alternative — the individual sibling tools whose methods it references. It does not explicitly state when NOT to batch (e.g. single operations), so it stops short of the 5 tier.

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?

Far exceeds the annotations: it discloses the automatic baseline creation, storage in a private git history under .godot/forge, that the user's own git is untouched, the git dependency, the Forge dock UI with Approve/Discard, that restore keeps the changeset open, that begin closes the previous changeset as accepted, that revert_changeset opens a new changeset, and that discard is destructive and needs user confirmation.

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 structure is exemplary for a 10-action tool: a short conceptual paragraph followed by one scannable line per action with inline parameter signatures. The introductory prose ('like a sandbox', the dock-button detail) is slightly chatty, but overall it is front-loaded and each action line 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?

With no output schema, the description compensates by describing return shape per action (status returns the open changeset plus changed files; diff returns a unified diff plus stat; history returns past changesets with outcomes and ids). Combined with the mutation/destructive guidance and the git-dependency note, an agent 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?

Schema description coverage is already 100%, so baseline is 3, but the description adds per-action parameter mapping and defaults that the schema does not convey (e.g. accept_previous?=true for begin, checkpoint as 'name or commit prefix', which actions take path/paths/id). This meaningfully exceeds the flat per-property 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 opens by defining exactly what a changeset is (a reviewable/reversible baseline recorded automatically before the first edit) and then enumerates all 10 supported actions with their parameters. Despite the generic tool name 'changes', an agent immediately understands this is the changeset/rollback manager, and no sibling tool (files, project, exec, etc.) overlaps that 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?

It gives explicit situational guidance per action: checkpoints before risky steps, restore if an approach fails, approve 'only when the user asked you to, or at the end of a task they approved', and discard only after confirming with the user. It also implicitly distinguishes restore (whole changeset) from revert_files (selected files) from revert_changeset (undo an approved changeset). It does not name alternative sibling tools, which keeps it just short of a 5.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context: signatures come from the installed engine, descriptions match the release, the migration action returns 3→4 renames, and status reveals index/download progress. It omits only minor operational details like caching or rate limits.

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 purpose and a high-value warning, then uses a tight action list with inline parameter hints and examples. Every sentence earns its place; the length is justified by the tool's six actions and seven-parameter schema.

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

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

For a multi-action, read-only documentation tool with no output schema, the description is essentially complete. It explains each action's inputs, what each returns at a high level, and how the tool fits into a Godot workflow. No critical agent decision is left unspecified.

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 already 100%, but the description adds substantial meaning by mapping parameters to actions: query for search, name/filter/full for class, Class.member for member, optional query for migrate, optional topic for guide, and no params for status. It also supplies concrete examples like 'move and slide' and 'KinematicBody2D', which the schema alone does not provide.

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: official Godot class reference, migration notes, and built-in guides for the exact installed engine version. It enumerates all actions and distinguishes itself from sibling API/runtime tools by being a documentation lookup surface. An agent can immediately tell what it does and why it matters.

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 usage context: 'Check here before using an API you are not 100% sure exists in Godot 4' and provides action-level examples. However, it does not explicitly name sibling tools as alternatives or state when not to use it, so it stops short of the full when/when-not/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 provide coarse safety hints (readOnlyHint false, destructiveHint false). The description adds per-action behavioral detail beyond annotations: clear_logs empties the buffer, restart defaults save=true, install_addon copies and enables the add-on, and use_project launches an editor if needed. It does not state which actions are read-only versus mutating, but it 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?

Front-loaded with a one-sentence summary, then a scannable per-action list that packs parameter details without waste. For a 14-action multiplexer, this structure is efficient and every line contributes invocation guidance.

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 flat schema and absence of an output schema, the description is nearly complete for correct invocation, covering all actions with their parameters and defaults. A minor gap is that it does not indicate which actions return what data or are read-only, but the annotations and schema cover enough for selection.

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 89%, so the schema already documents most parameters. The description still adds meaningful value by mapping parameters to specific actions and supplying defaults (steps=1, save=true) and allowed values (main_screen options, level/source values) that are absent or less specific in the schema. It also documents parameters like limit, force, and nested forge_settings that the schema does not list, compensating for 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?

States a specific resource and scope: editor state and connection management, listing domains like status, logs, undo/redo, settings, and project connection. An agent can identify this as the editor-control tool, but the description does not explicitly differentiate it from siblings such as 'project' or 'scene' when their responsibilities overlap.

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 action list implies when each action is appropriate (e.g., 'notify' to show a toast, 'use_project' to switch projects), giving implied usage. However, there is no explicit guidance on when to choose this tool over siblings like 'project' or 'run', and no exclusions or preconditions are 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 already declare destructiveHint=true and readOnlyHint=false, so the safety profile is covered. The description adds useful context beyond annotations: file changes are tracked by changesets, and forge.begin/commit enables undoable edits. It does not detail error behavior or return payload shape, so it falls just short of 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 front-loaded with the escape-hatch purpose and preference for dedicated tools, then uses a compact action list. Every sentence and bullet earns its place by explaining a distinct execution mode or parameter convention. There is 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 complex code-execution tool with three modes, the description covers when to use it, the side-effect tracking, undoability via forge, and action-specific parameters. With no output schema, it could say more about what the tool returns or how errors surface, but it gives the agent enough 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?

The input schema has 100% description coverage, but the description is essential because the action parameter explicitly redirects to it. It explains each action's parameter shape, including the expected function body signatures for editor and game, return semantics, and forge helper methods. This adds substantial meaning beyond the schema's field 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?

States a specific action and scope: run a GDScript snippet in the editor or running game as an escape hatch. It explicitly positions itself against sibling tools by saying to prefer dedicated tools when one fits. An agent can identify its purpose and differentiation immediately.

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 ('when no dedicated action fits') and example use cases (bulk procedural generation, one-off fixes, complex queries). It also states the general alternative preference: 'Prefer dedicated tools.' This is about as clear as usage guidance gets.

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 readOnly=false, destructive=false, openWorld=false; the description adds substantial behavior beyond them: build runs a separate headless Godot process, saves unsaved scenes first, writes a .gdignore for in-project output folders, and returns ok/output file+size/errors/warnings/hint. It also discloses that add_preset overwrites a same-named preset and that unlisted options retain Godot defaults.

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

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

Front-loaded flow statement followed by a per-action breakdown that keeps 5 actions and 16 params navigable. Dense but organized; minor redundancy where export_path/platform defaults repeat schema descriptions.

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-action, 16-parameter tool with no output schema, the description explains each action's params, the workflow order, and the build return shape (ok, output file+size, errors/warnings, hint). Only trivial gap: the artifact list omits iOS even though it appears in the platform enum.

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% (baseline 3), and the description still adds meaning: defaults for name (=platform), export_path ('build/<platform>/<game>.<ext>'), runnable (=true), timeout_s (=900), and that preset is optional when only one exists. Conditional optionality and default semantics are genuinely value-adding.

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

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

States a specific verb+resource framing ('Ship the game: manage export presets, check templates, build executables') and enumerates concrete output artifacts (Windows .exe, Web .html, Android .apk). An agent can immediately distinguish this from siblings like run, game, or exec.

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 an explicit 'Typical flow: templates -> add_preset {platform} -> build {preset}', which tells the agent the correct sequence and prerequisite relationship. It does not name when-not-to-use conditions or competing siblings, 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?

Beyond the annotations, it discloses real behavioral traits: writes keep the editor in sync (scripts reloaded, compile errors returned, scenes/resources refreshed, assets reimported), reads of images return pictures, and delete moves to OS trash rather than permanently removing. The trash behavior and editor-sync side effects are exactly the context an agent needs and are not derivable from destructiveHint=false alone.

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

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

The purpose is front-loaded, then a compact one-line-per-action list that is easy to scan. It is long, but the length is justified by 12 actions; only minor redundancy (parameters repeated in the prose) keeps it from a 5.

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 12-action multiplexed tool with no output schema, the description covers every action, its parameters, defaults, and side effects, and even previews return values ('resource type', 'diagnostics'). Nothing essential for correct invocation is missing.

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

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

The input schema only exposes 8 top-level properties and marks additionalProperties as unconstrained, so most action-specific parameters (recursive, pattern default '*.gd', include_addons, limit, regex, case_sensitive, glob, offset, overwrite default true, update_references, reimport) exist only in the description. The per-action parameter lists with defaults and the warning that edit's 'old must match exactly once, tabs matter' add substantial semantics over 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 opening sentence names a specific verb set (read, write, search, manage) and a precise resource (files inside the Godot project at res://), then enumerates all 12 actions with their key parameters. This clearly differentiates it from siblings like script, resource, scene, and assets, which cover narrower domains.

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 context is given for several actions: 'Prefer this over rewriting whole files' for edit, 'after changing files outside the editor' for rescan, and the note that .gd writes return diagnostics. There is no explicit routing guidance versus sibling tools (e.g. when to use files+read instead of the script 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=false and destructiveHint=false. The description adds important behavioral context: set changes live values but 'not saved', quit 'tests quit handling', audio returns currently playing players, and wait 'inside the game'. It stops short of covering rate limits or auth, but the operational details are rich.

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

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

Front-loads the overall purpose then uses a compact, scannable action list. Despite covering 14 actions and 19 parameters, every line adds necessary detail; no sentence is wasted.

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

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

For a complex multi-action tool with no output schema, the description adequately explains each action, its inputs, and often its return value (e.g., info lists fields, audio describes returns). Path conventions and usage prerequisites are included, leaving no critical 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 coverage is high (89%) so baseline is 3, but the description goes further by mapping every parameter to specific actions (e.g., {path?, depth?=6, props?, whole_tree?} for tree; {expression, path?} for eval) and notes defaults and examples. This adds substantial meaning beyond the schema.

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

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

States a specific verb+resource ('Inspect and manipulate the RUNNING game') and enumerates all capabilities. The qualifier 'after run.play' and 'live' distinguishes it from editor tools like scene or node without opening 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?

Provides clear context ('after run.play') and maps each action to its parameters, but does not explicitly name alternative sibling tools (e.g., node, scene) or state when not to use this tool. The context is strong 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?

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false. The description adds valuable behavioral context beyond annotations: steps run in order with real timing, record captures real input, and stop returns events with timestamps. It stops short of describing failure modes or game-state side effects, but is solid for this tool type.

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

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

Front-loads the core purpose in one sentence, then uses a bulleted breakdown for actions and step formats. Despite its length, every sentence earns its place by documenting the complex input vocabulary required to invoke the tool correctly.

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 five parameters, nested step objects, and no output schema, the description is complete: it defines all three actions, enumerates every step variant, and even notes that record returns timestamped events. Annotations cover safety, so nothing critical is missing.

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

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

Schema description coverage is 100%, yet the description substantially enriches parameter meaning. It spells out every step type in the send action (jump, key, click, drag, joy, axis, text, wait, release_all), and explains record mode and replay speed, far exceeding the terse 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?

States a specific verb (play/simulate input) and resource (running game), and enumerates concrete capabilities (press keys, gamepad buttons, click/drag, type text) that distinguish it from all siblings. An agent can immediately tell this tool is for injecting input into a game session.

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 establishes the context: use this to play or record/replay input in a running game. It does not explicitly name alternatives or when-not to use it, but the action breakdown (send/record/replay) effectively guides usage. Sibling 'ui' or 'game' might overlap, yet no exclusion is given.

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 readOnly, non-destructive, non-open-world, so the safety profile is covered. The description adds real behavioral context beyond that: unknown Godot 3 names return suggestions rather than failing, and results reflect a currently running engine. It does not describe output shape or error behavior for invalid 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?

Purpose is front-loaded in the first sentence, with the action list following as compact reference material. Each line earns its place; the only mild excess is the parenthetical 'no guessing', which is rhetorical rather than informational.

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 dispatcher tool wrapping five distinct operations across eight parameters with no output schema, the per-action parameter documentation is largely complete and covers the fallback-suggestion behavior. The remaining gap is return-value shape, which with no output schema the agent must infer.

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, but the description goes further by mapping which parameters belong to which action (sections for class, query/base for search, domain for node_types, child/parent for check_parent) and by enumerating the valid sections and domain values. That mapping is genuine value the flat schema cannot express.

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

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

States a specific verb and resource — interrogating the running engine for its exact API — and the phrase 'no guessing' plus 'running engine' distinguishes it from the offline 'docs' sibling. An agent can tell this is live introspection rather than static documentation lookup without opening the schema.

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 action breakdown effectively explains which operation to pick for which question (class members, class search, member declaration lookup, node types, parent/child validation), which is strong routing guidance. It stops short of any when-not guidance or explicit differentiation from the 'docs' sibling for offline 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 only declare it is not read-only, not destructive, and not open-world, so the description carries the real behavioral load and does so: bake is called out as synchronous and undoable, it returns polygon/vertex counts and bounds, agent returns the movement code to paste into the body's script, and holes are created as NavigationObstacle2D children that carve the bake. Missing only auth/permission notes.

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

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

Front-loaded with a one-line purpose followed by a tight bulleted action list, which is the right structure for a 26-parameter multi-action tool. The individual bullets are dense run-ons packed with parentheticals, costing some readability, but little is genuinely wasted.

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

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

For a high-complexity tool with 26 params, nested objects, and no output schema, the description covers every action, key defaults, and even partial return values (path points/length/reachable, bake counts/bounds, info overview). Only error behavior and scene-editor side effects are left unaddressed, which is minor.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds genuine meaning beyond the schema: defaults (agent_radius 10px in 2D, 4px/0.5m path & target distances), that bake?=true is implied when an outline is given (2D) and always on in 3D, that outlines are merged and holes carve them, and that link positions are in the parent's space.

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

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

Opens with a specific domain statement ('Pathfinding setup') and then enumerates six concrete actions (region, bake, agent, link, path, info), each with a verb+resource (create a NavigationRegion2D/3D, add a NavigationAgent, query a path). An agent can clearly separate this from siblings like physics, tiles, or node, which do not cover navmesh baking or path queries.

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 context is embedded for each action: path is for 'verify level connectivity before running the game', bake is for re-baking after adding children, region switches to group source mode when sources are given. It never names an alternative tool to use instead, so it stops short of explicit when-not guidance.

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

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

Goes beyond the annotations by disclosing that every change is undoable (Ctrl+Z) and saved, and that 'warnings' flag setup mistakes such as missing collision shapes or textures. This is meaningful context, though the presence of a 'delete' action alongside destructiveHint=false is worth scrutiny.

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

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

Front-loads the core statement, then uses a dense action list where each line earns its place given the flat-schema design. It is long but the length is proportionate to 14 distinct actions; a slightly less telegraphic style would read better.

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 get action's description of returned data (type, inheritance, script, props, children, groups, signal connections, warnings) covers the return contract. Nested specs (children, nodes) are also explained, leaving only minor gaps for a tool this broad.

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 is a flat union of 15 params shared across 14 actions, so the description's per-action parameter specifications (add's {type, name?, parent?, props?, children?}, set's sub-property syntax 'position:x', duplicate's offset-per-copy) are essential and not derivable from the schema alone. It also clarifies that type accepts a class, class_name, script, or scene instance.

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

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

Opens with a specific verb set and resource ('Add, edit and inspect nodes in the edited scene') and scopes it to the edited scene, which separates it from siblings like scene, signal, and script. The 14 named actions make the exact capability surface 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?

Each action documents its own parameter shape, so an agent knows which action to reach for and what it needs (e.g. find for searching, selection to resolve 'this node'). It never states when NOT to use this tool versus siblings like scene or script, so it stops short of full routing 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?

Beyond the annotations, the description discloses that changes are undoable, that CPU particles lack turbulence/collision, that visibility bounds grow with faster or longer-lived particles, that presets are tuned in 2D pixels and converted to meters for 3D, and that one-shot presets fire only when the scene starts unless restart is called. These are exactly the behavioral caveats an agent needs before invoking create, set, or convert.

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

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

The description is long but tightly structured: a front-loaded summary paragraph followed by a bulleted action list. Each action bullet carries only the parameters and caveats relevant to that action. For a tool with six actions and 23 parameters, the length is justified and there is little wasted 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 tool's complexity, nested objects, and lack of an output schema, the description is complete enough to invoke correctly. It covers purpose, action routing, parameter defaults, mutation consequences, conversion limitations, and even return shape for get. No critical operational detail is missing for an agent to choose and call the tool.

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

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

Schema coverage is already 100%, so the schema documents the 23 parameters. The description adds action-specific meaning beyond the schema: it maps parameters to create/set/convert, explains preset tinting, notes that size is in pixels for 2D and meters for 3D, and describes restart behavior for one-shot effects. This raises it above the baseline of 3 for fully documented schemas.

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 resource (particle effects) and enumerates all six supported actions, so the agent knows exactly what the tool does. It also distinguishes itself by listing supported presets and noting GPU/CPU and 2D/3D coverage, making it easy to separate from generic scene, node, or animation siblings.

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

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

Each action is given a clear context: presets lists available presets, create adds a particle node, set edits one, get retrieves settings, restart previews one-shot effects, and convert switches between GPU and CPU. It also explains one-shot behavior and when to call restart. It stops short of naming alternative tools for adjacent use cases like keyframed animation, but the action-level guidance 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?

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, but the description adds rich behavioral context: creation is undoable, fit_shape creates a missing CollisionShape, settings without arguments performs a read, and raycast operates in the editor world with global coordinates. It also discloses defaults for shapes, gravity units, and tick rate, giving the agent operational confidence 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 necessarily long for a 45-parameter, six-action tool and is front-loaded with a summary followed by structured action bullets. It is dense and some action bullets are run-on, but each sentence carries specific calling information. It is appropriately sized for the complexity, though not maximally concise.

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

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

For a complex mutation-oriented tool with no output schema, the description covers inputs, defaults, alternatives, and editor-vs-runtime behavior thoroughly. It only briefly mentions return information for raycast and omits return details for other actions, which is a minor gap for an agent needing to chain calls. Overall, it is complete enough to invoke correctly.

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

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

Although schema description coverage is already high at 84%, the description adds substantial action-specific meaning: body shape types, default rect/box sizes, fit_shape visual-fitting rules, layer name/number semantics, joint types and anchor defaults, and settings units/defaults. This goes well beyond the schema's brief per-parameter notes and directly guides correct parameter construction.

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

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

The description opens with a clear verb-and-resource statement: physics bodies, collision shapes, joints, raycasts, and project physics settings. It enumerates each action with domain-specific terminology, making it easy to distinguish from siblings like node, scene, or project. An agent can identify the tool's scope without opening the schema.

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 action list clearly implies when each sub-operation applies, and the raycast entry explicitly directs the agent to game.raycast for the running game. However, there is no broader guidance on when to use this tool versus node/scene for creating physics objects, and no explicit when-not conditions beyond the raycast distinction.

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=false and openWorldHint=false, so the agent knows this mutates local project state. The description adds real value beyond that: set_setting is 'saved to project.godot', create_project 'launches the editor', and set_layer_name 'returns its bit value'. It stops short of noting that remove_autoload/remove_input_action mutate the project file or that removal is not automatically 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 opening sentence is front-loaded with scope, and the action list is dense with no filler. It is long, but for a 17-action multiplexer nearly every line earns its place; only minor redundancy exists between the action lines and the generic parameter descriptions.

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 12 parameters spread across 17 actions, the description is the main contract, and it handles inputs well. Return values are only described incidentally (set_layer_name), so an agent gets no picture of what info, list_settings, or plugins return; for a tool this broad that is a real but modest 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 coverage is 92%, but the generic schema describes fields abstractly ('Setting/action/autoload/layer/plugin name'), so the description carries the crucial mapping of which parameters each action consumes, plus concrete syntax examples ('key:W', 'joy_axis:left_x-', 'physics/2d', layer 1-32). This adds substantial meaning the schema alone does not convey.

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

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

The description names a specific resource (project-level info and settings of the connected Godot project) and enumerates the exact scope: settings, autoloads, input maps, layers, plugins, UIDs. This is clearly distinguishable from siblings like scene, node, script, or resource, which cover other Godot domains.

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

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

Each of the 17 actions is paired with its purpose and parameters, and there is explicit steering ('Prefer actions over hardcoded keys in scripts'), which tells the agent when to use add_input_action. However, there is no explicit when-not guidance or routing against sibling tools (e.g., when to use project vs editor or files for path handling).

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, openWorldHint=false, correctly signaling a mostly-mutating but non-destructive, local-only tool; the description does not contradict this. It adds some behavior context (extract writes an embedded resource to its own file; create can take a custom script), but says nothing about disk writes, permission needs, or reversibility of edit/duplicate.

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?

Purpose is front-loaded in one sentence, followed by a compact action list where each line carries payload shape plus a concrete example. Dense but every line earns its place; only mild verbosity in the example payloads.

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, 7-action tool with no output schema, the description covers each action's required arguments, which is the main gap the schema leaves. It does not describe return values or failure modes, but with no output schema that omission is tolerable rather than disqualifying.

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 90% schema coverage the baseline is 3, but the description goes further by binding parameters to actions (e.g. assign uses path=node, property, resource='res://..' or inline {type,...}; create accepts type=Resource with script=res://item_data.gd). This supplies per-action meaning the flat schema cannot express. Return/error semantics are still absent.

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 specific resource domain (Godot .tres resource files: materials, shapes, themes, curves, custom Resource classes) and enumerates the seven actions with their argument shapes. An agent can tell this apart from node/scene/script siblings by the resource-centric scope, though the definition never explicitly names a neighboring 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 per-action breakdown (create/read/edit/duplicate/assign/extract/types) with example payloads gives clear context for which action applies to which task. It also notes that inline resources can be set directly through node props, which implicitly flags an alternative path. No explicit when-not guidance or routing to siblings, 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 only declare readOnlyHint=false, destructiveHint=false, openWorldHint=false, which says almost nothing about behavior. The description carries the load well: play SAVES open scenes (a real side effect not in annotations), waits until the in-game runtime connects, and returns startup errors; mute defaults to the editor setting and is forced on in headless editors; continue resumes after the debugger stopped on an error. That is meaningful disclosure beyond structured data.

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

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

Front-loaded purpose and usage flow, followed by a compact per-action list with no filler sentences. Slightly dense with an undocumented 'settle' option, but every line 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?

For a 7-parameter, action-dispatch tool with no output schema and only safe-by-default annotations, the description covers launch, stop, status, error retrieval (script file:line and stack), streamed output, and debugger resume. Return-shape and failure-mode details are thin but adequate 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 100% (baseline 3), but the description adds value the schema does not: it maps which parameters belong to which action and supplies defaults ('restart?=true, timeout?=20, mute?', 'level?=error'). One caveat: it references a 'settle?=0.5' parameter that does not appear in the input schema, a minor misalignment.

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

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

The opening sentence names a specific verb and resource ('Play the game from the editor and read its output') and immediately distinguishes the tool from the interaction siblings by deferring them ('Then use game/input/view to interact'). An agent can tell it apart from 'game', 'input', and 'view' without opening any schema.

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

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

It gives explicit routing guidance ('Then use game/input/view to interact') and explains what each of the six actions is for, including easing back after a debugger stop via 'continue'. It stops short of stating when NOT to use it (e.g. vs. the 'game' sibling for non-editor launches), so there is no exclusion 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 declare readOnlyHint=false and destructiveHint=false, so the mutating nature is already known; the description adds genuinely new behavior: 'Edits are auto-saved after every call', the 'becomes main scene if none is set' side effect of create, the save?=true default on close (closing persists), and the subtree-replacement semantics of pack_branch. This is real disclosure beyond the structured fields, though it never states what happens on failed saves or whether reload discards unsaved work.

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 summary is front-loaded and the per-action list is terse and scannable; every line adds information. The compressed pseudo-signature syntax ({path, root_type='Node2D', ...}) takes some parsing effort and slightly overloads the prose, keeping it off a perfect 5.

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 12-action, 11-parameter tool with no output schema, the description covers invocation well and annotates the one return type that matters most (source returns raw .tscn text). It leaves the return shapes of tree/current/list unspecified, but with no output schema and full schema coverage elsewhere, the definition is close to 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?

Schema coverage is 100%, so a 3 would be the floor, but the description goes well past the schema by mapping which parameters apply to which of the 12 actions (e.g. create takes root_type/root_name/inherits/open/set_main; instance takes scene_path/parent/name/props). The schema itself provides no action-to-parameter mapping, so this is essential, non-redundant semantic value.

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

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

The opening sentence names the verb family (create/open/save/inspect) and the exact resource (.tscn scene files), and crucially states the relational scope: 'The edited scene is the target of the node/signal tools.' An agent can immediately distinguish this from the node, signal, and project siblings without opening any schema.

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 action list implicitly routes between alternatives — 'list: every scene in the project' vs 'current: the edited scene and all open scenes' vs 'tree: node tree' are clearly differentiated. The note that other tools operate on the edited scene functions as cross-tool usage guidance. It stops short of explicit when-not-to-use or exclusion statements, so it lands just below 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?

Beyond the annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=false), it discloses genuinely useful behavior: creating/writing/editing a .gd reloads it in the editor and returns compile diagnostics immediately, write replaces the entire script, edit does exact replacements, lint reports unused variables/shadowing/unsafe casts, and open surfaces the script to the user. This is rich context the annotations do not carry.

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 tight two-sentence behavioral lead-in followed by a one-line-per-action list. For a 13-action tool this is dense but every line earns its place, and the most important behavioral note (diagnostics returned on edit) 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?

With no output schema, the description carries the return-value burden and does so for most actions (diagnostics, outline contents, references). It is nearly complete for a 12-param multi-action tool, though it does not explicitly confirm persistence semantics of write/edit or spell out what `read` returns versus `outline`.

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% (baseline 3), but the schema is a flat union of 12 params with only a single enum, so the description's per-action parameter mapping ('create: {path, content? | template?: ...}', 'attach: {path: node, script, scene?}') is what actually tells the agent which parameters apply to which action. That is meaningful 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 opening line names the concrete resource (GDScript/C# .gd files) and the verb set is enumerated per action, so an agent can tell this apart from the generic `files` sibling and from `scene`/`node`. Each action is stated as verb+resource (create a new script, read source, edit with exact replacements, lint diagnostics, 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?

It gives real routing guidance: 'fix errors before running', 'Use templates for common controllers', and distinguishes lint ('full language-server diagnostics ... for scripts on disk') from validate ('compile check', no args = whole project). It stops short of explicitly contrasting edit vs write or read vs outline, so it falls short of the 5-level when/when-not coverage.

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 annotations already disclose readOnlyHint=false, destructiveHint=false, and openWorldHint=false, but the description goes well beyond them: it notes that create writes and compile-checks, returns ok/diagnostics/uniforms, set_param is undoable on nodes with embedded materials, a shared .tres material edits and saves that file, and overwrite=true starts fresh. It also discloses validation behavior such as first-error line numbers, lint checks, and Godot 3-to-4 migration 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?

The description is long, but it is structured around the eight actions and front-loads the overall purpose before listing action-specific parameters. Most sentences carry actionable detail, though the Godot 4 syntax note and some action descriptions are dense enough that the text could be tightened slightly.

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 eight actions, nineteen parameters, no output schema, and only minimal annotations, the description is complete enough for an agent to invoke the tool correctly. It covers action selection, key parameter interactions, return values such as diagnostics and uniforms, side effects, and Godot-version syntax constraints.

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 95%, so the baseline would be 3, but the description adds substantial action-specific meaning beyond the schema: it documents template names per shader type, type inference from assign_to/template/scene, special handling for spatial outline via material_overlay, overlay and next_pass routing, params coercion examples, and material update semantics. These details help an agent choose and populate the correct parameters rather than relying on generic schema descriptions.

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

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

The description states a specific verb set and resource: it creates/read/edit/validates Godot .gdshader files, assigns them to nodes, lists uniforms, and saves ShaderMaterials. The opening sentence enumerates the exact scope and includes recognizable Godot-specific artifacts, so an agent can distinguish this from general resource, script, or node 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 context for each action through the 'Actions:' section, including when to use templates, create, validate, read, edit, uniforms, set_param, and material. It does not explicitly name alternative tools or state when-not-to-use conditions, but the action-level guidance is strong enough to route most invocations correctly.

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

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

Annotations declare readOnlyHint=false and destructiveHint=false, but the description adds important behavioral context beyond them: connections are persisted in the scene, 'connect' can generate a handler function in the target's script, and project-scope graph parsing reads all scenes and scripts. It doesn't describe failure modes or return payloads, so not 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?

Front-loaded purpose sentence followed by a compact action list; every sentence carries information (scope, persistence, defaults, example). 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 9-parameter mutation tool with no output schema, the description covers action semantics, defaults, persistence, and cross-file parsing well. It omits what each action returns (e.g., list output shape, graph format) and any permission requirements, leaving a modest 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 coverage is high, but the input schema only lists nine generic properties while the description documents action-specific parameters absent from the schema (connected_only, create_method, binds, deferred, one_shot) plus defaults like '_on_<from>_<signal>'. This goes meaningfully beyond the structured fields, though it doesn't explain each optional flag in depth.

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: 'Inspect and wire signals in the edited scene,' then enumerates four concrete actions (list, connect, disconnect, graph). It is clearly distinguishable from generic siblings like node or script, which don't deal with signal wiring.

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 establishes clear operating context: signals in the edited scene, connections saved in the scene, and defaults for each action (method name pattern, create_method=true). It does not explicitly route the agent away from sibling tools or state when-not to use it, so it stops short of a 5.

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

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

Annotations declare non-read-only, non-destructive, closed-world, so the safety profile is partly covered. The description still adds real behavioral context the annotations do not: audio is muted by default ('audio muted unless mute=false'), stop_on_failure defaults to true, scenarios can be persisted via save_as, and compare_image records a baseline if missing. These are meaningful side-effect disclosures.

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 opening summary is front-loaded, and the per-action bullet list with nested step types is dense but well organized. The exhaustive step enumeration is lengthy yet justified given the schema treats steps as free-form; only minor trimming is possible.

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 broad test/verify tool with no output schema, the description never explains what a run returns — pass/fail results, assertion output, error reporting, or how a failed scenario surfaces. The input side is thoroughly covered, but the result side is a notable gap for a verification tool.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds substantial meaning beyond the schema — notably the entire step sub-language (wait_for, wait_node, wait_signal, assert, expect_node, screenshot, etc.) and the note that expressions run with the scene root as self. This elaborates the opaque `scenario` object that the schema only marks as additionalProperties.

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+resource ('Verify the game works') and then enumerates each of the six actions with what it does (scripted playtests, project lint, unit tests, baseline comparison). It is clearly distinguishable from siblings like `run`, `game`, and `input`. It falls short of 5 only because it is a kitchen-sink tool bundling several distinct capabilities rather than one focused 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?

There is one sequencing hint ('Run before playing' for lint) and scenario explanation, but no explicit when-to-use/when-not guidance and no routing to alternatives among the many siblings. Usage is largely implied by the action names rather than 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=false, and the description reinforces that mutations are safe by stating 'All painting is undoable' and calling out clear as undoable. It also discloses that overwrite relinks layers of open scenes using the old TileSet, which is genuinely 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?

Front-loaded overview (what, coordinate conventions, undo guarantee) followed by a scannable per-action breakdown. It is long, but the 10-action, 39-parameter surface justifies the density and every action entry carries distinguishing detail rather than 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?

With no output schema, the description steps in to describe read's return (used cells plus an ASCII picture with auto_legend) and covers the parameter semantics for every action, including required TileSet prerequisites for terrain autotiling. Not every edge case (e.g., error behavior on a missing layer) is covered, keeping it at a strong 4.

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 already 90%, so the baseline is 3. The description exceeds that by explaining non-obvious semantics: the '010/111/010' 3x3 terrain mask format, tile-centered collision points, tile-size/block origins for terrains, the alternative parameter for random variety, and how legends differ between from_ascii and read.

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?

Names a concrete resource (2D tile maps, TileMapLayer/TileSet) and enumerates the specific verbs available (create_tileset, paint, terrain, from_ascii, read, clear). It explicitly distinguishes itself by stating the deprecated TileMap node is never used and by scoping to tilemap work that no sibling tool covers.

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 per-action guidance ('Use several layers for background/ground/decoration', 'Best way to lay out levels' for from_ascii, 'Use it to check what's painted' for read, and the assets.placeholder pointer when no art exists). It does not state explicit when-not conditions or name a concrete alternative 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 declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, but the description adds substantial behavioral detail beyond that: calls are 'undoable', returns include created node paths with 'pressed' signals and layout warnings, 'null value removes' a theme override, unknown theme item names are rejected with the valid list, and zero-size Control scene roots are auto-stretched. No annotation 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 long but appropriately structured for an 8-action, 36-parameter tool: a front-loaded summary paragraph followed by a detailed action list. Most sentences carry unique information, though some parameter-level detail overlaps with the 100% schema coverage, making it slightly less tight than ideal.

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

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

Given the tool's complexity (8 actions, 36 params, nested objects, no output schema), the description is complete: it covers all actions, return formats, edge cases (Containers vs anchors, empty scene root behavior, theme variations, font import), and error handling. An agent 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?

Schema description coverage is 100%, so the baseline is 3, but the description adds rich semantics far beyond the schema: it documents the nested spec object, lists all layout anchor presets, explains per-node shortcuts (text, min_size, size_flags, align/valign, font_size, etc.), details theme_overrides structure, and describes action-specific parameters like button_style inheritance and font import behavior.

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 ('Build game UIs... from Control nodes') and then enumerates eight concrete actions (build, menu_template, theme, font, focus, inspect, etc.), each with a clear purpose. This distinguishes it from generic node/scene siblings by focusing on Control-node UI construction.

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 action-level usage (e.g., 'build creates a whole UI tree', 'inspect explains why a layout looks wrong') and a contextual tip ('Put in-game HUDs under a CanvasLayer so they don't move with the camera'). It does not, however, name alternative sibling tools (e.g., when to use this instead of node or scene) or explicit 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 only declare the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=false). The description adds real behavioral context beyond that: rendering requires a non-headless editor, the `game` action returns viewport_size + coord_scale with the click-coordinate formula, and `render` auto-frames without editor camera fiddling.

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 one-line summary is front-loaded, followed by a scannable `Actions:` list that groups each mode's parameters inline. 'Look at things' is minor filler, but every subsequent line carries actionable detail.

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

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

With no output schema, the description carries the return-value burden and does so for the `game` action (viewport_size + coord_scale). For a 10-parameter, 4-action tool it is largely complete, though the return shape of `render`/`editor`/`preview` is left implicit.

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

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

Schema coverage is 100%, so the baseline is 3, but the description goes further by giving defaults (max_size=1280, preview_light=true), enumerating the allowed angle values, and cross-referencing parameters per action. It also mentions parameters (annotate_groups, format, preview_light) not present in the schema, adding interpretation the schema alone 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 enumerates the four capture modes (game screenshot, offscreen render, editor viewport, resource preview) with concrete detail, so the tool's role as the visual-capture entry point is clear. It stops short of explicitly distinguishing itself from the sibling `editor` tool, which it partially overlaps with via its own `editor` action.

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?

Per-action notes imply when each mode applies (e.g. `render` for offscreen angles, `preview` for texture/mesh/material/scene files), and it flags the non-headless editor requirement. However there is no explicit when-to-use-this-vs-an-alternative routing to siblings like `editor` or `game`.

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 mutation and non-destructive status, and the description adds substantial behavioral context beyond them: undoable scene changes, validation errors instead of NaN/zero, material file edit side effects, mesh library merge behavior, and scatter ground raycasting. No annotation contradiction is present.

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 front-loads the overall purpose before an action-by-action breakdown. Most sentences earn their place for a tool this complex, though there is some density and repetition with schema descriptions.

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 101 parameters, 12 actions, nested objects, and absence of an output schema, the description is remarkably complete. It covers action semantics, defaults, validation, file side effects, and scene mutation 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 already 100%, but the description adds crucial action-discriminated semantics for 101 flat parameters: per-action defaults, allowed shapes, nested CSG trees, collision mappings, material modes, import keys, and scatter modes. This is far beyond what the schema alone conveys.

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?

Starts with a specific verb and resource: 'Build 3D levels in few calls', then enumerates all 12 actions (mesh, csg, material, light, etc.). This makes the tool's scope immediately distinguishable from generic sibling tools like scene or 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?

Provides clear context for when to use it: building 3D levels and performing specific 3D operations. However, it never names sibling alternatives or states when not to use it versus tools like scene, node, or tiles.

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