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

No annotations are provided, so the description carries the full behavioral burden. It prominently declares READ-ONLY, specifies that orphan detection uses the asset registory, and discloses the graph limitation. It does not clarify dryRun, timeout, or editor-interaction semantics, but the read-only scope and boundaries are strongly conveyed.

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

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

Two sentences with high information density and no filler. The READ-ONLY scope, resource, and the Blueprint boundary are front-loaded, and every clause carries audit-specific detail that an agent needs.

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

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

For a complex read-only audit with five parameters and no output schema, the description gives enough to select and invoke it correctly: skeleton input, searchPath scope, and the exact asset categories returned. It does not specify return structure or the operational effects of dryRun/editor flags, but those are secondary to the core purpose and boundaries.

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

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

Schema description coverage is only 40%, so the description must compensate. It adds meaning for skeleton (audit target) and searchPath (scope of the audit), which are useful, but leaves dryRun, timeoutSeconds, and allowWithEditorOpen completely unexplained. This is a partial compensation with a clear gap around the operational parameters.

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

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

The description names a specific verb ('audit') and resource (animation assets for a skeleton), then enumerates the exact asset categories covered and the orphan-detection goal. It self-differentiates from generic sibling tools by declaring 'READ-ONLY' and by explicitly excluding the state-machine graph, which is not part of this tool.

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

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

It clearly states when to use the tool: for an animation audit of a skeleton across a search path. It also provides an explicit when-not and alternative: the state-machine graph is Blueprint territory and should be audited via the live UnrealClaude plugin, not headless.

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

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

With no annotations, the description carries the burden of explaining behavior, and it does disclose the same-commandlet-boot guarantee and the all-or-nothing failure condition. However, it does not explain what happens to script changes if verification fails (rollback, persistence, partial effects) and does not mention the dryRun or other safety-related 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 core behavior is front-loaded and presented in a compact paragraph. The final tagline adds personality and reinforces the verification purpose, though a bit of it is rhetorical rather than strictly informative. Overall it earns its length, with minimal repetition.

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

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

This is a complex nested-parameter tool with no output schema and no annotations, but the description omits important operational details: how expectation matchers work, how the verify target is selected, what dryRun=true implies, and what the return/error shape looks like. An agent would need to dig deeply into the schema to call this correctly.

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

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

Schema description coverage is only 14%, so the description must compensate for seven under-documented parameters. It loosely maps script, verify, and expect to 'repo script', 'probe an actor or asset', and 'expectations', but it does not clarify the semantics of args, dryRun, timeoutSeconds, allowWithEditorOpen, or the nested verify/expect object structures.

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

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

The description clearly states a specific verb plus resource: it runs a repo script, probes an actor or asset, and checks expectations in the same commandlet boot. This differentiates it from sibling tools like unreal_run_python_script and unreal_probe_actor by emphasizing the combined atomic apply-and-verify behavior.

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

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

The description implies the tool should be used when you want both mutation and verification in one commandlet boot, but it never gives explicit when-to-use/when-not-to-use guidance or names alternatives. The 'probe before you believe' line hints at the intended context but leaves the selection decision to inference.

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 behavioral disclosure burden and does a good job: it signals this is a read-only status check, reveals a practical risk consideration (file-lock), and lists what the status covers. It does not mention authentication or side effects, but the tool's nature makes them low-risk.

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 tight sentence that leads with the core purpose and enumerates the relevant items without wasted words. Every clause adds information an agent needs.

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 no-parameter, no-output-schema status tool, the description gives enough context for an agent to choose it and understand the kind of information it will receive. It could be slightly more explicit about the exact shape of the status response, but the listed categories suffice.

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 schema is empty with 100% coverage. Per the rubric, zero-parameter tools receive a baseline of 4 because there is no parameter meaning to clarify.

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?

Describes a specific resource (server/environment status) with a clear verb phrase and enumerates the key content: paths, editor-running state, and script housekeeping. This distinguishes it from sibling tools, which are all mutation/inspection actions rather than a status query.

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

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

The description implies a clear usage context by flagging file-lock risk for mutating tools, suggesting this should be checked before running those tools. It does not explicitly say 'use when' or name alternatives, but the intended timing and purpose are evident.

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

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

With no annotations, the description carries the burden. It usefully discloses mutation, map-saving, the in-game override, and the editor-open refusal unless allowWithEditorOpen. However, it omits the dryRun flag (default true), which could affect whether the map is actually saved, so the disclosure is incomplete.

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

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

Three sentences, front-loaded with the core action and side effect, followed by the two most decision-relevant caveats. No filler.

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

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

For a mutating, six-parameter tool with no annotations and no output schema, this is not complete. The critical in-editor caveat and mutation guard are present, but the unqualified statement that it saves the map conflicts with a dryRun default of true, and the return value and timeout behavior are unexplained.

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 illuminate the six parameters. It explains the preset concept, the target as sky actor (actorLabel), and the allowWithEditorOpen guard, but leaves map, dryRun, and timeoutSeconds without any semantic guidance in either schema or 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 opens with a specific verb ('Apply'), a concrete resource ('sky actor'), a named preset concept, and a side effect ('save the map'). It distinguishes this from sibling tools by scoping it to editor-time UDS lookdev checks, which none of the sibling names suggest.

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

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

It explicitly says this is for in-editor look checks only and warns that runtime phase profiles override the preset every tick in-game, giving a clear when-not-to-use condition. It stops short of naming an alternative sibling, so it earns 4 rather than 5.

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

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

With no annotations provided, the description correctly takes on the burden of behavioral disclosure. It explicitly declares the operation READ-ONLY and specifies the return shape as one MCP INSPECT_JSON line. It does not explain optional behavioral aspects like dry-run or editor-open interactions, but the core safety and output behavior are 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?

The description is one dense, front-loaded sentence with no filler. The READ-ONLY label, target actors, and key fields all appear early, though the colloquialism 'that have actually burned us' adds color rather than technical precision.

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 read-only inspect tool with defaults on all optional parameters, the description is minimally sufficient: the caller knows what is inspected and what is returned. However, with no output schema and no explanation of dryRun, timeoutSeconds, or allowWithEditorOpen, non-default invocations lack needed 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 needed to compensate by explaining the parameters. It only gives context for 'map'; dryRun, timeoutSeconds, and allowWithEditorOpen are never mentioned, leaving their meaning and effects unexplained.

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

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

The description states a specific verb and resource: it reports the sky (UDS) and weather (UDW) actors in a map, and lists the exact fields inspected. This clearly distinguishes it from write-oriented siblings like uds_apply_preset and from generic probe 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 READ-ONLY label and the phrase 'fields that have actually burned us' imply this is the diagnostic tool to run before modifying sky/weather state, but it does not explicitly state when to prefer it over alternatives such as unreal_probe_actor or uds_apply_preset. Usage context is implied rather than spelled out.

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

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

With no annotations provided, the description carries the full burden. It clearly labels the operation as mutating, discloses the editor-open refusal behavior, and mentions the save side effect. It does not, however, explain that dryRun defaults to true, which could prevent actual mutation.

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

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

The description is two sentences with no filler. The core action is front-loaded, and the critical behavioral guard is placed in a separate, easily parsed sentence.

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

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

For a 7-parameter mutation tool with no output schema and no annotations, the description is not fully self-sufficient. It omits dryRun semantics, timeout behavior, and what the tool returns or verifies after saving. The editor-open guard is helpful, but a crucial default behavior is missing.

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

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

Schema description coverage is 0%, so the description must compensate. It gives meaning to map, actorLabel, material, slot, and allowWithEditorOpen, but leaves dryRun and timeoutSeconds unexplained. dryRun is especially important because it defaults to true and directly affects whether the mutation happens.

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 and resource chain: assign a material to a slot on a named actor's static mesh component in a single map, then save. This clearly distinguishes it from siblings like unreal_set_actor_properties or unreal_spawn_actors.

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 context by noting the operation targets one map and requires the editor to be closed unless allowWithEditorOpen is set. However, it never explicitly states when to prefer this tool over alternatives such as unreal_set_actor_properties or unreal_create_material_instance, so usage guidance is only implied.

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

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

No annotations are provided, so the description carries the burden of disclosing behavior. It clearly declares the read-only nature and the classDefaults branching, which are useful behavioral signals. However, it does not disclose return shape, failure/not-found behavior, or how optional parameters like dryRun and allowWithEditorOpen affect execution, leaving meaningful gaps.

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 tight sentences with no filler. The safety keyword 'READ-ONLY' is front-loaded, the asset scope is presented with concrete examples, and the sibling relationship is compressed into one useful clause.

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 no annotations, no output schema, and six parameters, the description covers the core required parameters and the main behavioral branch. It is not fully complete because it omits return-value shape, error behavior, and the roles of the three optional parameters, which an agent would need for confident end-to-end 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?

Schema description coverage is only 17%, so the description must compensate. It does define the core semantics: 'props' are property display names and 'classDefaults: true' selects Blueprint class defaults. But it says nothing about dryRun, timeoutSeconds, or allowWithEditorOpen, relying on their names and defaults instead of explaining their behavior.

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

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

The description names a specific verb ('read properties'), a specific resource ('ANY asset' including DataAssets, meshes, materials), and a distinct mode ('Blueprint's class defaults'). It also differentiates itself from its sibling unreal_probe_actor by calling itself 'the asset-side sibling,' so an agent can tell them apart without inspecting schemas.

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

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

The 'READ-ONLY' prefix and 'asset-side sibling of unreal_probe_actor' provide clear context for when to choose this tool: reading asset properties rather than actor properties. It does not enumerate exclusions versus write-oriented siblings like unreal_set_asset_properties, but the usage context is explicit enough for correct selection.

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 of behavioral disclosure. It does say 'then save,' which signals persistence, but it omits important behavioral facts such as dryRun defaulting to true, overwrite/update semantics, editor-open requirements, or side effects of updating an existing material instance.

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 efficient sentence that front-loads the primary action and then lists the key parameter categories. There is no filler, repetition, or unnecessary detail.

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

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

This is a 9-parameter mutation tool with nested objects, no annotations, and no output schema, yet the description is only one sentence. It fails to explain required path semantics, dry-run behavior, safety, or return expectations, leaving substantial ambiguity for correct invocation.

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

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

Schema description coverage is only 22%, so the description must compensate. It does add meaning by clarifying that scalars/vectors/textures are parameter dictionaries and that parent is the source material. However, it gives no semantic guidance for name, destination, dryRun, timeoutSeconds, or allowWithEditorOpen, including the required destination.

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

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

The description opens with 'Create (or update) a MaterialInstanceConstant from a parent material' — a specific verb, asset type, and source. It also names the parameter groups (scalar/vector/texture) and the save step, making it distinguishable from siblings like unreal_apply_material_to_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 use case is reasonably clear: use this tool when you need to create or update a material instance asset. However, there is no explicit when-to-use vs. when-not-to-use guidance, and no alternative tool is named, so the agent is left to infer the boundary against sibling tools.

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

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

With no annotations, the description carries the full burden of disclosing side effects, and it does state that the operation is 'Mutating' and that it refuses while an editor is open unless allowWithEditorOpen is set. However, it does not clarify the dryRun default behavior, overwrite semantics, or what happens on refusal or success.

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 filler, with the core operation front-loaded and the critical safety condition stated immediately. Every word 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?

This is a mutating 6-parameter tool with no annotations and no output schema, so the description needs to cover more than it does. Missing context includes the dryRun default, overwrite behavior, timeout, error handling, and return value, leaving the agent under-informed for safe invocation.

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

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

Schema description coverage is 0%, so the description must compensate, but it only references allowWithEditorOpen and gives no explanation of sourceMap, targetMap, dryRun, overwrite, or timeoutSeconds. The property names hint at their meanings, but the description adds minimal parameter-level value.

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

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

The description states a specific verb ('Duplicate'), a specific resource ('map asset'), and the '/Game/...' path scope. This clearly distinguishes the tool from siblings like unreal_list_assets, unreal_import_assets, and unreal_spawn_actors.

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 choose this tool over alternatives, nor does it mention exclusions or prerequisites beyond the editor-open condition. The editor-open refusal is a usage constraint, not a comparison with sibling 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 behavioral burden and does reveal key traits: animation-only, existing skeleton required, no mesh, exported-time length, and no default sample rate. However, it omits side effects such as overwrite behavior, editor-open requirements despite the allowWithEditorOpen parameter, dryRun semantics, and success/failure outcomes.

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 tightly written sentences front-load the core purpose and pipeline constraints, then mention the post-tuning sibling. There is no filler or redundancy.

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

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

For a 7-parameter mutation tool with no annotations and no output schema, the description is incomplete. An agent would need to guess about dryRun defaults, editor-open restrictions, overwrite semantics, and what a successful import returns. The purpose is clear, but operational completeness 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 only 29%, so the description must compensate. It adds useful context for skeleton (must be existing) and file (animation-only FBX), but it does not explain name, dryRun, timeoutSeconds, or allowWithEditorOpen, leaving several behavior-affecting parameters undocumented.

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

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

The description clearly identifies the action: import an animation-only FBX onto an existing skeleton. It specifies the pipeline constraints (no mesh, exported-time length, no default sample rate) and differentiates itself from broader import tools like unreal_import_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 gives clear guidance by describing the Trekker pipeline and explicitly pointing to unreal_set_asset_properties for post-tuning. It implies when this tool is appropriate, though it does not explicitly exclude mesh imports or name unreal_import_assets as the alternative.

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

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

No annotations are provided, so the description carries the burden. It discloses the import mechanism (AssetImportTask), textureType compression behavior, the repo-local file requirement, and a memory exhaustion warning. It does not cover dryRun defaults or editor-open behavior, but the schema provides those defaults and the description adds meaningful operational risk detail.

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, each carrying essential information. The main action is front-loaded, texture configuration is compactly explained, and the memory warning is a valuable final note. No fluff or repetition.

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

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

For a 4-parameter batch-import tool with no output schema and no annotations, the description gives enough to invoke it correctly: supported input types, destination format, textureType meaning, and operational caveats. The main omission is explicit handling of dryRun and allowWithEditorOpen, but those are clear from defaults and param names.

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% for top-level parameters, so the description must compensate. It explains textureType values and compression behavior, clarifies file must be inside the repo, and implies destination is a /Game path. However, 'name', 'dryRun', 'timeoutSeconds', and 'allowWithEditorOpen' are not described beyond their names and schema defaults.

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

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

States a specific verb ('batch-import'), resource (files into /Game destinations), and supported file types (FBX meshes, PNG/JPG textures, WAV). This clearly distinguishes it from siblings like unreal_import_animation and asset management 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 clear context: use when batch-importing supported asset types into UE. It also gives important operational constraints (files must live inside the repo, chunk large texture batches). It does not explicitly name alternatives or exclusions, but the supported file types and scope make intended usage 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 provided, the description carries the safety burden and meets it by leading with 'READ-ONLY'. It also adds a performance trait ('Cheap') that helps the agent understand the tool's side-effect and cost profile. It does not detail output shape or editor-related behavior, but for a read-only query this is a reasonable level of 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?

Two tight sentences, front-loaded with the most important behavioral signal (READ-ONLY) and a clear resource scope. The second sentence earns its place by giving strategic usage context. No padding or redundancy.

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

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

The description is sufficient for selecting the tool and for the core path/filter invocation, but incomplete for a 7-parameter tool with no output schema. It does not describe return format, pagination/limit behavior, dryRun semantics, timeout, or allowWithEditorOpen. This leaves gaps an agent must guess or probe.

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

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

Schema description coverage is only 14%, so the description must compensate for undocumented parameters. It adds meaningful substring semantics for nameContains and classContains, but leaves limit, dryRun, timeoutSeconds, and allowWithEditorOpen completely unexplained. With 7 parameters and 4 of them semantically dark, the description only partially carries the burden.

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 verb 'query', the exact resource ('asset registry under a /Game path'), and the optional filters (class-name and asset-name substrings). It also signposts this as a discovery tool versus the probe/set siblings, making the tool's role 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 phrase 'Cheap discovery before probe/set tools' explicitly tells the agent when this tool should be used relative to the mutation/probing siblings. It lacks a named list of alternatives or explicit exclusions, but the positioning is clear enough for correct tool selection.

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 disclosure burden and does reveal the key safety trait ('READ-ONLY'), the matching semantics (label OR class, case-insensitive), and the display-name convention. However, it glosses over the fact that 'load a map' can disrupt the current editor session, and it never mentions the 420s default timeout, the maxActors=5 truncation, or dryRun behavior — significant behavioral traits for an agent deciding whether to call this.

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

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

Two sentences, front-loaded with the safety prefix and verb+resource before any detail. The second sentence's anecdote is slightly loose ('tool shape that found...') but earns its place by evoking the output behavior (surfaceing nulls), so there's no real waste.

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 no-annotation, no-output-schema tool with 7 parameters, it covers purpose, matching semantics, and naming semantics but omits the return shape and the behavior of four optional params. An agent cannot predict whether results come as a per-actor map of requested props, how missing props surface, or how long a call may run — material gaps for a tool whose default timeout is 7 minutes.

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

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

Schema description coverage is only 29%, and the description genuinely compensates for the two opaque required params: props are 'editor display names' with examples, and actorMatch matches label OR class case-insensitively. But dryRun, maxActors, timeoutSeconds, and allowWithEditorOpen are documented in neither the schema nor the description, and the last one encodes a non-obvious editor-state interaction.

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

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

States a specific verb+resource with method: 'load a map and read actor properties by their editor display names', backed by concrete examples ('Use Auroras', 'Ultra Dynamic Weather'). The 'READ-ONLY' prefix and 'read back the ACTUAL state' wording clearly distinguish it from write-oriented siblings such as unreal_set_actor_properties and unreal_spawn_actors.

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 a clear context for when to use it — 'read back the ACTUAL state instead of trusting push logs' — pointing at verification-after-pply scenarios, reinforced by the anecdote about finding a dead switch and null reference. It stops short of a 5 because it never explicitly names an alternative tool or states when-not-to-use.

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

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

No annotations are provided, so the description carries the full burden. It discloses headless execution, output filtering with a default marker ('MCP |LogPython'), and sys.argv delivery with the no-whitespace constraint. But it omits a crucial behavioral trait: dryRun defaults to true, yet the description never says the tool runs in dry-run mode by default — an agent expecting real changes would be misled.

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, front-loaded with purpose, and every sentence earns its place: mechanism, arg contract, and output contract. No filler, no repetition of the schema.

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

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

The core contract is well covered: what runs, how args get in, what output looks like. But with no annotations and no output schema, and 6 params, the missing dryRun semantics and the editor-open constraint (allowWithEditorOpen defaults true despite 'headless commandlet') are gaps that could lead an agent to misuse 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 schema description coverage at 33%, the description adds real value for two params: args (delivered via sys.argv, no whitespace allowed) and outputFilter (default marker, regex-based). But three parameters — dryRun, timeoutSeconds, allowWithEditorOpen — go unexplained in both the schema and the description, leaving significant gaps unaddressed.

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

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

States a specific verb ('Run'), a specific resource ('existing python script from the repo scripts/ folder'), and a specific mechanism ('headless commandlet'). This clearly distinguishes it from all siblings (unreal_duplicate_map, unreal_probe_actor, etc.), none of which run python scripts.

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 context: the script must already exist in scripts/, and the tip 'have your script unreal.log() what matters' is actionable guidance for getting useful output through the filter. However, there is no explicit when-to-use versus alternatives or when-not-to-use statement.

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 behavioral disclosure burden. It openly states that it kills the game, steals foreground focus while capturing, is Windows-only, and is serialized with all other runs. That is strong transparency beyond the raw schema, though it does not describe failure modes or what happens on dryRun.

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 a dense, front-loaded workflow and no repetition. Every clause adds information about what the tool does, what it returns, or what constraints apply.

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

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

For a 7-parameter tool with no output schema and no annotations, the description gives strong orientation but is not complete: it omits dryRun semantics, resolution controls, and timeout defaults. The schema provides ranges and defaults, but the description does not tie them into the workflow, so an agent still has to infer important execution behavior.

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

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

Schema description coverage is only 14%, so the description is expected to compensate. It does clarify map, vantages/BugItGo, console commands, and PNG output, but resX/resY, dryRun, settleSeconds, and timeoutSeconds are not meaningfully explained. The dryRun default-true behavior is especially consequential and undocumented in prose, leaving a critical gap.

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

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

The description names a concrete workflow: launch a -game map instance, wait for settle, teleport through vantages, run console commands, screen-capture, kill the game, and return PNG paths. This is far more specific than a generic 'takes screenshots' and clearly distinguishes it from the asset-editing and actor-editing sibling tools.

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

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

It says this is the pattern every visual verification was built on, which gives a clear context for when to call it, and it adds actionable constraints: Windows-only, steals foreground focus, and serialized. It does not explicitly name alternatives or when-not-to-use conditions, so it stops short of a 5.

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

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

With no annotations, the description carries the full burden, and it does disclose mutation, saving, the editor-open gate, and safe literal conversion. But the unconditional 'then SAVE the map' is misleading given dryRun defaults to true; the description does not state that saving only occurs when dryRun=false, which is a significant behavioral caveat.

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 dense sentences with no wasted words; the core action and side effect are front-loaded, and the mutating/refusal condition follows naturally.

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 7 parameters, nested properties, no output schema, and no annotations, this description is too thin to fully support correct invocation. An agent can infer param names but not matching semantics, the maxActors safety cap, the dry-run/save relationship, or the response/error behavior.

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

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

Schema description coverage is 0%, so the description must compensate. It clarifies map, actorMatch, properties, and allowWithEditorOpen, but it does not explain dryRun, maxActors, or timeoutSeconds, and it misrepresents dryRun's role as the save switch.

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 ('Set... properties') and resource ('matching actors in a map') and calls out the consequential save. It differentiates at a surface level from asset-focused siblings like unreal_set_asset_properties, though 'editor-displey-name properies' is ambiguous and the schema suggests arbitrary actor properties.

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 useful operational context: the operation is mutating, it saves the map, and it refuses while an editor is open unless allowWithEditorOpen. However, it does not explicitly state when this tool should be chosen over similar siblings, nor does it explain that dryRun should be used for previews; usage guidance is mostly implied.

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

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

No annotations are provided, so the description carries the burden, and it does disclose important behaviors: the tool auto-loads a /Game/... string as an object reference and it saves the asset after setting properties. It also states a meaningful limitation (no struct/array support). It does not mention dryRun's effect or return behavior, which keeps it from a 5.

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

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

Two tightly written sentences with no filler. The main behavior and value types are front-loaded, followed immediately by the critical exclusion and alternative. 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?

For a mutation tool with no annotations and no output schema, the description covers the core operation, save side effect, value coercion, and unsupported types. However, it omits dryRun semantics entirely—especially since dryRun defaults to true, which could crucially affect whether the asset is actually saved. That is a real gap for correct invocation.

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

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

Schema description coverage is only 17%, so the description needs to compensate, and it does for the central 'properties' parameter by clarifying allowed scalar types and the /Game/ string-to-object-reference coercion. It also explains why struct/array values are invalid. It doesn't explain dryRun, but the most complex parameter is well covered.

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 and resource: setting simple-valued properties on an asset or a Blueprint's class defaults and then saving. It also distinguishes itself by explicitly calling out the unsupported struct/array case and naming unreal_run_python_script as the alternative, so an agent can disambiguate it from nearby asset/actor tools.

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

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

It states when to use the tool: for simple-valued number/bool/string properties on assets/class defaults. It also gives a clear when-not and alternate: struct/array properties are NOT supported, so use unreal_run_python_script instead. This is explicit routing guidance with named 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 present, the description carries the full disclosure burden. It does disclose the key side effect—'Writes inside the repo'—and 'regenerate' implies overwriting the existing markdown. However, it does not mention other behavioral traits such as requiring Unreal to run, potential long runtime, or what happens if the editor is open, despite there being parameters related to those behaviors.

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 compact sentences with no filler, front-loading the action and the payload details. Every clause earns its place.

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

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

For a tool with five parameters, no output schema, and no annotations, this description is too thin. An agent can infer a default invocation, but it cannot assess dry-run behavior, timeout constraints, editor-safety implications, or what the tool returns, leaving significant gaps for correct 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?

Schema description coverage is only 20%, so the description must compensate, but it explains almost nothing about the parameters. It implies the map path and that output is written to a file, but dryRun, outFile, timeoutSeconds, and allowWithEditorOpen are not semantically clarified beyond their names and defaults.

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

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

The description names a specific verb ('Regenerate') and a specific resource ('level snapshot markdown'), and even details what the snapshot contains (label, class, transform, tags for every actor). This clearly distinguishes it from siblings like uds_inspect_level, which is about inspecting rather than regenerating a 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 when the tool should be used by referencing CLAUDE.md and the authoritative snapshot status, but it does not explicitly state conditions like 'use when the snapshot is stale' or contrast with alternatives such as uds_inspect_level for read-only inspection. Usage context is present but largely inferred.

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

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

With no annotations provided, the description carries the full disclosure burden. It does well by warning about the destructive 'clearTag' behavior, stating idempotent re-run behavior, and explaining the headless physics limitation. The only imprecision is that 'and save' is not qualified against the schema's dryRun default of true, which could slightly mislead an agent expecting persistence by default.

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

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

The description is compact, front-loaded with the core purpose, and every sentence adds operational value. The 'NOTE:' gives a critical environment constraint without burying it, and no filler or redundant phrasing is present.

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 mutating tool with no output schema and no annotations, the description covers the required inputs, source formats, deletion side effect, idempotence, and the critical Z-coordinate limitation. The dryRun default true is visible in the schema, so the miss is minor, but a sentence tying 'save' to dryRun=false would make invocation expectations fully unambiguous.

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

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

Schema description coverage is only 17%, so the description must compensate. It usefully explains supported source types, required label/location, optional rotation/scale/tags, and the clearTag parameter's deletion semantics. It leaves dryRun, timeoutSeconds, and allowWithEditorOpen to the schema, but the core actor-entry parameters are made meaningful.

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

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

The opening sentence 'Batch-spawn actors into a map and save' names a precise operation on a specific resource, and clearly distinguishes this tool from the sibling tools, none of which are about spawning actors. It further specifies accepted source types ('/Game' asset or '/Script/Module.Class'), so an agent can recognize both the action and the domain immediately.

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

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

The description gives clear operational context: it is for batch-spawning actors into a map, with explicit note that headless commandlets have no physics scene and therefore require explicit Z. It does not explicitly name alternative tools or exclusions, but the tool's purpose is distinct enough that the usage context is reasonably 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 fully carries the behavioral burden. It discloses side effects (setting driver, launching game, killing game, restoring original driver), the focus-sensitive behavior, and the NOFOCUS failure signal. This is notably transparent for a tool that mutates game 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?

Two sentences precisely describe the full workflow and the critical operational caveat. The phrase 'One-call arc verification' is front-loaded, and every clause contributes meaning 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 gives a strong operational narrative, but for a 7-param tool with no output schema and no annotations it is incomplete: it does not explain return values, output locations, the effect of dryRun, or the role of timeoutSeconds/fixedTimerSeconds. The existing prose covers workflow but not enough of the input/output contract.

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

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

Schema description coverage is only 29%, and only 'map' and 'profile' have schema docs. The description mentions the profile driver and fixed timer conceptually, but never explains resX,resY, dryRun, timeoutSeconds, or fixedTimerSeconds. It leaves most parameters underspecified and does not compensate for the low 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 specifies a clear multi-step workflow: it sets a TOD profile's driver, launches the map, detects run start, captures phase-named screenshots, kills the game, and restores the original driver. This goes beyond the name and clearly identifies the tool's purpose, distinguishing it as an orchestrated verification workflow rather than a simple screenshot utility.

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 useful usage context: it is a 'One-call arc verification' tool and explicitly warns that the machine should be idle-ish because captures are focus-verified and report NOFOCUS if focus is lost. It does not explicitly name alternative tools or when-not, but the environment prerequisite provides actionable guidance.

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