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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context beyond annotations: it is static analysis with zero Godot dependency, it labels blind spots honestly (runtime dynamic signal names and autoload-to-autoload connections are invisible), and it indicates that declaration/emit sources are labeled separately. No contradiction with annotations.

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

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

The description is dense but well-structured: core positioning first, then the two action modes, then the honest blind-spot note. There is no filler, each sentence carries operational meaning, and the action-based structure makes it easy for an agent to parse.

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

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

For a multi-mode static analysis tool with seven parameters and no output schema, the description gives enough operational context: it defines each action, lists the relevant parameter dimensions, and describes what the results cover. The remaining gap is a lack of explicit description of output shape/truncation behavior at the semantic level, but the schema already documents limit/default, and the blind-spot statement prevents most false expectations.

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

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

The input schema already describes all parameters (100% coverage), so the bar is at baseline 3. The description adds value by connecting actions to parameter semantics and outputs: signal mode selects connectors/emitters/listeners; script mode references; scene mode connections/scripts/instantiation sites. This gives the agent real semantic grounding beyond the schema's individual 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?

The description states concrete verbs and resources: signal_map lists all project signal connections, impact_check evaluates the impact surface before a change. It enumerates exactly what is covered (.tscn [connection] declarations, .gd connect/emit references) and distinguishes the two modes, making it easy for an agent to tell this tool apart from generic 'analysis' and sibling signal/project/runtime 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: signal_map for a full signal-connection panorama, impact_check for pre-change assessment, with three explicit scenarios (signal, script, scene). It does not explicitly name sibling tools to avoid, and it doesn't state when not to use this static analysis in favor of runtime or validation tools, so it falls just short of full alternative routing.

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

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

Annotations already mark destructiveHint=true and readOnlyHint=false; the description adds important context that operations are runtime-only and non-persistent, and that persistence requires .tscn editing. It aligns with the annotations and also lists destructive actions like delete and remove.

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

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

The description is compact and front-loaded, with a clear categorization of actions in three short sentences. Every sentence serves a purpose, and 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?

This is a complex tool with 34 parameters and 21 actions, but no output schema. The description provides categories and runtime/persistence guidance, yet it omits the IK-related actions from the schema and does not explain return values or differences among query actions, leaving clear gaps.

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

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

The schema has 100% parameter description coverage, so the baseline is 3. The description groups actions but adds no per-parameter semantics beyond what the schema already provides, so there is no need to compensate.

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

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

The description clearly states the tool's purpose as querying, controlling, and editing animations, and enumerates specific action names grouped by category. It is more specific than the bare name 'animation', though it does not explicitly differentiate from the sibling tool 'animation_track'.

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

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

The description provides a clear breakdown of actions (query, playback, edit) and gives practical usage context: operations are runtime-only and affect only the current execution context, with persistence requiring .tscn editing. It does not explicitly mention alternative tools, but the persistence note serves as a meaningful exclusion.

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

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

Annotations already declare destructiveHint and readOnlyHint=false, so the destructive nature is known. The description adds value by revealing that operations only affect the current execution context and are not persisted, which is beyond annotations. No contradiction.

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

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

The description is three sentences, efficiently front-loaded with the main purpose, then categorically listing operations, and ending with a critical boundary note. Every sentence earns its place; no filler.

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

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

For a tool with 15 parameters and no output schema, the description gives a high-level map of operations and the essential runtime-vs-persistence distinction. It does not cover return values or error handling, but these are not required given the rich schema and annotations, so it's adequately complete.

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

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

The input schema provides comprehensive descriptions for all 15 parameters, including enums and conditional requirements. The description adds no extra param-level semantics, so it scores baseline 3 for a fully schema-covered tool.

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

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

The description clearly states the tool handles animation tracks and keyframes, enumerating all action categories (track, keyframe, curve). It distinguishes itself from persistent file editing by noting runtime-only scope, making its purpose unambiguous.

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

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

The sentence '运行时操作，仅影响当前执行上下文。如需持久化，请编辑 .tscn 文件' explicitly tells when to use the tool (runtime) and when not (for persistence), naming the alternative (editing .tscn). This is clear usage guidance.

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

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

With annotations that only show readOnlyHint=false, idempotentHint=false, and destructiveHint=false, the description adds meaningful behavioral context: operations are runtime-only and do not persist unless the user separately edits .tscn files. This prevents the agent from assuming scene changes are permanent. It does not disclose every side effect, but the persistence boundary is the most important behavior and is clearly stated.

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

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

The description is compact and front-loaded with the core purpose, followed by a concise list of supported operations and then the key scoping note about runtime-only behavior and persistence. The list of operations overlaps with the action enum in the schema, but remains a helpful summary without excessive redundancy.

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

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

Despite 18 parameters and action-dependent field usage, the description does not explain which parameters are required or how they combine for each action. It identifies broad capabilities and runtime scope, but the agent must rely entirely on schema parameter descriptions and enums to construct correct calls. There is also no output schema or return behavior description, which is a notable gap for a complex orchestration 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 description coverage is 100%, so the schema already documents all parameters. The description mostly restates operation names and general capabilities, providing little beyond the parameter descriptions themselves. It does not add new semantics such as default behaviors, required parameter clusters, or validation rules.

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

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

The description uses a specific verb set ('查询、控制和编辑') with an explicit resource (AnimationTree) and enumerates concrete capabilities: creating nodes, adding states and transitions, setting blend parameters, playing states, and editing state properties. This distinguishes it from generic 'animation' or 'scene' tools by scoping it to AnimationTree runtime manipulation and explicitly separating persistence to .tscn 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?

The description explicitly states that this is a runtime operation that only affects the current execution context, which tells the agent when to use it. It also gives a clear when-not/alternative: if persistence is needed, edit the .tscn file instead. This is actionable guidance beyond the input schema.

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

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

The description adds behavioral context beyond annotations: it states that operations are runtime-only and do not persist, which is useful for the agent. While annotations indicate the tool is mutable and non-idempotent, the description enhances this with the temporary-scope trait. It doesn't fully detail side effects, but the annotation coverage lowers the bar.

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

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

The description is compact and front-loaded with the action list using a clean, consistent format. Each sentence earns its place, and there is no wasted text. The structure makes scanning easy.

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

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

For a complex tool with 11 parameters and 4 actions, the description covers the action semantics and runtime scope, which is sufficient given the absence of an output schema. It doesn't elaborate on generic parameters (project_path, load_autoloads) but these are common across sibling tools and not critical to the audio-specific 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?

The input schema already has 100% parameter coverage, so the baseline is 3. The description adds value by grouping parameters with actions (e.g., 'set_param: volume_db/pitch_scale/bus' and 'play: volume_db/pitch_scale') which helps the agent map parameters to the intended action. This goes slightly beyond the schema but remains consistent with it.

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

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

The description clearly states '音频操作' (audio operations) and lists four specific actions (play, stop, set_param, query) with their target resources (AudioStreamPlayer/2D/3D). This is a specific verb+resource structure that distinguishes it from sibling tools like animation or physics.

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

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

The description explicitly states that these are runtime operations affecting only the current execution context, and advises editing the .tscn file for persistence. This provides clear when-to-use and when-not-to-use guidance, effectively serving as an alternative to sibling tools for persistent changes.

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

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

The description goes well beyond the readOnlyHint, idempotentHint, and destructiveHint annotations. It discloses the exact data source path, the type of output (operation counts, risk highlights, recent entries, time range), and the honest limitations of rollback suggestions (create-class deletion, project.godot before_values, and Git reliance). It also mentions that write/destructive operations are auto-persisted via middleware with PII guardrails, providing a complete behavioral picture.

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

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

The description is dense but compact, packing the core action, sub-actions, output summary, and middleware logging behavior into meaningful semicolon-separated segments. It is not overly long, and every sentence provides value, though clearer line breaks or bullet-like separation would improve scanability 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 the five parameters, no output schema, and the already detailed input schema, the description provides comprehensive context: path, action-specific behavior, rollback limitations, and persistence expectations. An agent can correctly invoke both actions and understand the implications of the results without requiring additional missing information.

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

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

The input schema already covers all 5 parameters with descriptive comments, including action-specific meanings such as 'get_log:取末尾 N 条' and 'suggest_rollback:条目序号'. The tool description reinforces the actions but does not need to add much parameter meaning beyond the schema. This matches the baseline for a schema with 100% description coverage.

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

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

The description begins with '操作审计日志查询' (operation audit log query), clearly identifying a query action on a specific audit log resource. It further distinguishes two sub-actions: get_log for statistics and suggest_rollback for rollback suggestions, making the tool's purpose concrete and distinct from sibling categories like qa or validation.

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 specifies when to use each internal action: get_log for reading stats/history with time/count filters, and suggest_rollback for advising on specific logged entries. It also mentions that write/destructive operations are logged automatically, which hints at when audit data is available. It does not explicitly name alternative tools, but no sibling is a direct substitute, so this is sufficient.

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

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

No annotations are provided, so the description must fully convey behavioral traits. It states the action (execute a blocked tool) but gives no details about side effects, reversibility, permissions, token validity, or failure modes. For a tool that performs an execution, this lack of transparency is a notable gap.

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

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

The description is two concise sentences with no redundancy. The first sentence states the purpose; the second gives the usage trigger. Every word earns its place, and it is front-loaded with the core action.

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

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

For a simple one-parameter tool, the description covers purpose and usage condition. However, there is no output schema and the description does not explain what happens after successful execution (e.g., whether it returns the original tool's result) or any caveats like token expiration. This leaves some ambiguity for the agent, though the core behavior is clear.

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

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

The input schema already fully describes the only parameter (token) with a clear description, and schema coverage is 100%. The tool description also references the token, but adds no additional semantic detail beyond what the schema provides. This is a baseline 3 per the rubric.

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

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

The description clearly states the tool's function: 'Execute a previously blocked tool using a confirmation token.' The verb 'execute' and resource 'previously blocked tool' are specific and distinguish it from all sibling tools, none of which mention confirmation or token handling.

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

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

The description says explicitly 'Use this when a tool returns a confirmation_token,' providing a clear condition for when to use it. While it does not mention when not to use it or list alternatives, no sibling tool serves a comparable purpose, so the guidance is sufficient for this context.

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 (write-side effect, idempotent, non-destructive), the description adds important behavioral detail: it explicitly says '不联网/不编译' (no network, no compile), so the agent knows the output is a source skeleton only, not a built extension. It also names the expected generated files.

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

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

The description is dense but front-loaded with the key purpose, followed by the artifact list and constraining behavior. There is no filler. Slightly long, but each clause carries meaning. It could be split into a clearer, structured layout, but it remains 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?

The description is largely sufficient for a scaffolding tool, especially considering a fully schema-documented input. It covers the output scope, generated files, and non-network/non-compile behavior. The force/overwrite semantics are handled by the schema itself. It could add a sentence about choosing between this and the other generation-related tools, but that is a relative weakness rather than a completeness gap.

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

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

The schema has 100% description coverage, including enums, defaults, and parameter-level comments for all 6 parameters. The description itself only reinforces that project_path is the generation root. It does not need to add much more, so a baseline 3 is appropriate.

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

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

The description identifies a specific operation ('scaffold_gdextension') with a specific verb ('生成') and resource (godot-cpp GDExtension project skeleton), and lists concrete artifacts. It clearly differentiates from generic sibling tools such as script or project via the C++/GDExtension scope, though it never names alternatives explicitly.

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

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

The description implies usage: use this tool to scaffold a C++ GDExtension project. It does not explicitly state when to use it versus the sibling script/project tools, nor does it mention exclusions. The 'C++ GDExtension' framing gives a defensible context but leaves comparison to alternatives implicit.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds no further behavioral context such as return format, pagination, or error behavior, which is acceptable given the strong annotation coverage.

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

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

The description is a single, front-loaded sentence that immediately conveys the tool's purpose and lists its operation types. Every word earns its place, and 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 tool with six parameters and four operation variants, the description is minimal but the schema and annotations fill in critical context. It does not explain return values or distinguish action-specific behaviors, which is a gap given there is no output schema, yet the tool's core purpose is clear enough for simple documentation queries.

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

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

Schema description coverage is 100%, so the schema fully documents all six parameters. The description only repeats the action names already present in the enum, adding no additional meaning beyond what the input schema provides, thus meeting the baseline of 3.

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

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

The description clearly states the tool queries Godot class documentation and lists the four supported actions (get_class_info, search_classes, find_method, get_inheritance). This distinguishes it from sibling tools by naming the specific resource and verb, though it does not elaborate on what each action does individually.

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

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

No guidance is provided on when to use this tool versus alternatives, nor how to choose among the four listed actions. The description does not mention any conditions, prerequisites, or competing tools, leaving the agent to infer usage solely from the action names.

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

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

The description goes far beyond the annotations by disclosing concrete behavior: read-only method whitelist, blocklist for dangerous methods, did-you-mean suggestions, fire-and-forget coroutine semantics, snapshot limitations, freeze/unfreeze behavior, push-mode notifications, and how the bridge remains responsive. This gives agents substantial behavioral context that annotations alone would not provide.

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

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

The description is dense and highly structured: it is quickly previewed, then organized by operation category. It packs a lot of information into a single continuous block without much filler. Line breaks or bullet structuring would improve readability, but every sentence/genuinely contributes to explaining the tool's surface.

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

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

Given the tool has 21 parameters, nested objects, and 17 action variants, the description covers all major operation families, important side effects, constraints, and method characteristics. It falls short of fully specifying the output/return contract for every method, since there is no output schema; however, the action names and parameter details are mostly self-evident.

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% and the schema already documents every parameter and its per-action meaning in detail. The description does summarize action-method relationships, but it does not add much semantic value about parameters beyond what the input schema provides.

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

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

The description states it is a '游戏桥接操作' tool and enumerates the major operation families (install/uninstall, query, write, input, wait, playtest, monitoring, signals, UI). This is clear about the resource and scope, but the tool is an umbrella for many subactions rather than a single specific verb, and it does not differentiate itself from sibling tools like scene, screenshot, or runtime.

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

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

It provides clear category labels for when to use each internal subaction: 查询, 写入, 输入, 等待, 监控, etc. However, it never says when to prefer this tool over sibling tools, nor gives explicit 'when not to use' guidance. The context is mainly an internal index, not a decision guide.

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, idempotentHint, and destructiveHint, so safety is covered. The description adds valuable behavioral context beyond the schema: headless mode returns scene=null, project_path fallback behavior, and performance only being valid via bridge. These disclose important edge cases and parameter-dependent behavior, which is more than the minimal date-range scoping in the calibration example. However, it stops short of describing the complete return structure or potential side effects (though read-only makes that less critical).

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

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

The description is two sentences: the first states the main purpose and lists contents; the second adds a specific caveat about headless mode. There is zero padding, and every word contributes to understanding. This is exemplary conciseness.

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

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

There is no output schema, so the description must carry the burden of explaining what the tool returns. It lists the major categories (mode, project, connection, scene snapshot, stats, tool groups, workflows, rules, performance) and notes the headless edge case. This is sufficient for an agent to know what to expect, though it does not provide detailed structure or nested field information. Given the tool's complexity, this is a solid overview but not exhaustive.

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% for all three parameters, so the schema already fully explains each parameter's meaning and behavior. The description does not add new parameter semantics beyond what is in the schema; it only reiterates the headless and bridge nuances already present in the schema descriptions. Baseline 3 is appropriate.

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

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

The description clearly states the tool returns a comprehensive session panorama, listing specific components (mode, project, connection, scene snapshot, stats, tool groups, workflows, rules, performance). This is a specific verb+resource that distinguishes it from sibling tools like godot_list_instances or godot_select_instance, which have more targeted purposes.

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

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

The phrase '减少反复探路' (reduce repeated exploration) implies using this tool to get an overview before diving into more specific operations. This provides clear context, though it does not explicitly name alternatives or state when not to use it. No exclusions are given, but the context is sufficient.

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

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

Annotations already provide readOnlyHint, idempotentHint, and non-destructive traits. The description adds further behavioral context beyond that by explaining that the tool returns complete documentation and action lists, and that it can suggest close tool names for misspellings. No hidden or surprising behavior is apparent.

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 functional and direct, but it repeats the entire 46-item enum that already exists in the schema. While the list makes the scope obvious, it adds length without adding value for an agent that already has schema access. Structurally it is readable but somewhat redundant.

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

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

For a one-parameter read-only help tool with full enum coverage in the schema, the description is largely complete. It explains the purpose, expected input, what information will be returned, and one useful edge behavior. Lacking an output schema is negligible here because the output is itself documentation for other tools.

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

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

The parameter schema already fully defines tool_name with type, description, and an enum of all 46 allowed values. The description adds only a brief restatement of '传 tool_name 获取该工具的详细用法、参数、action 列表', which is useful but does not meaningfully extend per-parameter semantics beyond the schema.

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

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

The description clearly identifies the action and resource: '获取完整文档' for any tool, and lists accepted tool names. It is not a tautology and is informative enough for an agent to understand what help does. It does not explicitly distinguish itself from the similarly naming sibling 'docs', so it falls just short of full sibling differentiation.

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

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

The description explicitly tells the agent to pass tool_name and states what will be returned: detailed usage, parameters, and action list. It also notes automatic spelling correction. It does not provide when-not-to-use or alternate tool comparisons, but for a meta help tool the usage context is clear and actionable.

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

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

Beyond the annotations (all false), the description discloses meaningful behavioral traits: the two-stage retrieval pipeline, the return of source/path and relevance score, and the non-error handling of missing libraries. It does not directly contradict the annotations, though the readOnlyHint=false could be seen as inconsistent with the read-only nature implied, but the description never claims any write behavior.

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

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

The description is a single dense sentence containing all essential information without fluff. It is reasonably structured with a colon and semicolon, making it readable despite the density. No word is wasted, though it could be split into clearer sentences for improved scannability.

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

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

Given there is no output schema, the description adequately explains the return format (source/path and score) and error handling for missing libraries. It also describes the fallback algorithm. Combined with the schema, it covers the essential aspects for a search tool, though it does not mention pagination or empty-result behavior, which are minor gaps.

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

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

The input schema has full coverage for all three parameters (query, limit, libraries) with descriptions. The tool description does not add additional parameter-level semantics beyond what the schema already provides, so the baseline of 3 is appropriate.

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

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

The description clearly specifies the action (search/retrieve), the target resource (SKILL.md from local knowledge base), and the method (two-level retrieval with high-precision then full-text fallback). This distinguishes it from sibling tools focused on other domains and leaves no ambiguity about what the tool does.

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

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

The description provides clear context: it is used to search for skill definitions by keyword, with a documented fallback strategy. It also explains behavior for missing libraries, guiding the agent on what to expect. However, it does not explicitly name alternatives or describe when not to use this tool, so it stops short of full guidance.

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

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

Adds valuable context beyond annotations: all operations are runtime-only and non-persistent. However, it does not disclose potential side effects of specific actions like write/save/load, or any authorization requirements, so transparency is moderate.

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 reasonably compact, but the enumeration of action names duplicates the schema enum. The grouping and runtime note add value, making it efficient overall.

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 (12 parameters, 11 actions) and lack of output schema, the description provides only high-level context and runtime behavior. It doesn't explain differences between save/load and shader_save_file, nor return formats, leaving some gaps.

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

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

Schema already describes all parameters with 100% coverage, so the description adds limited param-specific meaning. It groups actions into read/write/shader categories, helping interpret the 'action' parameter, but does not clarify individual parameters further.

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

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

The description clearly identifies the tool as managing material and shader operations and lists action categories, distinguishing it from sibling tools focused on other domains (e.g., scene, script, physics). However, it lacks a single precise verb like 'manage' or 'manipulate', instead relying on a listing of actions.

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

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

Explicitly states operations are runtime-only and affect only the current execution context, and advises editing the .tscn file for persistence. This provides clear when-to-use and when-not-to-use guidance, though it does not reference sibling tools as alternatives.

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

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

Annotations indicate readOnlyHint=false, idempotentHint=true, and destructiveHint=false. The description adds the crucial behavioral trait that operations are runtime-only and non-persistent, which is not fully captured by the annotations. It doesn't contradict annotations; it reinforces the non-destructive, session-scoped nature.

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

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

The second sentence is a verbatim repeat of the first: '运行时操作，仅影响当前执行上下文。如需持久化，请编辑 .tscn 文件。' This duplication is unnecessary and wastes space. While the description is short, the redundancy means not every sentence earns its place.

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

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

Despite having 22 parameters and five action types, the schema provides thorough parameter documentation, and the description adds high-level runtime/persistence context. It lacks a mention of return values or prerequisites, but given the schema's richness, the description is sufficiently complete for a well-structured tool.

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

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

Schema coverage is 100%, so the baseline is 3. The description's generic phrases like '设置发射/处理参数' add no additional meaning beyond the schema's detailed descriptions, which already document parameter relationships (e.g., emission_box_extents only for box shape).

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

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

The description explicitly states multiple specific actions: creating GPUParticles2D/3D nodes, setting emission/process parameters, loading presets, and setting materials. This clearly identifies the resource domain and distinguishes the tool from broader scene or material manipulation 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 says '运行时操作，仅影响当前执行上下文' (runtime operation, only affects current execution context) and directs users to edit .tscn files for persistence. This provides clear guidance on when to use the tool vs. persistent scene edits, though it doesn't explicitly name an alternative particle-specific tool.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds valuable context by clarifying that operations affect only the current execution context and that no persistent changes are made, reinforcing the read-only nature without 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 concise and well-structured, listing actions with brief explanations and ending with a crucial limitation. Each sentence contributes useful information without redundancy, making it easy for an agent to parse quickly.

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

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

The description adequately covers all actions and the types of data collected (FPS, memory, draw calls, p99 percentile, trends, etc.) for a tool with several parameters and no output schema. It could elaborate on the return format of get_data, but the current level is sufficient for selecting and invoking the tool correctly.

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

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

Schema description coverage is 100%, with each parameter thoroughly documented including enums and defaults. The description's mention of multi-dimensional sampling and frame-level data aligns with the schema but does not add significant extra meaning, so the baseline score of 3 is appropriate.

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

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

The description clearly identifies the tool as a '性能分析工具' (performance analysis tool) and enumerates specific actions (snapshot, start/stop, get_data, get_active_processes, get_signal_connections) with explicit purposes. This distinguishes it from sibling tools by focusing on runtime profiling and scene introspection.

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

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

The description states that operations are runtime-only and affect only the current execution context, explicitly noting that persistence requires editing .tscn files. This provides a clear when-not-to-use condition, though it does not explicitly name alternative tools for persistent changes.

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

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

annotations 提供 readOnlyHint=false、idempotentHint=false、destructiveHint=false，信号非常弱，描述承担了行为透明化的主要责任。描述虽提到创建项目、设置项目规则等副操作，但未透露 write_config 的写操作，也未说明 setup_project_rules/create_project 可能创建文件（包含 hooks、AGENTS.md、CLAUDE.md 等副作用）。当前描述未与 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?

描述以一句紧凑的动词列表呈现，没有无关冗余，做到了简洁。但对一个拥有 9 个 action 和 23 个参数的复杂工具来说，单行列表虽简单但无法承载足够的信息，缺少数层化/分点式结构。

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?

工具复杂度高（9 个 action、23 个参数、嵌套对象），且没有输出 schema，因此描述需要尽可能说明操作和边界，但它只列出部分操作，遗漏 write_config、list_templates、apply_template。没有提及返回格式、副作用或与兄弟工具的取舍关系，整体不够完整。

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

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

input schema 对全部 23 个参数都有中文描述，覆盖率为 100%，包括默认值、枚举、示例和特定 action 归属（如 write_config）。因此描述本身无需再重复参数语义；基线 3 合理。描述没有在 schema 之外增加参数含义，但 schema 已足够充分。

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

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

The description uses specific verb+resource pairs（搜索、获取、列出、读取、创建、设置，均指向 Godot 项目或项目内容），使代理能够识别这是项目级工具。但它只描述了 6 种动作，遗漏了 action 枚举中的 write_config、list_templates、apply_template，因此区分能力不完全覆盖所有功能。

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?

描述没有说明何时使用该工具而不是使用诸如 scene、script、game、runtime 等兄弟工具。没有提供“不使用此工具”的排除条件或指向替代工具的提示，使用时机只能从项目相关关键词中隐含推断。

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 all-false annotations, the description discloses meaningful side effects: it auto-installs the bridge, runs the game, executes state-mutating steps (set/call/watch/monitor), and writes report files to ~/.godot-mcp/qa-reports/. It also notes the call-method whitelist (GODOT_MCP_BRIDGE_EXTRA_METHODS) and the RCE-avoidance design of step_until. Missing an explicit overview of what the sync run returns, 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?

The description is front-loaded with the core purpose and then methodically enumerates step types, assertion guidance, async mode, and report location. It is dense but stays on-topic; the single run-on enumeration of step types is the only minor structural weakness.

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 9 parameters, nested objects, multiple actions, and no output schema, the description covers the orchestration flow well, but it does not say what a sync 'run' returns beyond the existence of report artifacts, nor the result shapes of status/report/diff. With no output schema to fill that gap, this is a noticeable completeness deficiency.

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 parameters are already fully documented and the baseline for this dimension is 3. The description adds only a high-level step-type list and pointers to 'schema 字段 description' rather than new semantic value beyond what the schema already says.

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 (编排/orchestrate) and resource (QA test suites), and lays out a clear end-to-end pipeline: spec → bridge install → run game → step execution → report + regression diff. This makes it unmistakably distinguishable from sibling tools like validation or screenshot.

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

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

The description provides real operational context: async background execution managed via status/cancel, and an implicit hint that large suites should go through spec_path rather than inline spec. However, it never explicitly states when to choose this tool over alternatives (e.g., 'use this when you need automated multi-step game testing, not one-off assertions'), leaving usage as largely implied.

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 are all false, so the description carries the full burden of behavioral disclosure. It merely lists actions in imperative form and does not disclose that run_project spawns a process, stop_project terminates it, or record_save writes a JSON file. The schema parameter hints capture some of this later on, but the tool-level description adds very little behavioral transparency.

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

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

The description is a single front-loaded sentence and is easy to skim. It is concise without padding, but the brevity comes at the cost of omitting the recording-related actions and overall dispatch nature of the tool, so it loses one point.

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

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

This is a 12-parameter dispatcher with 11 possible actions, no output schema, and no description of the return behavior or the overall orchestration pattern. The description excludes six of the action enum values entirely and does not explain how wait_for_bridge, timeout, and autostart interact. A tool can be used in a variety of configurations here, and the description is too incomplete to fully support an agent.

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

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

Schema description coverage is 100% and each parameter is well explained with enum values, defaults, and practical notes such as timeout edge cases and the GUT -gquit compatibility issue. The description text contributes no additional parameter explanation beyond what the schema already provides, so the baseline score of 3 is appropriate.

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

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

The description lists specific verbs tied to a concrete resource: launching the editor, running/stopping the project, fetching debug output, running tests, and getting the Godot version. This makes the main intent clear. It does not distinguish itself from siblings or mention the recording actions, which keeps it from a 5.

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

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

There is no guidance about when to use this tool versus closely related siblings such as project, game, script, or runtime_assert. The description only enumerates capabilities and gives no exclusion criteria or conditions that would help an agent route between alternatives.

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

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

注解已声明 readOnlyHint=true、idempotentHint=true、destructiveHint=false，描述有需要补充的只是运行依赖和前置条件，该描述确实补充了 game-bridge、安装步骤和游戏运行要求。这些信息对调用时机和准确使用有价值，且没有注解矛盾。

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?

描述紧凑，两句话即完成：先给功能摘要，再给调用时机和前置条件，没有冗余或重复 schema 内容。每句话的信息密度都足够，结构便于 agent 快速理解。

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?

该工具复杂度中等偏高：5 种 action、12 个参数、嵌套对象且无输出 schema。描述已覆盖调用范围、路径边界和依赖前提，sctype+annotations 也清晰；唯一明显缺口是未说明断言失败时的返回形式或行为，但整体仍足以支持 agent 正确发起调用。

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

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

信号显示 schema 参数描述覆盖率为 100%，12 个参数已包含较充分的字段级说明，包括 action 枚举、screenshot_diff 的 threshold/max_diff_ratio 语义等。描述对参数增加的意义不大，因此按高覆盖率基线给 3 分。

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

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

描述首句即明确‘运行时断言’这一动作，并列举可验证的各类对象：节点状态、场景结构、屏幕文本、性能、截图对比。它同时说明该工具的运行场景是‘运行中的游戏’，并能与 workflow.dev_loop、validation、screenshot 等同级工具区分开。

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?

明确说明‘agent 可任意时刻调用，不必走 workflow.dev_loop’，并给出硬前置条件：需先 game_bridge_install 且游戏运行中。这些信息足够让 agent 判断何时使用该工具；但未明确说明何时不应使用或与 validation、qa 等工具的取舍边界，稍有缺失。

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 flag destructiveHint=true, but the description does not go beyond the bare list of action names, so it adds no extra behavioral context. It does not explain which operations persist to disk, what effect commit has, or that some actions remove or detach nodes — the agent is left to infer the destructive nature from action names.

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

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

The description is very compact and front-loaded with the 'scene operations' heading, then a categorized enumeration of actions. It is scannable and clutter-free, though the use of Chinese punctuation to chain groups makes it a little dense, and omitting some schema actions means the listing is not fully aligned with the enum.

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 dispatcher tool with 30 parameters, a 19-value action enum, nested objects, and no output schema, this description is far from complete. It does not cover all actions in the enum and does not explain the purpose or return/behavior semantics that would let an agent confidently use this tool in high-consequence scene modification scenarios.

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

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

Schema description coverage is 100%, so the baseline is 3; the schema already documents per-parameter meanings and per-action notes. The tool description itself does not add semantic value for parameters — it only groups action names, which the schema enum already covers.

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

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

The description starts with '场景操作' (scene operations), making it clear this is the scene-operation dispatcher, and then groups the supported actions into categories such as read/create, nodes, save/resources, query, and instances. It is not a mere tautology because it enumerates meaningful sub-operations, though it omits some schema enum actions like open_scene, merge_scene, health_check, create_3d_node, and commit.

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

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

The description provides category labels, which hint at related actions, but it never says when to choose one action over another or when to prefer a sibling tool. Since the tool is an action dispatcher with more than a dozen mutually exclusive enum values, this is a significant guidance gap.

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, idempotentHint, and destructiveHint, which covers the safety profile. The description adds useful behavioral context by labeling headless capture as 'experimental' and explicitly stating that analyze returns image data rather than text. However, it does not qualify that vision_route can make the tool return a plain-text description instead of image content, creating a slight gap in the blanket 'NOT a text description' claim.

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 text is short, front-loaded with the core purpose, and avoids redundant restatement of schema fields. That said, the conciseness is achieved in part by omitting the 'diff' action and the vision_route exception, so the structure is economical but not fully representative of the tool's capabilities.

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

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

This is a complex tool with 22 parameters and three distinct actions, yet the description only discusses two of them and says nothing about diff. There is no output schema, so the description is a lower source of truth for what each mode returns or requires. The missing diff mode and the unqualified analyze-vs-vision_route statement leave the description incomplete for an agent serving the full schema.

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

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

The input schema has 100% parameter description coverage, so the schema already documents all fields. The description itself adds minimal parameter-level detail beyond naming 'capture' and 'analyze', and does not help understand the 'diff' parameters or the relationship between vision_route and analyze. With complete schema coverage, the baseline of 3 is appropriate.

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

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

The description identifies a specific resource ('Godot scene screenshot') and provides distinct verbs for capture ('capture') and analyze ('return the image as MCP image content'). However, the action enum includes a third mode, 'diff', which the description never mentions, so an agent cannot tell from the description that pixel-level image comparison is in scope. Overall clear but incomplete on the full purpose.

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

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

The description gives brief per-action meanings for 'capture' and 'analyze', but provides no guidance on when to use this tool versus siblings or when to choose the 'diff' action. It also does not specify conditions like needing a client vision capability or a text-output alternative, beyond a single caution that analyze returns image data, not a text description.

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?

Exposes significant behavioral traits beyond the false-boolean annotations: the sandbox is only protection against accidents, not against untrusted input; write_script/edit_script enter the same threat surface as execute_gdscript via pre-write scanning; the dangerous-pattern list is deliberately hidden to prevent sandbox-boundary probing. This gives agents the true security model and the reason for information withholding. Misses some specific write-behavior details (output/return behavior, confirmation flow), 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?

The description is dense and front-loaded: the action list appears in the first few words, and every sentence carries meaningful security or usage content. It loses a point for being one long flowing block — the two important caveats are embedded mid-sentence, and explicit line breaks or bullets would improve agent scanning.

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 21 parameters, 7 actions, nested objects with no output schema, the description supplies the high-value operational context (security threat model, sandbox boundaries, execute best practices). The remaining gaps are noticeable but not blocking: no statement of return/output behavior, and no mention of whether destructive actions need additional confirmation or iterate (e.g., project_replace write visibility).

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 every parameter is already documented in the input schema. The description adds essentially nothing beyond the schema: it references edit_script's line-number/search_and_replace and project_replace's bulk replacement, which the schema already captures in parameter descriptions. Baseline 3 is appropriate.

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

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

Description gives 'script operations' as the domain and enumerates all seven actions with their verb categories: read/write (read_script, write_script), edit (edit_script), execute (execute_gdscript), test (generate_test, create_test_scene), bulk replace (project_replace). This clearly distinguishes the internal actions, though it stays a dispatcher-level description and does not differentiate from sibling tools like 'cpp' explicitly.

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 routing guidance for every action family, and goes further: it says when NOT to trust execute_gdscript (untrusted input), when to use ALLOW_EXECUTE_GDSCRIPT=false, and recommends a step-by-step 'execute-verify-iterate' pattern for complex logic. Lacks explicit comparison to sibling tools, so it earns a 4 rather than a 5.

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

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

The description adds behavioral context beyond annotations by stating it only affects the current execution context and restricting emit parameters to basic types. While annotations already indicate no read-only or destructive behavior, the description clarifies the non-persistent nature, which is valuable for an agent.

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

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

The description is compact and well-structured, listing actions clearly and adding a single guiding note about persistence. Every sentence serves a purpose without unnecessary elaboration.

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 10 parameters but no output schema, the description competently covers the tool's behavior and constraints. It could be richer (e.g., explaining flags or node_path usage), but the schema fills most gaps and the description provides a solid high-level overview.

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

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

The input schema provides 100% parameter descriptions, including action-specific details like 'emit: 信号参数（仅 string/number/bool/null）'. The description largely recaps the schema without adding new parameter semantics, so the baseline of 3 is appropriate.

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

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

The description clearly identifies the tool as '信号操作' (signal operations) and enumerates the four specific actions (connect/disconnect/emit/list). It distinguishes itself from persistent .tscn editing by noting it only affects the current runtime execution context, setting it apart from sibling tools.

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

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

It explicitly states '如需持久化，请编辑 .tscn 文件' (for persistence, edit .tscn file), providing a clear when-not-to-use and a specific alternative. The '运行时操作' (runtime operation) phrase signals the appropriate context for use.

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

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

Annotations indicate the tool is not read-only, not idempotent, and not destructive. The description adds context like 'headless run' and 'import resources', which implies side effects, but it does not disclose what exactly gets modified or any other behavioral traits such as file writes or potential conflicts. No contradiction with annotations.

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

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

The description is a single, compact sentence that front-loads capabilities and clearly distinguishes one-click versus individual actions. No filler or redundant content.

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

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

The tool has 12 distinct actions and 18 parameters, but the description only mentions a subset (validation, error analysis, import). It does not cover actions like 'assert', 'stress', 'export_build', or 'verify_delivery'. The schema provides details, but the description lacks a full overview needed for a complex multi-action tool.

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

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

The input schema has 100% description coverage for all 18 parameters, so the baseline is 3. The description does not add any parameter-level detail beyond what the schema already provides, merely summarizing the action types at a high level.

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

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

The description clearly states multiple specific actions (run validation, analyze errors, validate project/scripts, import resources) with a clear resource scope. However, it does not explicitly differentiate from sibling tools like 'project' or 'script' that might overlap in validation tasks.

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

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

The description implies usage contexts such as 'one-click headless run + error analysis' or 'on-demand individual checks', giving some guidance. But it does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites.

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