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

Given no annotations, the description should disclose behavioral traits. It mentions runtime attachment, optional socketing and transforms, but omits side effects (e.g., does it overwrite? fail conditions?), permission needs, or return behavior. Adequate but not thorough.

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?

Single sentence, 25 words, front-loaded with the core purpose. Every word is necessary; no redundancy.

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

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

With 6 parameters, a nested object, and no output schema or annotations, the description covers the main action and optional features but lacks details on defaults (e.g., auto-naming), failure modes, and behavior of attach_to and socket parameters. Adequate but incomplete for a mutation 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 description adds minimal new meaning beyond the schema. The phrase 'optionally socketed and transformed relative to a parent component' corresponds to socket and relative_transform, but no deeper semantics are provided. 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 action (attach), the resource (component to actor), the context (runtime, optionally socketed and transformed), and is distinct from all sibling tools, which focus on inspection, deletion, or bulk operations.

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

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

The description implies the tool is for adding components at runtime with optional socketing and transforms, but does not explicitly state when not to use it or suggest alternatives. However, the narrow purpose and lack of similar sibling tools make the guidance clear enough.

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

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

No annotations are provided, so the description carries the full burden. It discloses the injected boilerplate and the output-capture limitation (ExecuteFile mode does not return stdout), which are key behavioral details. However, it does not cover error handling, required permissions, or side effects, leaving some gaps in 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?

Two sentences, no wasted words. The first sentence states the core purpose and available variables, the second provides critical caveat and workaround. Front-loaded with essential information, achieving high 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?

Given the tool's complexity (wrapper with injected boilerplate), the description adequately covers the purpose, injected variables, and output limitation. No output schema exists, but the caveat points to a workaround (`unreal.log marker + get_log_lines`). Missing some behavioral details (errors, permissions), but overall complete for the tool's scope.

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

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

Schema coverage is 100% with one parameter `code`, so baseline is 3. The description adds significant value by explaining that the injected boilerplate makes `selection` and `selected_assets` available directly, which the schema alone does not convey. This enhances the agent's understanding of how to use the parameter effectively.

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

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

The description clearly states it runs user Python with the editor's current selection pre-bound, naming the variables `selection` and `selected_assets`. It distinguishes itself from the sibling `execute_unreal_python` by explicitly calling itself a convenience wrapper that injects lookup boilerplate, making the purpose specific and unambiguous.

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

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

The description implies usage when the selection context is needed ('convenience wrapper'), but does not explicitly state when to use this vs. alternatives like `execute_unreal_python`. It mentions the same output-capture caveat, linking to a sibling tool, but lacks explicit when-to-use or when-not-to 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?

Despite no annotations, the description discloses its read-only nature and that it composes two operations bridge-side. This adds valuable context beyond the schema about its scope and side-effect-free 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?

Two concise sentences with no wasted words. The first sentence states the core action, the second adds critical usage guidance. Every part earns its place.

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

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

With no output schema, the description explains the status buckets and hints at the output structure via the compile_failures_only parameter. It is sufficient for a simple enumeration tool, though it could explicitly mention the output format.

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% with clear descriptions for both parameters. The description reinforces the path_under parameter but adds no new meaning beyond the schema, meeting the baseline expectation.

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 ('Enumerate') and resource ('Blueprints under a content path') with clear output state buckets. It distinguishes itself from siblings by noting it composes find_assets + inspect_blueprint and is a read-only audit.

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 it is read-only and no recompile is triggered, and suggests pairing with bulk_compile_blueprints for fixing. This gives clear guidance on when and how to use it, though it doesn't list alternative tools for other scenarios.

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

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

With no annotations, the description should disclose side effects and implications. It only states the basic action without explaining what 'wires to the live actor' entails, required permissions, or failure cases. Insufficient for a mutation tool.

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

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

The description is a single sentence that front-loads the core action. It is concise with no unnecessary words.

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

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

While the tool has low complexity (2 required params, no nested objects), the description omits contextual details like return behavior or error conditions. Adequate but not comprehensive for an action that modifies assets.

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 parameter descriptions already provide meaning. The tool description adds no extra semantic value beyond what's in the schema, meeting baseline expectations.

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

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

The description clearly states the action ('add'), the resource ('level actor as a possessable binding to a Level Sequence'), and what it accomplishes ('creates the binding GUID and wires it to the live actor'). This distinguishes it from sibling tools like spawn_actor or add_component.

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

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

No guidance on when to use this tool vs alternatives, no prerequisites or exclusions. For a tool that modifies sequences, explicit context about preconditions (e.g., sequence must exist, actor must be in level) is missing.

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

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

With no annotations, the description carries full burden. It discloses return structure ('per-path success/failure plus aggregate counts') and error handling behavior ('continue_on_error' stops at first failure). It does not cover potential side effects, but compilation is generally non-destructive.

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 long, front-loaded with the core purpose, and contains no redundant information. Every sentence adds value.

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

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

Given no output schema, the description's mention of return shape and error handling is helpful. It covers key behavioral aspects, though it omits edge cases like path validation or skip-if-up-to-date. Overall complete for the tool's simplicity.

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

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

Schema description coverage is 100%, so baseline is 3. The description summarizes the parameter shape ('paths list + continue_on_error') but does not add meaning beyond what the schema already provides.

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

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

The description clearly states 'Recompile multiple Blueprints in one MCP call,' specifying the verb and resource. It distinguishes itself from the single-compile sibling 'compile_blueprint' and aligns with the bulk_*_assets family.

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 notes it is 'Useful after batch-mutating BPs via execute_unreal_python or other tooling,' providing context. Although it does not explicitly name alternatives, mentioning the bulk_*_assets family and composing compile_blueprint implies when to use this tool over single compilation.

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?

Without annotations, the description carries full burden. It honestly discloses the destructive nature (deletion), partial success handling, and the synthetic bridge-side nature. It does not detail the exact result structure, but the return of per-path results and aggregate counts is mentioned.

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

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

Two sentences, front-loaded with essential purpose, then behavioral detail. Every sentence serves a clear purpose without redundancy. Very concise and well-structured.

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

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

No output schema is provided, and the description only vaguely mentions 'per-path results plus aggregate counts' without specifying the structure. Given the tool's complexity (batch operation with potential partial failures), a more detailed result format would improve completeness. However, the behavioral aspects are adequately covered.

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 covers both parameters with 100% description coverage. The description adds value by explaining the continue_on_error flag in context of partial success ('partial success is normal'), which goes beyond the schema's description. It also reiterates path normalization 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 clearly states it deletes multiple assets via a bridge handler, distinguishing it from single delete_asset and other bulk operations. Specific verb 'Delete', resource 'multiple assets', and mechanism 'composing the delete_asset C++ handler bridge-side' make the purpose unmistakable.

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

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

It explains the default behavior (continue on error) and how to change it via continue_on_error=false, providing some usage context. However, it lacks guidance on when to use this tool versus other bulk operations (e.g., bulk_move_assets) or when deletion might be inappropriate (e.g., assets referenced elsewhere).

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

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

With no annotations, the description carries full burden. It explains that the source is preserved and a new copy is created, and that it returns per-entry results plus aggregate counts. This covers key behavioral traits, though details like error handling or side effects are not fully expanded.

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

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

The description is a single, well-structured paragraph that efficiently communicates the core function, key differences, return format, and implementation detail. Every sentence adds value without redundancy.

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

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

Given no output schema, the description explains return format, key behavioral differences from related operations, path constraints, and error handling. It is sufficiently comprehensive for an agent to understand the tool's behavior and usage.

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

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

Input schema has 100% coverage, but the description adds value by explaining that dest_path is a full destination path (not a leaf name) and adding constraints about non-empty strings, no NUL byte, and no '..' segment. This enriches the schema.

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

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

The description clearly states 'Duplicate multiple assets in one call' and distinguishes from siblings like bulk_rename_assets by explaining the difference in path handling. It also notes that it's a synthetic bridge-side handler, making the purpose unambiguous.

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

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

The description contrasts with rename/move by noting that duplicate does not leave a redirector and explains the dest_path vs new_name difference. However, it does not explicitly state when to use this tool over alternatives or provide exclusions. The context is clear but could be more directive.

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?

Describes composition of fix_up_redirectors per folder and explains parameter behaviors (recursive echoed, continue_on_error control), adding value beyond schema.

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

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

Two sentences: one for purpose, one for usage guidance. No wasted words.

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

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

Given no output schema, description sufficiently covers behavior and use cases; missing return value info but acceptable for this tool.

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

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

Adds meaning beyond schema by explaining recursive's purpose for intent capture and continue_on_error's stopping behavior; schema coverage is 100%.

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

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

Clearly states tool resolves UObjectRedirector stubs across multiple folders, distinguishing from sibling fix_up_redirectors which operates on a single folder.

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 advises to use as follow-up to bulk_move_assets/bulk_rename_assets, implying alternative fix_up_redirectors for single folders.

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?

Describes composition of focus_actor and get_viewport_screenshot, details the settle delay behavior (sleeps between calls, not after last), and explains the screenshot_each option. Some minor gaps like error handling, but sufficient given no annotations.

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

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

Two sentences, front-loaded with action, no wasted words. Perfectly 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?

Comprehensive for a bulk tool with simple parameters. Mentions output (screenshots array) but doesn't specify format when no screenshots. Minor gap, but overall adequate.

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

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

Schema coverage is 100%, and description adds meaningful context: max 100 entries for names, default/max for delay_ms, default false for screenshot_each, and clarifies delay timing.

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

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

Clearly states it frames the viewport on each actor in a sequence, optionally capturing screenshots. Distinguishes itself from sibling tools like screenshot_actor by avoiding polling loops.

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 provides a use case ('show me each enemy / spawn / light in turn' walkthroughs) and explains why it's better than using screenshot_actor individually.

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

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

Discloses that partial failures are isolated per result, and returns per-path data plus aggregate counts. Without annotations, this is valuable behavioral context. Could further mention that it is read-only, but the inspection nature implies safety.

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

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

Three well-structured sentences with front-loaded purpose, output summary, and an example use case. Every sentence adds value without redundancy.

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

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

Given the tool's simplicity and no output schema, the description adequately covers purpose, output shape, error behavior, and a typical use case. It could briefly mention the return format structure, but it remains functionally 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?

Input schema has 100% coverage with descriptions for both parameters. The description adds context about 'partial failures isolated per result' relating to continue_on_error, and 'per-path inspection data' relating to paths, but does not significantly augment the schema's explanations.

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 that the tool inspects multiple assets in one call, distinguishing it from the singular inspect_asset sibling. It also mentions the bulk_*_assets family, reinforcing its role as a batch operation.

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

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

The description provides an explicit use case (pipeline audits for textures lacking power-of-two sources), implying batch scenarios. However, it does not explicitly state when not to use it (e.g., for single asset inspection), leaving a small 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?

With no annotations, the description fully carries the burden. It discloses that each move leaves a redirector at the source (UE standard), returns per-path results plus aggregate counts, and defaults to continuing after individual failures with option to stop on first failure. This provides sufficient behavioral context.

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

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

The description is concise (4 sentences), front-loaded with core purpose, and each sentence adds unique value. 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?

Despite lacking annotations and an output schema, the description covers all necessary behavioral details: redirector semantics, error handling strategies, return structure, and relationship to sibling tools. This is comprehensive for a multi-asset move 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?

All parameters have schema descriptions (100% coverage). The description adds value by explaining path rules (same as bulk_delete_assets), that dest_folder applies uniformly, and the detailed behavior of continue_on_error. It also notes the shape similarity to a sibling tool, aiding interoperability.

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

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

The description clearly states the verb 'Move' and resource 'multiple assets', specifies the single destination folder, and distinguishes itself from the sibling 'move_asset' tool. It also notes it mirrors 'bulk_delete_assets' shape, making the purpose unambiguous.

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

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

The description explains when to use this tool (bulk move to one folder) versus alternatives (for per-asset destinations, call move_asset directly). It also mentions the default behavior of continuing on error and how to change it. However, it does not explicitly state prerequisites or when not to use the tool.

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

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

Without annotations, the description discloses key behaviors: each rename leaves a redirector, it is a synthetic bridge-side handler, and it returns per-entry results with aggregate counts. It could also mention error handling behavior (continue_on_error) which is only in the schema.

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

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

The description is four sentences long, providing essential details without unnecessary fluff. It could be slightly more structured, but it remains concise and informative.

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

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

The description covers the tool's purpose, behavior (redirector), result shape, and schema distinction. It is complete enough given no output schema, though it does not detail error partiality which is handled by the schema's continue_on_error parameter.

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 the input schema has 100% coverage with descriptions, the description adds value by interpreting what the renames parameter does (per-entry leaf name) and the redirector side effect, enhancing understanding beyond the schema alone.

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

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

The description clearly states the tool renames multiple assets in one call, specifies it uses a list of {path, new_name} objects, and distinguishes from sibling tools by noting the schema differs from bulk_delete_assets and bulk_move_assets.

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

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

The description explains that each rename leaves a redirector per UE standards and that results mirror the bulk_*_assets convention, providing context. However, it does not explicitly state when to use this tool versus other rename or bulk tools.

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

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

With no annotations, the description carries the transparency burden. It explains the composition (screenshot_actor -> focus_actor + get_viewport_screenshot) and describes the delay_ms behavior (sleeps between actors). It misses potential side effects like viewport changes, but the given details are adequate for understanding the tool's behavior.

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

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

The description is two sentences with no wasted words. The first sentence states the core function, and the second provides context and comparison. It is well-structured and efficient.

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

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

Given no output schema, the description does not mention what the tool returns (e.g., file paths or success status). While it describes the process, the lack of output information leaves the agent uncertain about the result. This is a moderate 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 100%, but the description adds significant value: for 'names', it adds a 50-entry cap and comparison to bulk_focus_actors; for 'delay_ms', it specifies default, max, and the behavioral note about sleeping between actors (not after last). This exceeds what the schema provides.

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

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

The description clearly states the tool frames and screenshots each actor in a sequence, explicitly distinguishing it from the sibling bulk_focus_actors by noting it always captures a PNG. It also explains the composition of screenshot_actor, providing a precise 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 implies usage for thumbnail pipelines needing deterministic centered shots. It compares to bulk_focus_actors, offering some guidance. However, it does not explicitly state when to avoid this tool or suggest alternatives beyond the sibling comparison.

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

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

With no annotations provided, the description carries full burden. It discloses that it composes set_actor_property, mirrors bulk_*_assets shape, each assignment has own triple, and continue_on_error defaults true. Explains per-assignment failure behavior. Lacks details on atomicity or response structure, but adequately transparent.

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

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

Four sentences, well-structured: starts with purpose, then relates to siblings, clarifies what it is NOT, and gives usage context. No unnecessary words; every sentence earns its place.

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

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

Given no output schema and no annotations, the description covers purpose, usage, parameter constraints, and error behavior. Could mention success/failure response format, but overall sufficiently complete for a bulk tool with two parameters.

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 baseline is 3. Description adds significant value: clarifies max 200 entries, each actor/property non-empty, and explains continue_on_error behavior. Adds constraints and context beyond schema.

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

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

The description uses a specific verb-resource combination ('apply many UPROPERTY mutations') and clearly distinguishes itself from set_actor_property and the bulk_*_assets family by explaining the composite nature and per-assignment structure.

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

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

States clear usage context: 'useful after batch-spawning to push initial-state mutations without N round-trips.' Explicitly clarifies it is NOT 'set the same property on N actors' but individual sets. Could mention when to use alternatives, but provides good guidance.

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

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

With no annotations, the description carries full burden. It details the capture-pre-values, apply, and rollback-on-failure process, including the explicit rollback failure list. Missing permission or side-effect details, but adequate.

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 action, three sentences each adding value. Slightly verbose but not excessive; clear structure.

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

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

For a bulk operation with rollback (2 params, no output schema), description covers behavior well but omits return value structure. The mention of rollback failure list implies output, but agency lacks full clarity.

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

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

Schema covers 100% of parameters. Description adds 'Max 50 entries' limit for assignments and 'Default true' for rollback_on_error, plus explains rollback behavior, going beyond schema.

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

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

The description clearly states it sets multiple console variables in one call with atomic rollback, distinguishing it from sibling tools like set_console_variable (single) and get_console_variable (read).

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

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

The description implies when to use this over single-setters by emphasizing bulk operation and rollback pattern. It mirrors editor behavior, giving context, but lacks explicit 'when not to use' or 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?

With no annotations, the description fully covers cooperative cancellation, flag polling, status transition to 'cancelled', and Unreal Engine's lack of forced termination. Also notes idempotency 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?

Four sentences, each with distinct purpose: action, mechanism, limitations, and idempotency. No wasted words, front-loaded with core function.

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 simple single-parameter tool with no output schema, description covers all necessary behavioral aspects, edge cases, and limitations thoroughly.

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% for task_id, and description adds no extra information beyond the schema's description. 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?

Clearly states it cancels a running task cooperatively. The verb 'cancel' and resource 'task' are explicit, and it distinguishes itself from sibling tools like list_tasks or poll_task by describing cancellation behavior.

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

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

Provides explicit guidance on when to use (to cancel running tasks), when not to (workers that don't poll ignore cancellation), and idempotency for unknown/terminal tasks. No alternative tool mentioned, but 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?

With no annotations, the description carries full burden. It reveals that the tool composes inspect_asset bridge-side on both paths and excludes the path field from comparison. This is sufficient disclosure for a read-only diff operation, though it omits details about permissions or side effects, which are minimal for a comparison tool.

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

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

The description is three sentences, each earning its place: first sentence states the core function, second gives use cases, third notes an important exclusion (path field). No redundant or vague language. Information is front-loaded effectively.

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

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

While the description covers purpose, usage, and parameter semantics, it lacks detail on the output format. The tool returns 'fields that differ' but does not describe structure (e.g., key-value pairs, nested vs flat). Given no output schema, this gap could leave the agent unsure how to consume the result. However, for a diff of inspect_asset outputs, the return format is implied by the input schema's field structure, so it is marginally adequate.

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% with descriptions for all three parameters (path_a, path_b, fields). The description adds value beyond the schema by explaining that the path field is excluded from comparison and providing guidance on using the fields parameter to scope the diff to a specific subset. This clarifies behavior not captured in the schema.

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

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

The description clearly states the tool performs a symmetric diff between two assets by comparing their inspect_asset outputs. It uses specific verb+resource ('diff' + 'assets') and distinguishes itself from siblings like inspect_asset by explaining it composes two inspect_asset calls and returns only differing fields.

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 use cases: checking what changed between versions of a blueprint or cross-checking duplicated assets. It implies when to use (for symmetric diff) and excludes path field, but does not explicitly state when not to use or list alternatives, though the sibling set includes inspect_asset which could be an alternative for single asset inspection.

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

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

No annotations are provided, so the description carries the full burden. It indicates the tool performs an explicit recompile and that it should be used when no further mutation is needed. However, it does not disclose whether the recompile is synchronous, what happens on failure, or any logging/error behavior. The behavioral description is adequate but not 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?

Two sentences: first identifies the tool's function with technical precision, second provides usage guidance and a sibling reference. No wasted words, information is front-loaded and easily scannable.

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

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

Given no output schema, no annotations, and only two parameters, the description covers the essential context: what the tool does, when to use it, and a related tool. It could mention return behavior or error handling for completeness, but current coverage is good for a simple recompile 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% with clear descriptions for both parameters (path and skip_save). The description does not add additional semantic meaning beyond what the schema provides. It mentions pairing with edit_widget_tree's compile flag, which is contextual but not parameter-specific. 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?

Explicitly states 'Blueprint recompile' as the core action, with a specific technical reference (FKismetEditorUtilities::CompileBlueprint). Clearly distinguishes from sibling tools like bulk_compile_blueprints or audit_blueprint_compile_status by focusing on a single, explicit recompilation.

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

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

Provides explicit usage context: use when a Blueprint has been mutated externally via execute_unreal_python and needs recompilation without further mutation. Also mentions pairing with edit_widget_tree's compile flag, offering a related alternative. Does not explicitly state when not to use, but the guidance 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?

With no annotations, the description carries full burden. It explains the two pathways, their outputs, and that success is based on exit code. Lacks details on system impact, permissions, or error handling.

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

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

The description is well-structured and front-loaded with the main purpose. It is slightly lengthy but each sentence adds value, covering both pathways and key details.

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

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

Given 8 parameters and no output schema, the description covers the two modes adequately but lacks details on failure modes, error messages, or how to interpret the BuildPlugin output (no .pak generated).

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

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

Schema coverage is 100%, but the description adds useful context beyond schema, such as how mod_name disambiguates .pak files and that output_dir is required for success verification.

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

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

Clearly states the tool compiles a UE mod plugin to a .pak file via two specific methods (BuildMod or BuildPlugin), headless. It distinguishes itself from siblings like compile_blueprint and compile_mod_pak_direct by detailing the two pathways and their outputs.

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 guidance on when to use BuildMod (game Dev Kits) vs BuildPlugin (vanilla UE5), including fallback for installed-build mode. However, it does not explicitly state when not to use this tool or mention 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?

With no annotations, the description fully bears the burden. It explains the tool bypasses RunUAT, runs in seconds, produces a .pak for direct deployment, and requires pre-cooked files. It also labels itself as 'SYNTHETIC bridge-side handler'. While it lacks details on failure modes, it still provides substantial behavioral context.

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

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

The description is concise (about 6 sentences), front-loaded with the core purpose and differentiator. Every sentence adds valuable information without redundancy.

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

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

The description lacks explicit information about the tool's return value or output format. It says 'produces a .pak' but doesn't specify what the tool returns (e.g., success message, path). Given the tool has no output schema, this omission leaves a gap.

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

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

Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal extra meaning beyond the schema, meeting the baseline but not exceeding 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 the tool's purpose: 'Compile a UE5 mod into a .pak by invoking UnrealPak.exe directly'. It also distinguishes it from sibling tool compile_mod_pak, specifying when to use each. This provides excellent clarity.

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 advises when to use this tool: 'Use when the Dev Kit's RunUAT BuildMod is broken' due to a specific bug. It also contrasts with compile_mod_pak. This offers precise 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?

Discloses that changes are persisted, triggers UE's PreEditChange/PostEditChange flow, and rebuilds the GPU resource. This goes beyond the basic mutation fact, highlighting resource-intensive side effects. Since no annotations are provided, these behavioral details are essential and well-covered.

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

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

Two sentences, no redundancy. The first sentence defines purpose and scope, the second adds behavioral context. Every word is necessary; there is no fluff.

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

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

For a mutation tool with no output schema and 6 parameters, the description covers purpose, behaviors, and side effects adequately. It does not mention return value (likely success/failure), but that is minor for a mutation tool. Overall complete given the complexity.

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

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

Input schema has 100% description coverage, so the baseline is 3. The description does not add significant meaning beyond the schema, merely confirming that the listed properties are adjustable. No additional parameter constraints or formatting details are provided.

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

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

Clearly states it adjusts SRGB, CompressionSettings, LODGroup, and Filter on an existing UTexture asset, which matches the input schema properties. The verb 'Adjust' and resource 'existing UTexture asset' precisely describe the action, distinguishing it from creation (import_texture) or inspection (inspect_texture) 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?

Implies usage for modifying existing textures (not creating or reading), but does not explicitly state when to use versus alternatives like import_texture or inspect_texture. No mention of prerequisites, when not to use, or specific context beyond asset existence.

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

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

With no annotations, the description fully discloses behavior: spawning temporary actors, capture pipeline, cleanup of temp assets. It details the entire process, ensuring the agent understands side effects and safety.

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

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

The description is well-structured with purpose, pipeline steps, and cleanup. It is detailed but not overly verbose. Slight improvement could be made by front-loading the most critical info, but overall effective.

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

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

Given no output schema, the description explains the output (static UTextureCube) and covers all inputs, process, and cleanup. It is comprehensive for the tool's complexity.

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

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

Schema coverage is 100%, but the description adds valuable defaults (e.g., dest_path defaults to source folder, dest_name to source basename plus _Cube), explains cube_size range, and lists compression options. This goes 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 explicitly states the tool converts a longlat-projection HDRI to a UTextureCube for use with SkyLight's SpecifiedCubemap slot. It distinguishes itself from siblings like import_texture and configure_texture by focusing on a specific conversion pipeline.

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 purpose clearly indicates use for SkyLight cubemap setup. It mentions being a 'SYNTHETIC bridge-side handler' but lacks explicit when-not-to-use guidance or alternative tools. The context is clear but could be stronger.

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

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

With no annotations, the description must fully disclose behavior. It states creation and parent setting but omits critical details: whether overwriting existing assets is allowed, error conditions, required permissions, or any side effects. This is insufficient for a potentially destructive operation.

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

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

The description is a single, well-structured sentence that conveys the core action without unnecessary words. It is front-loaded with the key verb and resource.

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

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

Despite being concise, the description lacks completeness for a creation tool. It does not explain default properties, naming conflict handling, or post-creation steps. Given no output schema or annotations, more context is expected.

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% coverage with descriptions for each parameter. The description adds no extra semantic information beyond what is already in the schema, so the baseline score of 3 is appropriate.

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

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

The description clearly states the verb 'Create' and the specific resource 'UMaterialInstanceConstant asset', along with the action of setting its parent. This distinguishes it from other tools on the server, none of which create material instances.

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 the basic purpose but offers no guidance on when to use this tool versus alternatives (e.g., set_mi_parameter for modifying an instance). No when-not-to-use or alternative suggestions are included.

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

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

No annotations are provided, so the description carries full responsibility. It states 'Create' implying a write operation, but does not mention side effects like asset overwriting, permissions, or what happens on name conflicts. The behavioral detail is minimal.

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

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

Two concise sentences, front-loaded with purpose, no extra words. Every sentence adds value.

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

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

With 4 parameters fully described in schema and no output schema, the description provides adequate context for a creation tool but lacks details on success feedback or performance. It is minimally 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 baseline is 3. The description adds slight value by mentioning 'empty MovieScene' and mapping 'display frame rate' and 'playback end-frame' to parameters, but does not significantly enhance understanding beyond the schema.

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

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

The description clearly states it creates a new Level Sequence asset, initializing an empty MovieScene with specific parameters. This distinguishes it from sibling tools like inspect_sequence or sequencer_add_transform_keyframe.

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

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

The description implies usage for creating a new sequence, but lacks explicit guidance on when to use this tool vs alternatives, or exclusions such as overwriting behavior or prerequisites.

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

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

No annotations are provided, so the description carries the full burden. It clearly explains that children are detached (not destroyed) and that the force flag overrides the safety check. However, it does not mention error handling for nonexistent actors or undo 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 three sentences: first establishes purpose and parameter, second clarifies children behavior, third explains force flag. Every sentence adds value with no redundancy, and the key information is front-loaded.

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

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

Given no annotations and no output schema, the description covers core behavior (children handling, force flag) and mentions a specific error ('has_children'). It could be more complete by describing the return value or behavior when the actor name is invalid, but it is largely sufficient for a straightforward deletion 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 covers 100% of parameters, and the description adds value by explaining the force flag's purpose ('overrides the children-attached safety check') and clarifying that 'name' can be a label or FName. This enriches the schema's minimal descriptions.

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

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

The description clearly states the specific action ('remove an actor'), the resource ('actor in the editor world'), and the method ('by name (label or FName)'). It distinguishes itself from sibling tools like 'delete_asset' by targeting actors specifically.

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

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

The description does not explicitly state when to use this tool versus alternatives like 'delete_asset'. While the context implies use for actor deletion, it provides no direct comparison or exclusions.

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

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

With no annotations, the description carries full burden. It discloses permanence, refusal when referenced, and force-delete undo implications. This is substantial, though it could mention permissions or logging.

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

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

Two sentences, front-loaded with action, then condition and warning. No fluff, every sentence adds value.

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

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

Given moderate complexity and no output schema, the description covers key aspects: action, conditional refusal, and permanence warning. Minor ambiguity about undoability for non-force deletions, but overall 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% with descriptions for both parameters. The description adds context about refusal and force, but the schema already defines 'force' as 'delete even if referenced'. The additional value is minimal.

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 deletes an asset, specifying the verb 'delete' and resource 'asset'. It also adds nuance about referenced assets, which distinguishes it from sibling bulk_delete_assets and delete_actor.

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

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

The description implies usage for single asset deletion but does not explicitly contrast with bulk or other sibling tools. It provides context on force usage but no when-not guidance.

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

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

With no annotations, the description discloses key behaviors: source preservation, destination non-existence requirement, and absence of redirector. This is strong but could mention error handling or authorization needs.

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

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

Three concise sentences, each adding distinct value: purpose, key constraints, and behavioral nuance. No redundant or unnecessary words.

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

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

Given two required parameters and no output schema, the description covers essential behavioral aspects. It could mention return value or async nature, but overall sufficient for usage.

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

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

Parameter descriptions in the input schema already provide meaning (source vs. destination paths). The description adds overall context but no per-parameter details beyond the schema, resulting in baseline score.

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 copies an asset, preserves the source, requires a non-existent destination, and creates no redirector. This distinguishes it from siblings like move_asset, rename_asset, and delete_asset.

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

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

The description implies when to use (when a copy is needed, destination new) but does not explicitly list when not to use or mention alternative tools. The differentiation from move_asset (source preserved) and rename_asset (no redirector) is clear.

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

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

With no annotations, the description carries the burden. It states 'Mutate' implying changes, lists ops, and mentions the compile parameter note from schema. However, it does not disclose potential side effects, required permissions, or failure modes, so transparency is adequate but not thorough.

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

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

The description is extremely concise at two sentences, with the first sentence immediately stating the purpose and operations. Every sentence earns its place without any fluff.

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

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

Given the complexity (9 parameters, 3 operations, no output schema), the description lacks crucial context such as what the result of each operation is, error scenarios, or how changes persist. The compile note is only in the schema. Therefore, completeness is poor.

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

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

The schema description coverage is 89%, so the schema already documents most parameters well. The tool description adds the operation enum list but little else beyond what the schema provides. 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 it mutates a widget tree, lists the three operations, and references a specific use case (UE 5.7 EUW WidgetTree population). This effectively distinguishes it from sibling tools like inspect_widget_tree and other non-editing 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 provides the operations but does not explicitly state when to use this tool versus alternatives. It offers a brief note on the compile parameter regarding batching, but lacks broader usage context or exclusions.

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

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

With no annotations provided, the description carries full burden. It details the persistent state mechanism (FPythonCommandEx, Public scope), output-capture caveat (stdout not captured, use unreal.log + get_log_lines), and pairing with reset_python_state. This is thorough behavioral disclosure.

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

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

The description is a single paragraph that covers key points, but includes minor extraneous context (e.g., 'Tier 2 PR #45') and could be slightly more streamlined. However, it is front-loaded with the most critical information (state persistence).

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

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

The tool has no output schema, so the description should explain return values. It does not explicitly state what the tool returns, but it covers the output-capture caveat, pairing, and persistent globals. Given the simplicity (single code parameter), it is mostly 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 has 100% description coverage, so the schema already defines the parameter. The description adds minimal extra context ('persistent globals dict'), but does not enhance parameter understanding beyond stating the execution environment.

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 tool's purpose: executing Python code with state persistence across calls. It explicitly contrasts with sibling execute_unreal_python, which does not persist state, making the distinction unambiguous.

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

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

The description mentions pairing with reset_python_state to reset state, implying when to use that alternative. However, it does not provide explicit when-not-to-use guidelines or potential side effects of persistent state, such as unintended variable collisions.

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

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

With no annotations, the description carries the full burden. It mentions execution on the game thread in the editor world context, which is helpful. However, it does not disclose potential destructive side effects, permission requirements, or that commands may alter the editor state.

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

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

The description is two sentences, highly efficient, and front-loaded with the core action. No redundant information.

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

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

Given the tool's potential complexity and lack of output schema, the description is adequate but incomplete. It covers the basic function and execution context but omits safety warnings and details about return value format.

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 description adds minimal extra meaning. It supplements with command examples but does not explain parameter formats beyond the schema. Baseline is 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 runs a UE console command, provides concrete examples ('stat fps', 'r.ScreenPercentage 50'), and notes the optional output capture. This distinguishes it from siblings like 'set_console_variable' and 'execute_unreal_python', which are more specific.

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

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

The description does not explicitly guide when to use this tool over alternatives. Context from sibling names suggests differentiation, but no direct 'when to use' or 'when not to use' advice 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?

With no annotations provided, the description must fully disclose behavioral traits. It adds only that multi-line scripts are allowed, but omits critical information such as side effects, error handling, execution context, return values, or potential risks of running arbitrary code.

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

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

The description is extremely concise: two sentences, front-loading the verb and resource with no wasted words. Every sentence adds value.

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

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

For a simple one-parameter tool, the description covers the core purpose and an important support detail (multi-line). However, it does not address return values, error states, or clarify behavior relative to sibling tools like exec_python_persistent.

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 the 'code' parameter as 'Python source to execute', but the description adds the valuable detail that multi-line scripts are allowed. With 100% schema coverage, this extra information justifies a score above baseline.

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 that the tool executes arbitrary unreal.* Python code in the editor's embedded interpreter, and labels it as a 'universal escape hatch'. However, it does not explicitly distinguish this tool from similar siblings like exec_python_persistent or run_python_file.

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

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

The description implies usage as a fallback via the phrase 'universal escape hatch', but provides no explicit guidance on when to use this tool versus alternatives, nor any conditions or prerequisites.

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

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

With no annotations, the description explains the matching logic (case-insensitive, path stripping) and notes it composes get_actors_in_level. It implies a read-only operation, though not explicitly stated. The behavioral details are adequate for a non-destructive filter.

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

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

Three concise sentences, each adding essential information. The purpose is front-loaded, and there is no redundancy or extraneous content.

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

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

While parameters are well-covered, the description omits the return type or format of the results. As a filter tool with no output schema, this is a notable gap. The behavior is simple, but completeness suffers from missing output description.

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%, providing a baseline of 3. The description adds value by clarifying that class_name accepts short names or paths, explaining case-insensitivity and path-stripping behavior, which surpasses the schema's description.

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

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

The description clearly states the tool filters actors by class, distinguishes it from get_actors_in_level by specifying it composes that tool and matches class names, and provides concrete use cases like 'find every light'.

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 contrasts with get_actors_in_level, advising against using it to dump all actors. It gives specific scenarios (finding lights/spawn points). However, it doesn't mention other filtering alternatives 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?

No annotations provided, so the description carries the burden. It correctly indicates a read-only query operation and mentions the default limit and max limit. However, it does not discuss error handling, performance, or pagination beyond the limit parameter. For a query tool, this is adequate but not exceptional.

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

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

Two sentences concisely convey purpose, filters, and return format. No filler words or redundant information. Every sentence is essential and front-loaded.

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

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

Given no output schema, the description mentions return fields (name, package_path, class, tags) which is sufficient. It also includes version notes for tag parameters. Missing details like whether results are sorted or paginated, but overall complete for a query 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?

Input schema covers all 6 parameters with 100% description coverage. The description adds value by summarizing the filter categories and mentioning the return fields. This is helpful context but not necessary beyond the schema. Score is baseline 3 for high schema coverage.

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

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

The description clearly states it queries the asset registry by class and optional filters (path, name, tags). It returns structured records with specific fields. This distinguishes it from sibling tools like find_actors_by_class (focuses on actors) and inspect_asset (single asset inspection).

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

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

The description implies use when you need to find assets by class and filters, but lacks explicit guidance on when to use this vs alternatives like find_actors_by_class or find_unused_assets. No when-not or exclusion criteria are mentioned.

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

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

With no annotations, the description carries the full burden. It states the tool performs a prefix-search and returns specific data (names, types, flags), but does not disclose whether the operation is read-only, its performance implications, or any side effects. The implementation detail about C++ handler adds minimal behavioral context.

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

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

The description is two sentences covering purpose and pairing context. The third sentence about the language-shim experiment (PR #46) is extraneous for tool invocation and could be omitted for 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?

Without an output schema, the description adequately explains the return values (names, types, read-only flags). It also provides workflow context by pairing with related tools. However, it lacks mention of error handling or performance limits beyond the schema's 'limit' parameter.

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

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

Input schema has 100% description coverage for both parameters (prefix, limit). The description adds no additional meaning beyond what the schema already provides, so 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 states it performs a prefix-search on the IConsoleManager registry and returns CVar names, types, and read-only flags. It distinguishes itself from sibling tools like get_console_variable and set_console_variable by focusing on discovery via prefix matching.

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 pairs this tool with get_console_variable and set_console_variable for discovery workflows, indicating when it should be used. However, it does not mention when not to use it or contrast with other sibling tools like bulk_set_console_variables.

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, but description details return behavior: returns first `limit` unused assets and a `truncated` flag, and explains scan halting logic. Missing explicit read-only statement but clearly non-destructive.

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

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

Three concise sentences: purpose, composition+use case, return behavior. No wasted words.

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

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

Covers main behavior and output structure (unused assets + truncated flag) despite no output schema. Could clarify exact output format but acceptable given tool simplicity.

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

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

All parameters have schema descriptions (100% coverage). Description adds significant value: default '/Game', recursive hint for path_under; default 100, max 10000, and scan halting behavior for limit.

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

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

The description clearly states it enumerates assets and reports those with zero referencers, distinguishing it from siblings like find_assets and inspect_asset via composition hint.

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 'Useful for content cleanup audits before shipping.' Does not detail when not to use, but context implies alternatives for simple listing or inspection.

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

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

With no annotations, the description carries full burden. It discloses that the tool updates consumers and deletes stubs, indicating destructive behavior. However, it does not mention reversibility, partial failures, or safety of re-running.

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

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

Three sentences with zero fluff. First sentence states action, second specifies context, third relates to editor. Information is front-loaded.

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

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

Given no output schema and a single parameter, the description adequately explains the tool's purpose, usage, and parameter rationale. Missing details like error handling or idempotency, but sufficient for a simple 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%, but the description adds context: 'Required to avoid accidentally rewriting an entire project.' This provides safety rationale beyond the schema's parameter description.

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

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

The description clearly states the tool's action: cascade-update consumers of UObjectRedirector assets and delete stubs. It distinguishes itself from siblings like bulk_fix_redirectors by specifying it operates under a folder. The verb 'fix_up' and resource 'redirectors' are explicit.

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 when to use: after move_asset/rename_asset workflows. It also mirrors editor functionality. However, it does not provide explicit when-not-to-use or alternative tools.

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

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

With no annotations, the description carries full burden. It discloses selection and viewport framing but omits side effects (e.g., changing selection state), prerequisites, or error handling for non-existent actors.

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?

Single sentence, 12 words, front-loaded with the action. No wasted words.

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

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

For a simple tool with one parameter and no output schema, the description covers the basic action but lacks completeness regarding error states (e.g., actor not found) and behavioral nuances.

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

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

Schema description coverage is 0%, but the description adds that the 'name' parameter accepts a label or unique name, which provides useful clarification. However, no format or examples are given.

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

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

The description clearly states the verb 'select' and 'frame the editor viewport' on an actor, distinguishing it from sibling tools like 'bulk_focus_actors' (bulk operation) and 'delete_actor' (different 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?

No guidance on when to use this tool versus alternatives such as 'find_actors_by_class' or 'get_selected_actors'. The context is implied but not explicitly stated.

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

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

Without annotations, the description carries the full burden. It correctly states it returns data for all actors (no mention of destructive behavior) but does not disclose potential performance impact of returning many actors or that it reads from the active editor world. Adequate but not richly transparent.

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

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

Two sentences front-load main purpose and optional filter. No redundant words. Perfectly concise and well-structured.

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

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

For a simple tool with one optional param and no output schema, the description is sufficient. It covers scope, return fields, and filter. Could be enhanced with guidance on when to use this vs siblings, but overall complete enough.

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

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

Schema coverage is 100% with one parameter described. The description adds 'Optional' but does not add meaning beyond the schema's 'Substring filter on actor label'. 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 it returns name/class/transform for every actor in the active editor world, with an optional name filter. This distinguishes it from siblings like 'find_actors_by_class' (returns references by class) and 'get_selected_actors' (only selected).

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

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

The description implies usage for listing all actors with optional name filter but does not explicitly mention when to use this tool over alternatives like 'find_actors_by_class' for class-based search or 'get_selected_actors' for working with selections. No when-not-to-use guidance.

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

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

No annotations are provided, so the description carries the full burden. It discloses the synthetic nature composing two other tools and returns a specific format, but does not mention safety, permissions, or side effects (though read-only is implied).

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

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

Two concise sentences: first clearly states purpose, second adds implementation detail. No wasted words.

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

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

For a zero-parameter, no-output-schema tool, the description fully covers purpose, return format, and implementation context. 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?

Input schema has zero parameters with 100% coverage, so description needs no parameter explanation. Baseline 4 for zero-param tools.

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

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

The description clearly states the action 'Read' and the resource 'level-editor viewport camera transform', distinguishing it from siblings like 'set_camera_transform'.

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

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

The description implies usage for reading camera transform but does not explicitly state when to use this versus alternatives like taking screenshots or setting transforms. No exclusions or prerequisites mentioned.

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 provided, so description carries full burden. It details the return data (four representations, type, readonly flag, last-setter) and implies non-destructive read. Could explicitly state side-effect-free, but sufficiently transparent.

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

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

Two sentences, no wasted words, front-loaded with verb and resource. Ideal 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?

For a single-parameter read tool with no output schema, the description fully explains purpose, returns, and sibling differentiation. Nothing missing.

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

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

Input schema has 100% coverage with one parameter described. Description adds value by specifying exact CVar name requirement, case-sensitivity, and giving concrete examples.

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

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

Clearly states it reads a UE Console Variable by name and returns multiple representations. Explicitly distinguishes from execute_console_command by stating it reads CVar state directly without invoking the console exec engine.

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?

Directly contrasts with sibling tool execute_console_command, telling the agent when to use this read-only direct access versus the potentially destructive exec path.

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, and the description does not mention any behavioral aspects such as read-only nature, side effects, or permissions. Since it's a read operation, transparency is lacking.

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

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

Two sentences, front-loaded with purpose, no extraneous information.

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

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

Given zero parameters and no output schema, the description sufficiently explains the return value and its use case. However, it lacks information about potential errors or assumptions.

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

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

There are no parameters, but the description adds value by explaining the output structure and the minor_dotted convenience field, which goes beyond the empty schema.

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

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

The description clearly states the tool returns a structured engine version snapshot with fields like major, minor, patch, changelist, and branch, differentiating it from get_project_summary which returns a single string.

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 advises using this tool when the LLM needs to branch on engine version without parsing a single string, naming the alternative get_project_summary.

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 provided, so description carries burden. Discloses read nature implicitly but does not explicitly state no side effects or if data is cleared. Could be improved by stating it is read-only.

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

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

Two sentences, front-loaded with core purpose, no extraneous information. Every sentence contributes meaning.

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

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

For a simple read tool with 3 parameters and no output schema, description covers operation, filters, limits, and defaults fully. No gaps.

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

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

Schema coverage is 100% with parameter descriptions, so baseline is 3. Description adds value by explicitly stating defaults (100), max (1000), and the 'at or above' severity logic, enhancing understanding beyond schema.

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

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

Description clearly states verb 'Read' and resource 'UE Output Log entries from the in-process ring buffer', making the purpose explicit and unique among siblings.

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

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

Describes supported filters (category, verbosity) and default/max count, giving clear context for when to use. No explicit alternatives or exclusions needed as no other log tools exist.

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 implies a read-only operation with no side effects. While annotations are absent, the tool's function is inherently safe and non-destructive, so transparency is high.

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

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

The description is a single sentence that lists exactly what the tool returns, with no unnecessary words. It is highly concise and front-loaded.

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

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

For a simple summary tool with no parameters and no output schema, the description is mostly complete. However, it could mention that the output is a summary or specify data types, but overall it suffices.

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?

No parameters exist, so schema coverage is 100%. The description does not need to add parameter information. A baseline score of 4 applies.

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

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

The description clearly states it retrieves project name, engine version, enabled plugins, and asset counts. This is specific and distinguishes it from sibling tools like inspect_project_setting (which likely provides detailed settings) and get_engine_version (which only returns engine version).

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

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

No explicit guidance on when to use this tool versus alternatives. Given many sibling inspection tools, it would be helpful to indicate that this is for a quick overview and that more detailed inspection tools exist.

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

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

Discloses BFS traversal, depth bound (default 3, max 8), composition of inspect_asset recursively, and direction behavior. Lacks details on cycle handling or performance, but provides sufficient behavioral context.

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

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

Two concise sentences front-load the core action and add directional guidance without unnecessary words. 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?

With no output schema, description mentions returning 'every node and edge' but not the format. However, context is adequate for a graph traversal tool with well-explained inputs.

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 baseline is 3. Description adds value by explaining the BFS algorithm context and the practical use of each direction, which goes beyond 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?

Clearly states it walks the asset reference graph BFS from a root, returning nodes and edges up to a depth bound. Distinguishes direction=up and direction=down with specific use cases, differentiating from sibling tools like inspect_asset.

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 describes when to use each direction: direction=up for impact-of-change analysis before deletion/renaming, direction=down for dependency audits before packaging. Does not explicitly state when not to use, but context is clear.

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

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

No annotations provided; description carries full burden. It states the exact output (name/label/class/transform of every selected actor). While it doesn't discuss edge cases like empty selection, the read-only nature is clear.

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

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

Two sentences, front-loaded with core functionality, zero wasted words. Efficient and clear.

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 zero parameters and no output schema, the description fully covers the tool's inputs, outputs, and the intended usage pattern as a companion to another tool. No gaps identified.

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?

No parameters exist, so schema coverage is 100%. Description adds nothing beyond the empty schema, but baseline for 0 parameters is 4 per guidelines.

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

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

Description clearly states the tool returns selected actors' properties (name/label/class/transform). It distinguishes from siblings like 'get_actors_in_level' by specifying selection context.

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

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

Explicitly frames the tool as a companion to 'apply_python_to_selection', guiding the agent to use it before acting on selections. Does not list exclusions or alternatives but provides clear 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?

No behavioral traits are disclosed beyond the basic action. For a read-only operation like a screenshot, it is likely safe, but this is not stated. No annotations are provided to rely on.

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

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

The description is a single sentence that communicates the essential information without any wasted words. It is appropriately concise and front-loaded.

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

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

Given no parameters and no output schema, the description fully specifies the tool's action and output format. It mentions the active editor viewport and base64 encoding, which is sufficient.

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

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

The input schema has no parameters (empty properties), so schema coverage is 100%. The description does not need to add parameter info. Baseline score of 4 applies.

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

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

The description clearly states the tool captures the active editor viewport as a PNG and returns it base64-encoded. It distinguishes from similar tools like screenshot_actor (captures specific actor) and take_high_res_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?

No guidance is provided on when to use this tool versus alternatives like screenshot_actor or take_high_res_screenshot. The agent must infer from the 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?

No annotations are provided, so the description carries the full burden. It states 'canonical UE asset import pipeline' but does not disclose side effects such as file overwrite behavior (handled by replace_existing, not described), disk writing, or error handling. For a mutation tool without annotations, this is insufficient.

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

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

A single, well-structured sentence that conveys the core functionality without extraneous words. Every part is meaningful and front-loaded.

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

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

The description is adequate for basic understanding, but with 6 parameters and no output schema or annotations, it lacks details on parameter interactions (e.g., automated, save), success/failure return values, and advanced import scenarios. It covers the essentials but misses some behavioral context.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value by listing supported formats (not in schema), but does not elaborate on individual parameters like 'automated' or 'save' defaults beyond what the schema already provides.

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

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

The description specifies the action ('Import an image file'), the input formats (PNG/JPG/EXR/TGA/BMP/HDR), the asset type (UTexture2D), and the use of 'canonical UE asset import pipeline', clearly distinguishing it from siblings like 'configure_texture' or 'convert_hdri_to_cubemap'.

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 basic usage (when to import a texture), but lacks explicit guidance on when not to use this tool versus alternatives like 'configure_texture' for post-import settings or 'marketplace_import' for marketplace assets. No prerequisites or exclusions are mentioned.

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

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

With no annotations, the description bears full burden. It discloses the read-only nature implicitly ('Read structural properties'), mentions a null guard for compiled data, and notes no new dependencies. It is transparent about the tool's behavior, though could state 'read-only' explicitly.

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 (two sentences) and front-loaded with the tool's purpose and key behaviors. Every sentence provides essential information without redundancy.

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

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

Given no output schema, the description adequately explains what properties are returned. It covers the compiled data guard and dependency info. It could mention error handling or return format, but for a one-parameter read-only tool, it is sufficiently 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 single parameter 'path' is fully described in the schema (UE asset path notation). The description adds little beyond that, only referencing the path in the context of the C++ handler. At 100% schema coverage, a 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 states 'Read structural properties of a UAnimBlueprint asset' and enumerates specific properties like parent class, target skeleton, etc. It distinguishes itself from sibling tools like inspect_blueprint and inspect_anim_montage which handle other asset types.

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

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

The description implies usage for inspecting anim blueprint structural data but does not provide explicit when-to-use or when-not-to-use guidance versus alternatives. It does mention a guard for uncompiled blueprints, which is helpful 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?

No annotations are provided, so the description bears full burden. It clearly indicates a read-only operation ('Read structural properties') and provides implementation detail ('C++ handler; no new Build.cs deps'). It does not specify error behavior or permissions, but for a read tool this is acceptable.

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

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

The description is three sentences, front-loaded with the purpose. Each sentence adds unique value: list of properties, implementation note, and sibling context. No superfluous words.

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

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

The tool is a simple read inspector with one parameter. The description enumerates all key properties returned (skeleton, length, frame rate, blend envelope, sections, tracks, notifies) and situates it among siblings. No output schema is needed; the description covers what the agent needs to know.

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

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

Schema coverage is 100% with a clear description for the single parameter 'path'. The description adds no further semantic detail beyond what the schema provides, so a 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 uses a specific verb 'Read' and identifies the resource as 'structural properties of a UAnimMontage asset'. It lists concrete properties (target skeleton, play length, etc.) and explicitly distinguishes it from siblings by naming the 'animation introspection trio' with inspect_anim_blueprint and inspect_skeletal_mesh.

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 by stating it 'completes the animation introspection trio', giving context for when to use this tool versus other inspection tools. However, it lacks explicit guidance on when not to use it or any prerequisites (e.g., asset must exist).

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

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

With no annotations provided, the description should disclose behavioral traits. It only states it reads data, but does not cover edge cases (e.g., invalid path, missing asset), performance, or safety implications. It lacks behavioral depth beyond the basic read operation.

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

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

The description is a single, well-structured sentence of 22 words. It is front-loaded with the key verb and resource, and every word adds value. No redundancy or filler.

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

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

Given no output schema, the description enumerates the returned data (class, tags, dependencies, file size) which is helpful. However, it omits error handling, format details, and behavior for non-existent assets. Still, for a simple read tool, it is largely sufficient.

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

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

The input schema covers 100% of the single parameter with a clear description including examples. The tool description adds no new parameter information; the schema already provides adequate semantics, so 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 specifies the action ('Read everything'), the resource ('a single asset'), and explicitly lists the returned data (class, tags, dependencies, file size). This clearly distinguishes it from sibling tools like 'bulk_inspect_assets' or asset-type-specific inspectors.

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

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

The description implicitly states it is for a single asset, allowing inference of when to use it. However, it does not explicitly mention alternatives or exclusions (e.g., for detailed type-specific info use other inspectors).

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

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

Discloses synthetic bridge handler implementation, error handling specifics (logical vs transport errors), and return envelope format. No annotations provided, so description carries full burden.

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

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

Three concise sentences covering purpose, implementation, and error handling. No redundant information, well-structured.

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

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

Given the tool's simplicity (1 required param, no output schema), the description fully explains behavior, output fields, and error conditions. No 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 has 100% description coverage for the single 'path' parameter. Description adds no additional meaning beyond what schema provides, so 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?

Description clearly states the action ('Inspect'), the resource ('UAudioBus'), and what is returned (leaf class name, path, channels, UPROPERTYs). The name and content distinguish it from sibling inspect_* 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?

No explicit guidance on when to use this tool versus alternatives. Context is implied by specialization, but no exclusionary or comparative statements.

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?

Read operation is clear, but with no annotations, description carries full burden. It doesn't disclose error handling (e.g., invalid path), permissions, or if operation is safe for concurrent use. Adequate but not comprehensive.

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?

Single sentence conveys precise scope with no redundancy. Perfectly concise for the information provided.

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

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

Given no output schema, description lists all return categories, which is helpful. However, it lacks detail on the format or structure of each item (e.g., variables list, compile status enum). Slightly incomplete for a tool with one parameter.

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