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

The description clarifies that the tool applies changes to multiple visual elements (consistent with non-read-only behavior) and implies idempotency by saying 'apply' without side effects. Annotations idempotentHint=true and destructiveHint=false are supported, and the description adds context of what gets modified.

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 action and scope; the second provides guidance. Information is front-loaded 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 a single required parameter and existence of an output schema (not shown but noted), the description covers the core purpose, parameter sourcing, and affected systems. It does not describe return values or error cases, but those may be covered by the output schema. Complete enough for the complexity.

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

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

With 0% schema description coverage, the description compensates by telling the agent to call ue_list_mood_presets for valid names, but does not elaborate on parameter format or constraints beyond the schema type. Baseline for low coverage is 3, and this description provides adequate but not rich semantics.

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

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

The description clearly states the tool applies a named cinematic mood as a coordinated package, specifying affected elements (sun angle/colour, fog, clouds, post-process colour grade). This distinguishes it from sibling tools like ue_set_time_of_day or ue_setup_sky_atmosphere.

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 instructs to call ue_list_mood_presets for available names and provides example names (golden_hour, noir, etc.), giving clear context on how to select parameters. It does not explicitly state when not to use it but implies a workflow.

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

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

Annotations indicate idempotent, non-readonly, non-destructive. The description adds valuable behavioral details: interpolation method, snap threshold (t>=0.5), and that numeric/color values interpolate while toggles snap. This goes beyond the annotations without contradicting them.

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

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

Two concise sentences. The first states the action and general effect, the second explains the parameter t and its behavior (interpolation vs snap). No redundant or unnecessary 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 output schema existence, return values are not required. The description covers input semantics well (t, interpolation types). It does not mention prerequisites (e.g., valid preset names from ue_list_mood_presets) or error conditions, but for a blending tool with clear interpolative behavior, it is largely 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 descriptions are absent (0% coverage), so the description carries full burden. It explains t (value between 0 and 1, default 0.5) and its effect on preset_a vs preset_b. It also describes interpolation behavior for different property types. However, preset_a and preset_b are only identified as 'mood presets' without mentioning source (e.g., from ue_list_mood_presets). This partial compensation earns a 4.

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

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

The description clearly states the verb 'Blend... and apply' and identifies the resources (mood presets). It explains the effect (interpolation of numeric/color values, snapping of toggles) and implicitly distinguishes from the sibling 'ue_apply_mood_preset' by focusing on blending two presets.

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 usage context: 'Great for dialing a look between two references.' It explains the t parameter behavior but does not explicitly state when not to use or list alternatives. Still, the guidance is sufficient for an AI agent to infer appropriate usage.

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

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

Annotations provide readOnlyHint=false, idempotentHint=false, destructiveHint=false. The description adds that it captures output and lists blocked destructive commands, but does not disclose other behavioral traits such as side effects, error behavior, or permissions. The annotations carry the main transparency 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?

The description is extremely concise with two sentences, no extraneous words, and front-loads the core purpose. The blocked command list adds value without bloat.

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 a single parameter and an existing output schema, the description covers the essential action. However, it lacks information on error handling, execution context (e.g., UE editor), and potential timeout behavior, making it only 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?

The schema has 0% description coverage, and the tool description does not explain the 'command' parameter at all. It only mentions 'Execute a UE console command,' which is insufficient to convey what values the parameter accepts or any format requirements.

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 'Execute a UE console command and capture output,' using a specific verb and resource. It distinguishes from siblings like ue_execute_python by listing blocked commands, which narrows the scope.

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

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

The description lists blocked commands (e.g., exit, quit, crash), which provides when-not-to-use guidance. However, it does not explicitly state when to use this tool over alternatives like ue_execute_python, leaving gaps in usage 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?

The description discloses that the tool creates an actor and requires a plugin. With annotations being all false, it fails to clarify important behavioral aspects such as whether the operation is idempotent, what side effects occur (e.g., instancing multiple meshes), or any required permissions. More detail is needed.

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, with two sentences front-loading the core purpose and a key requirement. However, for 10 parameters, it is under-informative and could benefit from a brief parameter overview without becoming verbose.

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

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

Given the tool's complexity (10 parameters, no schema descriptions, and minimal annotations), the description is insufficient. It lacks details on parameter usage, output behavior (despite an output schema existing), and fails to provide the context needed for an agent to confidently invoke the tool.

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

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

With 10 parameters and 0% schema description coverage, the description provides no information about what parameters like x, y, z, label, layout, counts, spacing, or mesh_path mean. The description mentions only 'mesh' and 'layout pattern' but does not map to the schema. This severely hinders correct parameter usage.

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

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

The description clearly states the verb 'Create', the specific resource 'ClonerEffector actor', and the action 'instances a mesh in a layout pattern'. It also includes a prerequisite plugin requirement, making the purpose unambiguous and distinct from sibling tools like ue_duplicate_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 mentions a required plugin, providing a necessary condition for use. However, it does not specify when to use this tool versus alternatives, nor does it give any exclusions or contexts where it should be avoided.

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

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

Annotations already indicate this is not read-only (readOnlyHint=false) and not destructive (destructiveHint=false). The description adds the duplication behavior but does not disclose side effects (e.g., whether it modifies the existing actor, what happens to references, or what the output contains). With output schema present, the lack of detail is partially mitigated but not fully.

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

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

The description is very short (one sentence) and contains no fluff, but it could be more informative without losing conciseness. It does not fully earn its place given the tool's complexity.

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

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

With 4 parameters (1 required) and no schema descriptions, the description is too sparse. It does not explain what the output is (despite an output schema existing), how offsets are applied (relative or absolute), or any constraints. Sibling tools provide further context but the description itself is lacking.

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

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

Schema description coverage is 0%, so the description should compensate. It mentions 'optional position offset' but does not explain the three offset parameters individually or the required actor_label. The parameter names are somewhat self-explanatory, but the description adds minimal value beyond what is evident from the names.

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 'Duplicate' and the resource 'actor', and mentions the optional offset feature. This distinguishes it from sibling tools like ue_create_cloner or ue_snap_to_ground.

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 (e.g., ue_create_cloner, ue_spatial_query). There is no mention of prerequisites or scenarios where duplication is appropriate.

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

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

Annotations already flag destructiveHint=true. The description adds that it is the most powerful tool, has access to all editor APIs, and that print() is used for output. This provides useful behavioral context beyond annotations, though it could mention potential side effects like scene modification.

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, each earning its place. No redundant information. Front-loaded with the core purpose and immediately followed by key capabilities and usage guidance.

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

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

Given the tool's complexity and destructive potential, the description explains input, output mechanism, and when to use it. The presence of an output schema reduces the need to describe return values. Slight lack of safety warnings, 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?

With 0% schema description coverage, the description fully compensates by explaining that the 'code' parameter takes Python code, has access to editor APIs, and that print() returns output. This adds meaning beyond the raw 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 executes Python code in the UE5 editor, specifies access to the 'unreal' module and editor APIs, and explicitly contrasts with sibling tools by calling itself the most powerful tool to use when no specific tool exists.

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 says 'use it when no specific tool exists for your operation,' giving clear guidance on when to prefer this tool over alternatives. Lacks explicit exclusions but the context of sibling tools makes the usage context clear.

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

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

Annotations already declare readOnlyHint and idempotentHint, confirming safe, repeatable behavior. The description adds value by specifying recursive traversal with a max depth of 10, which is behavioral context not captured by annotations.

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

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

The description is two sentences, front-loaded with the main action, and every sentence adds value. No redundant or irrelevant information.

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

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

Given the tool's simplicity (one parameter, output schema present), the description covers the key behavioral aspects (recursive depth limit). It does not explain error handling or output format, but the output schema likely handles that. Slight gap in usage context 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 description coverage is 0%, so the description must compensate. It only mentions 'for an actor', implying actor_label identifies the actor, but gives no details on format or identification rules. This is minimal semantic addition for a required parameter.

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

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

The description clearly states the tool retrieves the parent-child attachment tree for an actor and shows all attached children recursively. It uses specific verbs and resource, and while it doesn't explicitly differentiate from siblings, the purpose is clear and distinct from other tools like spatial queries or console commands.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, when not to use it, or any comparison with sibling tools, leaving the agent to infer 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?

Annotations already indicate readOnly, idempotent, and non-destructive behavior. The description adds context by listing specific information types returned (streaming levels, world settings, game mode), which provides useful insight beyond the annotations. It does not mention rate limits or permissions, but for a safe getter, this is sufficient.

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

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

The description is a single, compact sentence that front-loads the action and resource. Every word is meaningful, and there is no verbosity or redundancy.

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

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

Given zero parameters and the existence of an output schema (not shown but indicated), the description adequately covers what the tool does. The output schema handles return value details, so the description does not need to elaborate further. It is complete for a straightforward getter.

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

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

The tool has zero parameters, and the input schema coverage is 100% (empty). Baseline score is 4 because there are no parameters to describe. The description does not need to add parameter semantics.

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

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

The description clearly states the tool retrieves detailed world information including streaming levels, world settings, and game mode. The verb 'Get' and resource 'world information' are specific, but it does not explicitly differentiate from sibling tools like ue_status, though the name uniquely implies world-level data.

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 can be used to obtain world details but provides no guidance on when to use it versus alternatives, nor any prerequisites or restrictions. Since the tool is simple and has no parameters, the lack of explicit usage guidance is less critical but still a gap.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds value by specifying return data (hit point, normal, distance, actor), which annotations do not cover.

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 efficient sentences: first defines purpose and outputs, second gives usage context. 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?

Output schema exists (not shown) so return values are covered. However, parameter start_z is unexplained, which is a gap for a tool with only 3 params and no schema descriptions.

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%. Description does not explain parameters individually; start_z is not mentioned despite having a default value, leaving agents to guess its meaning.

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

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

Description uses specific verb 'line-trace' and resource 'ground/surface', clearly states what it does, and distinguishes from siblings by specifying it traces straight down at world coordinates.

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 when to use: 'before placing props so you know where the floor is'. No explicit alternatives or when-not, but context is clear and helpful.

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

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

Annotations declare readOnlyHint and idempotentHint as true, and destructiveHint as false, indicating a safe read operation. The description adds behavioral context by detailing the health data returned and explaining that deep=true runs a capability preflight, going beyond what annotations provide.

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

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

Two concise sentences: first states purpose and output, second provides usage guidance and parameter detail. Front-loaded with key information, no redundant 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 description covers the essential purpose, usage, and parameter. With an existing output schema (not shown), the return values are likely well-documented. The description could mention potential error conditions or limitations, but it's fairly 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 description coverage is 0%, but the description compensates fully by explaining the 'deep' parameter's purpose: to run a capability preflight to check if the bridge can execute. This adds significant meaning beyond the schema's basic type and default.

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 'Get' and the resource 'bridge health', listing specific data points (version, uptime, circuit breaker state, request metrics). This distinguishes it from sibling tools like 'ue_preflight' and 'ue_status'.

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

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

The description explicitly says 'Use this to diagnose connection issues', providing a clear context for when to invoke the tool. It also explains the 'deep' parameter as an alternative for a deeper check, though it doesn't explicitly mention when not to use it.

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

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

Annotations already provide readOnlyHint, idempotentHint, destructiveHint. The description adds 'built-in' and 'descriptions' context but no additional behavioral traits. No contradiction with annotations.

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

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

Single sentence, no redundant words, directly states purpose. 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?

Given zero parameters, complete annotations, and an output schema, the description fully covers what the tool does—listing presets and descriptions. 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?

No parameters exist, and schema coverage is 100%. Baseline is 4; description does not add parameter info but is not needed. It correctly implies no input required.

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

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

The description clearly states the tool lists built-in cinematic mood/look-dev presets and their descriptions, using a specific verb-resource pairing. It distinguishes from sibling tools like ue_apply_mood_preset and ue_blend_mood_presets.

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

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

Usage context is implied (list presets before applying/blending), but there is no explicit statement of when to use or not use this tool versus alternatives. No exclusions or sister tool references.

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 the ladder of tests (reachable, remote function calls, value round-trip, Python round-trip), stop-at-first-failure behavior, and return content (cause, fix, raw error). Annotations already indicate readOnly and idempotent; description adds valuable behavioral detail beyond 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?

Three sentences: purpose, mechanism, usage context. Front-loaded with key verb and resource. No extraneous 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?

Given zero parameters, present annotations, and existing output schema, the description fully covers the tool's purpose, behavior, and usage. 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 baseline of 4 applies. Description does not need to add parameter info. 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?

The description clearly defines a preflight probe that checks actual execution capability, not just connection. It distinguishes from ue_status by specifying what it tests and its use case. The verb 'probe' and resource 'capability' are 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?

Explicitly states when to use: 'whenever tools error but ue_status says connected', with a concrete example (UE 5.8's bAllowAnyRemoteFunctionCall block). This provides clear context and differentiation from alternatives.

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

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

Annotations indicate idempotentHint=true and destructiveHint=false. The description adds behavioral context: it drives multiple lighting properties, builds/reuses the sky rig, and recaptures. This goes beyond the annotations by explaining side effects without contradiction.

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

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

The description is two sentences long, front-loaded with the primary action and followed by key effects and technical detail. Every word contributes value; there is no redundancy or verbosity.

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

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

Despite having one parameter and an output schema (not shown), the description covers the parameter's effect and the tool's overall behavior (sky rig reuse). It could mention prerequisites (e.g., sky atmosphere setup) but remains adequate for a focused tool with idempotent annotation.

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

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

The input schema provides no description for the 'hour' parameter (0% coverage). The description compensates by specifying the valid range 0-24 and explaining that it drives sun elevation, compass azimuth, colour temperature, and intensity. This adds meaning beyond the schema's type and default.

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 sets the time of day and specifies the hour range 0-24. It enumerates the effects (sun elevation, azimuth, colour temperature, intensity) and mentions sky rig reuse, making the purpose unambiguous and distinct from sibling tools like ue_setup_sky_atmosphere.

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 provide explicit guidance on when to use this tool versus alternatives. While the purpose is clear, there is no mention of prerequisites or conditions (e.g., requiring ue_setup_sky_atmosphere first), nor comparison to sibling tools that might adjust lighting differently.

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

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

Annotations provide idempotentHint=true and destructiveHint=false. The description adds behavioral details: find-or-spawns actors, recaptures sky, and reuses existing rig. No contradiction with annotations. Additional context on limits or side effects would be beneficial but is not critical given 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, no fluff. The first sentence front-loads the purpose and key components. The second sentence explains two key parameters and idempotency. Every word earns its place, and the structure is logical.

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 (multiple actors, parameters) and existing annotations, the description provides a good overview but leaves gaps. Parameter documentation is incomplete, and it does not mention the output schema (though exists). The description is adequate for basic use but not fully comprehensive for all scenarios.

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

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

Schema description coverage is 0%. The description explains only two parameters (sun_elevation, sun_azimuth) with degrees and compass heading. The other four parameter names (fog, clouds, fog_density, sun_intensity) are self-explanatory to some extent but lack precision. For example, sun_intensity's default null and anyOf is unexplained, and fog_density's unit is missing. With 0% schema coverage, the description should document all parameters more thoroughly.

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 builds or updates the sky/atmosphere rig in one call, listing specific components (DirectionalLight, SkyAtmosphere, SkyLight, fog, clouds) and action (recapturing sky). It distinguishes from sibling tools like ue_set_time_of_day, which adjust time, not setup.

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

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

The description gives clear context (build/update sky rig) and notes idempotency, implying safe reuse. However, it does not explicitly state when to avoid this tool versus alternatives like mood presets or when manual setup is preferred.

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

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

The description adds behavioral context beyond annotations: 'One fast transaction' indicates speed and atomicity, and 'bounding-box bottom rests on the ground' clarifies the exact outcome. However, it does not disclose failure modes (e.g., what if ray doesn't hit ground) or permissions needed. Annotations already indicate idempotency and non-destructiveness, so the bar is lower.

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

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

The description is two sentences: the first gives the primary action, the second lists options and adds a performance note. Every word is necessary; no redundancy or filler. It is front-loaded and easily parseable.

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

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

For a tool with 3 parameters and a simple action, the description covers the core behavior and optional features. It mentions a transaction hint and offsets. However, it does not address edge cases like missing ground or incompatible actors, and the output schema is not described but is available separately. Overall, it is sufficient for typical use.

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

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

With 0% schema description coverage, the description fully explains all three parameters: 'by label' for actor_label, 'apply a vertical offset' for z_offset, and 'tilt it to match the surface slope' for align_to_normal. It adds meaningful semantics beyond titles and defaults, leaving no ambiguity about parameter purpose.

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: 'Drop an actor onto the surface directly beneath it so its bounding-box bottom rests on the ground.' It specifies the resource (actor by label) and the verb (snap/drop), and distinguishes from siblings like ue_ground_trace (which likely traces rays, not snaps) by focusing on repositioning with optional tilt and offset.

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

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

The description provides no guidance on when to use this tool versus alternatives (e.g., ue_ground_trace, ue_spatial_query). It does not mention conditions like actor must exist, must be movable, or what happens if no ground is found. The agent must infer usage from 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds value by detailing the behavior of each mode (e.g., 'N closest actors', 'penetration depth', 'union AABB', 'actors inside box'). This goes beyond what annotations provide, though it could mention that results are returned as a list or other format.

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

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

The description is concise, consisting of two sentences that front-load the purpose and then list modes. There is no redundant information. It could be slightly more structured (e.g., bullet points for modes), but it is clear 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 the tool's complexity (12 parameters, 1 required, with output schema), the description provides a good high-level overview and explains mode and filters. However, it omits critical details about spatial parameters (coordinates, extents) which are central to the tool's operation. The presence of an output schema somewhat reduces the need to explain return values, but the missing parameter details leave the description incomplete.

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

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

The schema has 0% description coverage. The description explains the 'mode' parameter and mentions 'class_filter' and 'tag_filter', but fails to describe many other parameters (x, y, z, count, actor_a, actor_b, extent_x, extent_y, extent_z). With 12 parameters and no schema descriptions, the tool description should compensate by explaining these, but it does not.

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

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

The description clearly states the tool's purpose: 'Reason about actor positions and volumes.' It enumerates four distinct modes with brief explanations, making the tool's function very specific. The sibling tools (e.g., ue_ground_trace, ue_get_actor_hierarchy) are clearly different in purpose, so this tool is well-differentiated.

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 each mode's behavior (nearest, overlap, combined_bounds, box_contents) and implies usage for spatial queries. It does not explicitly state when not to use this tool or compare it to siblings, but given the unique nature of the sibling tools, the guidance is sufficient for a typical use case.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds context about what is checked (editor running, API reachable) but does not provide additional behavioral details beyond that. This is adequate given the safety profile is clear from annotations.

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

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

The description is a single sentence that is front-loaded with the key action. Every word earns its place; no 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?

Given the simplicity of the tool (no parameters, output schema exists), the description is fully sufficient. It tells the agent exactly what the tool does without needing further elaboration.

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

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

With zero parameters and 100% schema description coverage, the description correctly has no parameter details. The baseline score of 4 is appropriate as the empty schema says nothing and the description does not need to compensate.

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

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

The description uses the specific verb 'check' with the clear objects 'UE5 editor is running' and 'Remote Control API is reachable'. This explicitly distinguishes it from siblings like 'ue_health_check' which might cover broader health, while this focuses on connectivity.

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 usage guidance is provided. There is no mention of when to use this tool versus the sibling 'ue_health_check' or any context about prerequisites or typical 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?

Annotations already indicate the tool is not readonly, idempotent, and not destructive. The description adds minimal behavioral context beyond listing the configurable attributes; it does not mention side effects, prerequisites, or effects on the system.

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

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

The description is a single, front-loaded sentence with no unnecessary words. However, it could be more informative without adding length.

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 five optional parameters and no enum constraints, the description fails to explain defaults, parameter interactions, or what the output schema returns. The tool is a configuration operation, yet the description omits critical usage context.

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

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

Schema description coverage is 0%, so the description must explain parameters. It vaguely lists 'resolution, format, capture rate' but does not map to specific parameters (width, height, format, max_fps, quality) or clarify allowed values, defaults, or constraints.

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

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

The description 'Configure the viewport perception system (resolution, format, capture rate)' clearly specifies the verb (configure) and resource (viewport perception system), and distinguishes from sibling tools like ue_viewport_percept (perception) and ue_viewport_diff (diff).

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 lacks any guidance on when to use this tool versus alternatives such as ue_viewport_percept or ue_viewport_watch. No explicit conditions or exclusions are provided.

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

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

The description adds behavioral context beyond annotations: it captures two snapshots with a delay (controlled by delay_ms) and returns a diff. This aligns with readOnlyHint and idempotentHint. No contradiction.

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

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

The description is two sentences, short and front-loaded. The first sentence explains the action and result, the second gives a use case. 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 single optional parameter, rich annotations, and existing output schema, the description covers purpose, usage context, and behavioral key points. No gaps are apparent.

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

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

With 0% schema description coverage, the description compensates by mentioning 'with a delay,' which implies the delay_ms parameter. It does not explicitly name the parameter or detail its unit, but the default and context make it clear enough for an agent.

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 two viewport snapshots and returns a structural diff of changes (actors, camera, selection). The verb 'Capture' and the resource are specific, and the purpose of verifying scene modifications distinguishes it from siblings like ue_viewport_percept or ue_viewport_watch.

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 suggests use for verifying scene modifications, providing a clear context. However, it does not explicitly mention when not to use or compare to alternative sibling tools, so the guidance is good but not exhaustive.

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

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

Annotations already indicate readOnly and idempotent behavior. The description adds value by specifying the returned data (image, camera, selection, metadata), with no contradiction. It could further disclose format or prerequisites.

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 fluff, earning every word.

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 captures the core function and output, but lacks parameter guidance. Given an output schema exists, return values are covered, but the missing parameter context reduces completeness for a 4-parameter 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 0% and the description does not explain any of the 4 parameters (width, height, format, include_image), leaving the agent without meaning beyond the schema.

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

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

The description clearly states the tool captures the viewport and returns an image plus metadata, providing a specific verb and resource that distinguishes it from sibling tools like ue_viewport_config or ue_viewport_diff.

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 for visual awareness but does not explicitly state when to use this tool versus alternatives, nor does it exclude any contexts or give when-not-to-use guidance.

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

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

Annotations set idempotentHint=true and destructiveHint=false, reducing the burden. Description adds that it captures frames continuously, but lacks details on the effects of start vs. stop or consequences of repeated calls.

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 key information. No 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?

Description covers start/stop and capture behavior but omits details on the action parameter and potential side effects. With four optional parameters but defaults, basic completeness is 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 0%, so description must compensate. Only the rate (fps) is hinted; no explanation of action, width, or height parameters.

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

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

Clearly states it starts/stops viewport awareness with a specified rate. Distinguishable from siblings like ue_viewport_config or ue_viewport_percept, but could be more specific about 'viewport awareness'.

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 versus alternatives, no when-not-to-use information. Only implies usage context via 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?

Annotations already indicate destructiveHint=true. The description adds that it validates first and applies transforms, but lacks details on side effects like overriding previous transforms, reversibility, or undo behavior. The version note (v0.4.0) adds minimal 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 (3 sentences), front-loaded with the primary action, and includes a version note. 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 existence of an output schema, return values are covered. However, the description lacks context on the input format and does not address potential failure modes beyond returning an error. For a tool with moderate complexity and no additional annotations beyond destructiveHint, a bit more detail would be helpful.

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

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

The schema has 0% description coverage for the only parameter ('x3d'). The description does not explain what the 'x3d' string should contain (e.g., file path, content, XML). It merely mentions 'X3D document's actor transforms', which is insufficient for an agent to construct the parameter correctly.

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's function: 'Apply an X3D document's actor transforms back to the live level.' It specifies the process (validates, then sets location/rotation/scale) and resource (transforms addressed by DEF). This clearly distinguishes it from sibling tools like ue_x3d_export and ue_x3d_validate.

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 a prerequisite: 'Actors must already exist.' However, it does not provide guidance on when to use this tool versus alternatives (e.g., ue_x3d_preview), nor does it specify when not to use it. The usage context is implied but not explicitly differentiated.

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

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

Adds behavioral context beyond annotations: reads actor properties, converts coordinates, returns actor_count and x3d. Annotations already indicate read-only and idempotent, so description enhances understanding.

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 with no redundancy. Front-loaded with main action, then relevant details. 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?

Covers key behaviors: serialization, data read, coordinate conversion, return value. Output schema exists but description suffices. Could mention potential limits or side effects.

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

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

With 0% schema description coverage, the description explains mesh_only parameter's behavior (exports only actors with static mesh when True). Adds meaning beyond the schema definition.

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 serializes the current level to X3D text, specifying the grammar, data read, coordinate conversion, and mesh_only parameter. Distinguishes from sibling tools like ue_x3d_apply and ue_x3d_preview.

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 exporting level to X3D, but lacks explicit when-not or alternative references. However, sibling names provide 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?

Annotations already indicate readOnlyHint and idempotentHint. The description adds useful context: the output is a standalone HTML referencing X_ITE from CDN, requiring network access, and the X3D payload is embedded inline. No contradiction.

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

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

Two succinct sentences with no wasted words. Every sentence adds value: first states the core action and output format, second provides a network dependency caveat.

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, the description covers key aspects: input, output structure, and runtime requirement. The presence of an output schema reduces the burden, though the output is also described. A minor gap is not specifying the X3D format (e.g., XML, JSON) 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?

With 0% schema description coverage, the description should compensate. It only vaguely mentions 'an X3D document' for the required 'x3d' parameter and doesn't explain the 'title' parameter beyond its default value. More detail on content format or usage is needed.

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 ('render') and resource ('X3D document'), clearly distinguishing it from sibling tools like ue_x3d_apply, ue_x3d_export, and ue_x3d_validate. The phrase 'no editor needed' adds 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 implies use for previewing X3D documents but lacks explicit guidance on when to use or avoid this tool. No alternatives 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?

Annotations already indicate readOnlyHint, idempotentHint, and destructiveHint. The description adds behavioral details: it 'rejects' various issues and 'does not touch the editor', consistent with readOnly. It also specifies the return format {ok, errors}, which goes beyond 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: the first states the main action and specifics, the second gives usage guidance. No redundant words. Front-loaded with the 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?

Given the presence of an output schema, the description covers the return format ({ok, errors}), lists validation checks, and provides usage context. It could mention if the function throws errors, but the return format is clear.

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

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

The schema has a single parameter 'x3d' of type string with 0% schema description coverage. The description refers to 'X3D document' but does not specify whether the string should be the raw XML content or a file path. This ambiguity reduces clarity for the agent.

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 'validate' and the resource 'X3D document', and lists specific validation checks (grammar, dangling USE references, numeric arity, non-X3D roots, NaN/inf). This distinguishes it from sibling tools like ue_x3d_apply and ue_x3d_export.

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

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

The description explicitly says 'Run this on model-edited X3D before apply', providing clear when-to-use context. It does not mention alternatives or when not to use, but the guidance is sufficient for typical use.

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