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

With no annotations, the description carries the full behavioral burden and does well: it discloses atomic transaction semantics, compilation outside the transaction, read-back verification, and rollback on failure. It stops short of explaining permissions, asset-lock behavior, or how errors are surfaced, 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?

The English sentence is front-loaded and dense with useful routing information, and the Chinese sentence mirrors it for bilingual clarity. The bilingual duplication makes it slightly longer than strictly necessary, but nothing is irrelevant.

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, nested-object mutation tool with no annotations and no output schema, the description covers the critical behavioral contract: atomicity, compile-outside-transaction, read-back verification, and rollback. It could say more about failure reporting and asset-lock interaction, but it is largely complete for correct invocation.

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

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

Schema coverage is 100%, so the schema already documents bp_path, replace, graph_spec, session_id, and idempotency_key. The description adds useful context about constructing graph_spec via ue5_search_blueprint_nodes, but it does not add syntax or format detail beyond the schema, so the high-coverage baseline of 3 is appropriate.

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

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

The description states a specific verb and resource: a declarative whole-graph write that builds/wires a GraphSpec atomically. It clearly distinguishes itself from node-level siblings by naming ue5_connect_pins and ue5_delete_node as surgical-fix-only tools.

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

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

It explicitly says this is the main path for graph logic, instructs the agent to build the spec from ue5_search_blueprint_nodes first, and confines ue5_connect_pins / ue5_delete_node to surgical fixes. That is clear when-to-use and when-not-to-use guidance.

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

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

No annotations are provided, so the description carries the full burden. It clearly discloses the key behavior: atomic rollback if any blueprint fails. This is the critical behavioral trait. It doesn't mention other possible behaviors (e.g., persistence, return format), but for a batch operation the atomicity is the dominant concern, and it is well-covered.

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

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

Two sentences with zero waste. The action and atomicity are front-loaded, and the usage guidance follows immediately. No redundant or filler content.

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

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

For a tool with a single well-described parameter and no output schema, the description covers purpose, usage, and the key behavioral guarantee (atomicity). It references the sibling tool's spec for parameter details, which is sufficient. Nothing essential is missing for an agent to decide whether to use it.

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

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

Schema coverage is 100%: the parameter 'blueprints' has a description that already explains it as an array of build specs referencing another tool's schema. The description adds no new parameter information beyond that reference, so baseline 3 is appropriate.

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

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

Description states a specific verb ('Create') and resource ('multiple Blueprints') with a defining feature ('atomic batch'). It distinguishes itself from the sibling ue5_build_blueprint by emphasizing the batch aspect, making its purpose unambiguous.

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

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

Explicitly says 'Prefer ue5_build_blueprint unless multi-asset atomicity is actually needed', giving a clear when-to-use and when-not-to-use directive, and names the alternative tool. This fully routes the agent.

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 burden and does well: it discloses atomicity, that assets created by the call are rolled back on any failure, and that compile is optional via compile_after. It omits permissions/lock semantics (only partially hinted by session_id) and gives no indication of cost or runtime for large specs.

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

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

Front-loaded with purpose and the atomicity guarantee, then a compact field enumeration with no filler sentences. The single dense run-on spec list is efficient for machine reading but not maximally scannable.

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

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

For a complex nested-spec creation tool with no output schema, it covers the creation contract, rollback behavior, and spec shape thoroughly. The main gap is that it never says what a successful call returns (asset path, node GUIDs for follow-up calls), which matters because node references downstream need GUIDs.

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 only says 'Blueprint build spec (see description for fields)', so the description is the sole source of meaning and it delivers: full field list with nested structure, alternate accepted names (blueprint_name|name, event_name|name), and the node-reference rule that 32-hex GUIDs are recommended over titles. This goes well beyond what the structured schema provides.

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

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

States a specific verb and resource ('Create a Blueprint') and adds the key differentiator 'from scratch in one atomic call', which separates it from siblings like ue5_apply_blueprint_graph and ue5_compile_blueprint. It also enumerates exactly what is created (asset, variables, components, interfaces, events, functions, connections).

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 'from scratch' framing makes the intended context clear: full blueprint creation rather than graph edits on an existing asset. It does not explicitly name alternatives or exclusions (e.g., use ue5_apply_blueprint_graph to modify an existing blueprint), so the agent must infer the boundary rather than being routed by name.

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

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

No annotations are provided, so the description must carry the full behavioral burden. It implies a read-only operation ('check health', 'confirm reachable') and specifies the return structure, but does not explicitly state that it makes no modifications, nor does it mention failure modes or error handling. This is acceptable for a health check but leaves some behavioral aspects implicit.

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

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

The description is two concise sentences (plus a bilingual translation) that front-load the purpose and return data. Every sentence earns its place, with 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?

For a tool with no parameters and no output schema, the description covers the essential aspects: what it does, what it returns, and when to call it. It could optionally mention behavior if the editor is unreachable, but the description is adequate for its simplicity.

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

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

The tool has zero parameters and the schema is fully covered, so the description does not need to elaborate on parameter meanings. The baseline for zero parameters is 4, and the description adds no unnecessary parameter details.

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 checks bridge/editor health and specifies the exact data returned: engine version, project name, and loaded bridge API list. It also positions itself as the first call before any write operation, distinguishing it from diagnostic tools like ue5_run_diagnostics.

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 instructs to call this first to confirm editor reachability before write operations, providing clear when-to-use guidance. However, it does not mention any alternative tools (e.g., ue5_run_diagnostics) or when not to use it, so it lacks explicit exclusion criteria.

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 does well: it enumerates returned fields (asset, function, node_name, node_guid, pin hint, pitfall_ref/fix_hint), states that unparseable fields are null rather than fabricated, and warns that fix_hint is advisory. It omits the side-effect/cost profile of compiling — whether it mutates assets, blocks, or is safe to repeat — which matters for a compile operation.

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

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

Front-loaded with the core action and output shape, then the routing rule, then a caveat — a sensible order with no filler. Slightly long due to the full bilingual duplication, which is conventional but does not shorten the prompt footprint.

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

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

The tool has no annotations and no output schema, so the description must explain the return contract — and it does, listing every diagnostic field and the null-instead-of-fabricated guarantee. What is missing is confirmation of compile side effects and whether the blueprint must be saved/dirty beforehand.

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

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

Schema coverage is 100% with a single required bp_path already documented with an example path in the schema. The description adds no parameter-level detail beyond that, so the baseline 3 applies — the schema does all the work.

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

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

States a specific verb and resource ('Compile a Blueprint') plus the differentiating output ('return structured compiler errors'), and names the sibling it supersedes, ue5_compile_blueprint. An agent can distinguish it from the plain compile tool without opening either schema.

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

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

Explicitly says 'Use this instead of ue5_compile_blueprint when a compile fails and you need to locate and fix the offending nodes' — naming both the alternative and the selecting condition. No inference required to route between the two compile 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?

Since no annotations are provided, the description carries the full burden of behavioral disclosure. It adds meaningful behavioral context: it reads back the compile status, scans logs for error patterns, and guarantees that failures are reported with log evidence rather than fake success. This goes well beyond the bare schema and helps an agent trust and interpret the result.

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 front-load the core action and follow with a critical reliability guarantee. There is no filler, and the bilingual repetition is minimal and acceptable. 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 single-parameter tool with no output schema, the description is largely complete: it states the operation, the expected result behavior, and the reliability guarantee. It could benefit from explicitly describing the returned status/log format, but that gap is minor given the tool's simplicity.

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

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

Schema description coverage is 100%, and the bp_path parameter already includes an example path (/Game/BP_Test). The tool description itself does not add extra parameter-level meaning, but none is needed because the schema fully documents the 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 action: compile a Blueprint, read back compile status, and scan logs for error patterns. It is specific and unambiguous about the resource (Blueprint), but it does not explicitly differentiate itself from the similarly-named sibling ue5_build_blueprint, leaving possible confusion about which tool to choose.

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 its use case: compiling a Blueprint and getting a truthful status. However, it provides no explicit when-to-use guidance, exclusions, or comparisons with alternatives like ue5_build_blueprint, so the routing decision is left mostly 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 full burden of behavioral disclosure. It does disclose the verification steps (existence, type compatibility, read-back) and the fail-loud behavior for ambiguous titles, which is valuable. However, it does not mention side effects such as whether the change persists, whether the blueprint is saved, or any return value. For a mutation tool, this is a significant gap, but the verification details provide some transparency beyond a simple 'connect' statement.

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 in English plus a Chinese translation, with no fluff. The primary action is front-loaded, followed by the key verification behavior and a specific usage hint. Every sentence adds information, and the structure is efficient and scannable. The bilingual duplication is a stylistic choice, not a 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 mutation tool with no output schema, the description should cover side effects, prerequisites, and return behavior. It covers the verification and failure modes but does not mention whether the blueprint needs to be loaded, whether connections are immediately applied, or what happens on success. Given the tool's complexity (array of connections with node/pin references), this is incomplete. However, the verification details mitigate some gaps, so a 3 is appropriate.

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 already provides descriptions for both parameters (blueprint_path and connections) with 100% coverage, giving a baseline of 3. The description adds meaningful value by explaining node reference formats (titles or 32-hex GUIDs) and the rejection of ambiguous titles, which is not present in the schema. This extra detail helps agents correctly specify the connections array, raising the score above baseline.

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

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

The description clearly states the tool's primary action ('Connect pins') and adds a specific differentiator: triple topology verification (existence, type compatibility, read-back). This distinguishes it from sibling tools like ue5_disconnect_pin and ue5_read_connections, which have obviously different purposes. The verb+resource combination is precise and unambiguous.

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

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

The description provides parameter-level guidance (e.g., 'use GUIDs when titles repeat') but does not explicitly state when to use this tool versus alternatives like ue5_disconnect_pin or ue5_read_connections. It implies the use case for connecting pins but lacks explicit exclusion or alternative selection criteria. The guidance about ambiguous titles is useful but is focused on parameter usage rather than 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 provided, the description carries the safety transparency burden. It discloses the destructive action, reference checks, post-delete read-back verification, and the save scope. It could additionally explain behavior when references are found or whether deletion is reversible, but it provides meaningful operational 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?

One compact bilingual sentence front-loads the action and then states two important behavioral caveats. Every clause earns its place without repetition beyond intentional localization.

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 two-parameter destructive tool, the description covers the action, the verification behavior, and the persistence side effect. It does not specify return values or failure semantics, but 'read-back verification' implies outcome checking and no output schema is declared.

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

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

The input schema has 100% description coverage for both asset_path and max_attempts, so the schema already documents the parameters. The description adds no parameter-level detail, which meets the baseline expectation when schema coverage is high.

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 an explicit verb ('Delete') and resource ('asset'), and adds distinguishing behaviors ('reference checks and read-back verification'). It clearly separates this tool from related operations like ue5_delete_node or ue5_save_asset.

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

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

The intended use is obvious: delete an asset. It also provides an important contextual caveat about save scope. It does not explicitly name alternatives or state when not to use it, but the sibling set makes the domain clear.

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

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

With no annotations, the description carries the full behavioral burden. It discloses the destructive nature (delete) and introduces dry_run as a safe reference-checking mode, which is valuable risk context. It omits details like irreversibility, what happens to connected pins, or failure behavior when references exist, but the core safety pattern is well covered.

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

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

The English description is a single efficient sentence with the safety caveat front-loaded. The appended Chinese translation duplicates the same content, adding length without new information, which prevents a top score.

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?

Parameter semantics are fully covered by the schema, and the description adds the key dry_run safety cue. However, there is no output schema and the description does not explain expected return values, failure modes, or consequences when dry_run detects references, leaving an agent to guess at post-call 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 100%, so the baseline is 3. The description repeats the dry_run behavior already documented in the schema ('Check references only, do not delete') and adds no new parameter-level semantics for node_id or blueprint_path.

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

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

The description uses a specific verb-resource pair ('Delete a Blueprint node') that clearly distinguishes this tool from sibling ue5_delete_asset by resource type. However, it does not explicitly name the sibling or contrast its scope, so it stops short of full differentiation.

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

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

Provides clear operational guidance: use dry_run=true first for nodes that may be referenced elsewhere. This is actionable context for safe invocation, though it does not address when to choose this tool over alternatives like ue5_delete_asset or ue5_disconnect_pin.

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 behavioral burden. It does add useful context beyond the bare action by stating 'verified against live topology', implying validation against current graph state. However, it omits side effects such as irreversibility, persistence implications, or impact on dependent nodes.

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 front-loads the action and object, then adds the verification qualifier. The bilingual text is compact and does not repeat schema content or add 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?

No output schema or annotations exist, yet the description does not explain return values, failure semantics, or whether changes require a subsequent save via save_asset. For a destructive topology mutation, this is a meaningful gap.

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

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

Input schema covers all three required parameters with meaningful descriptions, so the baseline is 3. The description adds no extra parameter-level detail, but none is strictly needed given the 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?

Description names a specific verb ('Disconnect') and precise resource ('every connection attached to one pin of a node'), which distinguishes it from sibling tools like connect_pins, read_connections, and delete_node. The live-topology qualifier further sharpens 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?

No explicit guidance on when to use this tool versus alternatives. The agent must infer from sibling names that connect_pins creates links and read_connections inspects them; the description itself provides no conditions, exclusions, or routing hints.

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 does disclose the safety envelope: whitelist-only execution, fail-loud rejection on unknown commands, and that arguments are 'less validated' than dedicated tools. The remaining gap is that it never says the dispatched commands can be mutating (undo/PIE/asset writes), so side-effect risk is only implied by the command catalog.

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 critical routing guidance ('prefer the dedicated tool', 'last resort') is front-loaded and each of the first three sentences adds information. The closing bilingual line partially repeats that content and contains garbled mixed-script text ('fail-loud拒绝'), which is wasted space.

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 generic dispatch tool with no output schema, the description covers scope, discovery path, error behavior, and validation caveats well enough to call it correctly. The one unaddressed item is what a call returns, which varies per underlying command and is left 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 coverage is 100%, so the baseline is 3; the description still adds real value by telling the agent where to obtain a valid `command` value (ue5_tool_search) and by characterizing `params` as less-validated free-form arguments. session_id and idempotency_key semantics are left entirely to 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?

Names a specific verb and resource ('run any whitelisted bridge command by name') and quantifies scope as the 'full 101-command surface,' explicitly including capabilities with no dedicated tool (materials, UMG widgets). An agent can immediately tell this apart from the dedicated 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?

Explicitly states the selection rule: 'Prefer the dedicated tool whenever one exists' and labels itself 'the last resort' — a clear when-not-this-tool clause. It also routes the agent to ue5_tool_search{query} for exact command names rather than guessing.

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. It conveys a non-mutating discovery intent, states the content-folder default, and explains the recursive flag's subfolder walk. It omits output-format details but does not mislead.

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 English text is compact and front-loaded: primary action first, then usage context, then the recursive note. The Chinese translation adds some duplication but serves bilingual users without becoming bloated.

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 two-parameter list operation, the description covers the root default, recursion behavior, and discovery purpose, which is enough to invoke correctly. The lack of an output schema and annotations makes return-shape details a minor gap, but not a blocking one.

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

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

The input schema already covers both parameters fully, so the baseline is 3. The description adds the /Game default and restates recursive behavior, but it does not substantially extend what the schema already documents.

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 phrase 'List asset paths under a content folder' states a concrete verb and resource, and 'Use to discover what exists before reading or editing' positions it as a discovery tool. This clearly distinguishes it from sibling reader/editor tools such as ue5_read_blueprint or ue5_delete_asset.

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

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

'Use to discover what exists before reading or editing' gives a clear workflow context for when to call this tool. It does not explicitly name alternatives or state when not to use it, so it stops short of a full 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?

No annotations are provided, so the description carries the full disclosure burden. It discloses the runtime-only nature (UEDPIE_0_ paths), the filter combination possibilities, and result capping via limit. The phrasing 'and/or' leaves filter combination semantics slightly ambiguous, but for a passive enumeration the behavioral surface is well covered.

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

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

Two dense sentences with the core action and scope front-loaded in sentence one, then a compact summary of filtering behavior. The short Chinese suffix is a consistent bilingual pattern across the tool family and does not add noise.

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 low-complexity tool with three optional parameters and no output schema, the description covers scope, filters, and limit. Minor gaps remain: it never states what the returned entries look like (names vs paths) or what happens without an active PIE session, but these are modest for an enumerate operation.

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

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

Schema description coverage is 100%, so the baseline is 3. The description mostly restates the schema ('Filter by actor_class and/or name_filter substring; limit caps the result count') rather than adding new meaning beyond confirming the filters can be combined.

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 ('Enumerate') and resource ('live Actors in the PIE world'), and adds the distinctive detail that runtime paths contain UEDPIE_0_. This clearly separates it from ue5_list_assets, which targets content-browser assets rather than runtime 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 scopes the tool to live PIE world objects, giving an agent clear context for when to call it (inspecting a running Play-In-Editor session). It stops short of explicitly naming alternatives or stating exclusions such as 'not for asset enumeration', so it earns a 4 rather than a 5.

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

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

With no annotations provided, the description carries the behavioral burden and does so reasonably: it states the tool is read-only and safe to call any time, and it says it returns structured JSON. It does not discuss performance or output shape in depth, but for a read-only tool the key safety profile is covered.

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

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

The description is front-loaded and appropriately sized, with the level semantics stated before the read-only note and return format. The repeated Chinese translation adds some redundancy without new information, keeping it from a 5.

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

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

Given no output schema and no annotations, the description supplies the important context: level meanings, read-only safety, and JSON return format. It stops short of describing the exact JSON shape, but the level breakdown gives enough structure for an agent to call it correctly.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds useful meaning beyond the schema by defining what each level value contains (L1 class info/variables/CDO, L2 node graph/connections, full both), which is central to invoking the tool 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 names a specific verb and resource ('Read a Blueprint asset') and explains the level-based scope (L1 class info/variables/CDO, L2 node graph/connections, full). It is clear what the tool does, but it does not explicitly differentiate itself from siblings such as ue5_read_nodes or ue5_read_connections, which overlap with L2.

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

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

The description implies usage through the level definitions and states it is safe to call any time, but it does not say when to choose this tool over alternatives like ue5_read_nodes or ue5_read_connections. The agent must infer the appropriate context from the level descriptions alone.

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 supplied, so the description carries the burden. 'Read' implies a non-mutating operation and the topology subject tells the agent what data comes back conceptually, but there is no statement about scoping behavior when graph_name is omitted, response size on large graphs, or permissions. Adequate but with clear gaps for an unannotated tool.

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

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

The English portion is two tight, front-loaded sentences with no waste. The full bilingual duplication roughly doubles length without adding information for an English-reading agent, which keeps it from a 5.

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

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

With no annotations and no output schema, the description must stand in for return-value shape. Saying it returns connection topology is directionally useful, but the actual structure (source/dest pin and node identifiers, list nesting) and behavior on missing graphs or empty results are unstated, leaving an agent to discover the response shape by calling it.

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

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

Schema description coverage is 100% and all three parameters are documented in the schema, including the 'omit to search all graphs' semantics for graph_name. The description adds no parameter meaning beyond that, so the baseline 3 applies.

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

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

The description names a specific verb and resource: reading the Blueprint's connection topology, explicitly clarified as 'which pin connects to which node/pin'. That distinguishes it cleanly from ue5_read_nodes (node inventory) and the write-side ue5_connect_pins/ue5_disconnect_pin siblings.

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

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

'Use to verify wiring before and after edits' gives a clear usage context tied to a workflow moment rather than just restating the purpose. It stops short of naming alternatives or exclusions (e.g. preferring ue5_search_blueprint_nodes for locating a pin), so it is strong but not complete routing guidance.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It explains the cursor semantics (cursor=0 vs cursor>0) and filtering behavior, which are non-obvious. It doesn't mention output format or error handling, but it's a read operation with no side effects.

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

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

The description is two concise sentences in English followed by a bilingual summary. It front-loads the core behavior (cursor semantics) and then adds the filter and use case. No fluff or redundant details.

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

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

Given the tool has 4 optional parameters, no output schema, and no annotations, the description covers the main behavioral aspects: cursor behavior, filtering, and purpose. It implies the return value (log lines) through phrases like 'returns the tail'. It doesn't mention pagination limits or error cases, but for a read-only diagnostic tool it is sufficiently complete.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaningful semantics beyond the schema by explaining the cursor logic (tail vs incremental) and how filtering works. This clarifies the interaction between parameters, which the schema alone 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 reads the UE log, explains the cursor-based behavior (tail vs incremental), and mentions filtering by category/pattern. It distinguishes itself from sibling tools like ue5_check_health or ue5_list_assets by focusing specifically on log reading.

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

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

The description explicitly states 'Use for self-service cross-checks of any operation', providing a clear when-to-use scenario. It doesn't mention when not to use it or name alternative tools, but the purpose is specific enough that an agent can infer it's the log-reading tool.

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

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

No annotations are supplied, so the description bears the full burden. It establishes that this is a non-mutating read and lists the returned fields, but it says nothing about cost or result volume when graph_name is omitted and every graph is scanned, nor about permissions or limits on large Blueprints. The scope semantics are covered; the operational traits are not.

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 returned data is front-loaded in the first clause, followed by the graph_name caveat and the workflow tip, which is good ordering. The bilingual restatement nearly doubles the length without adding information, which is the only 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 three-parameter read tool with full schema coverage and no output schema, the description covers what is returned and how graph_name scoping works — enough to call it correctly. The unexplained 'fields' parameter and the unqualified all-graph search cost are the remaining gaps.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters, making 3 the baseline. The description re-states the graph_name omission behavior (redundant with the schema) and never mentions the 'fields' projection parameter, so it adds little beyond structured data.

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 gives a specific verb and resource ('Read Blueprint nodes') and enumerates the returned data ('titles, positions, GUIDs and pin defaults'), so an agent knows exactly what it gets. It does not, however, distinguish itself from the sibling ue5_search_blueprint_nodes or ue5_read_blueprint, leaving genuine overlap unresolved.

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 a concrete workflow constraint — 'Use before connecting pins so you have the GUIDs' — which tells the agent when in a sequence to call it. The graph_name omission is also framed as a search-all behavior. There is no explicit when-not or named alternative, which keeps it from 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 full burden for behavioral disclosure, but it only repeats the verb 'read' and the schema's note about empty property_name. It does not state prerequisites (e.g., a running PIE session), error behavior, or explicit non-mutating guarantees beyond the word 'read'.

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 English text is a compact two-sentence description: the first sentence front-loads the core function and list-candidates behavior, and the second adds a useful usage scenario. The Chinese is a translation, not extra 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?

The description omits important operational details such as whether an active PIE session is required and what the tool returns (property value vs. a list of names). With no output schema or annotations, these gaps leave the agent to infer critical calling context, though the tool is simple enough that the core behavior is clear.

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

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

The input schema already provides 100% description coverage for both parameters, including the 'empty = list candidates' behavior for property_name. The description adds no new semantic meaning beyond the schema, so it stays at the baseline of 3.

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

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

The description states the specific verb 'Read', the resource 'runtime Actor property', and the context 'in PIE', and clearly distinguishes a special mode where omitting property_name lists candidate properties. This differentiates it from sibling tools like ue5_read_pie_state and ue5_list_pie_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?

It provides a concrete use case: 'Use this to prove game logic ran (e.g. health changed after a pickup).' This gives the agent clear context for when to invoke the tool, though it does not mention alternatives or exclusions.

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

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

With no annotations, the description carries the behavioral burden. It communicates that the tool is a read/poll operation and that it should be checked before runtime reads, but it does not disclose behavior when PIE is not running, return formatting, or any failure semantics. Some useful context is added beyond the tool name, but significant behavioral details remain implicit.

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

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

The description is front-loaded with the core purpose and usage guidance in two short clauses. The bilingual repetition adds some length without new semantic content for an English-reading agent, but the overall structure remains compact and scannable.

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

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

The description provides enough context for a zero-argument polling tool: it lists the state fields and explains when to poll it relative to ue5_start_pie. Since there is no output schema, it could have specified value types or non-PIE behavior, but the names are self-explanatory and the workflow cue covers the main use case.

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 an empty input schema, so there are no parameter semantics to explain. Per the baseline rule for zero-parameter tools, this is fully adequate; no parameter documentation 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 states a specific verb ('Read') and resource ('PIE state') and enumerates the exact data exposed (is_playing, world name, paused, game time). This clearly distinguishes it from siblings like ue5_read_pie_property, which targets actor properties rather than the overall PIE session state.

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 explicit timing guidance: 'Poll this after ue5_start_pie before reading runtime actors/properties.' This tells an agent when in the workflow to call it, though it does not explicitly name alternatives or state when not to use it.

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

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

No annotations are present, so the description must disclose behavior itself. It discloses the default stop-on-first-failure behavior and the whitelist restriction on commands, but does not discuss side effects, return format, or permission implications, which matters for a tool that executes commands.

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 and usage guidance are packed into three short clauses, with no filler. The bilingual repetition is mild but keeps each version compact.

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 two-parameter batch tool, the description covers selection and default failure behavior, but the absence of an output schema means the agent is still left without information about what the call returns (per-step results, logs, or aggregate status) or whether successful steps are committed. This is a substantive gap for a batch executor.

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

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

Schema coverage is 100%, so a baseline of 3 applies. The description adds meaning by restricting command values to a whitelist and emphasizing that the steps array represents an ordered multi-step sequence, which is not fully explicit in the schema.

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

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

The description opens with a specific verb and resource ('Execute a whitelisted-command batch') and clarifies it is a multi-step task in a single round trip. It also contrasts with single-operation tools, so an agent can distinguish this from the many sibling execution tools.

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

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

It explicitly says this tool is for sequences and that for a single operation the dedicated tool should be preferred. It does not name the specific sibling (e.g., ue5_execute_command), but the sequencing-vs-single-operation criterion is clear.

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

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

No annotations are provided, so the description must carry the full behavioral disclosure burden. It states the tool 'runs' diagnostics and outputs a matrix, but does not mention whether the operation is read-only, has side effects, requires permissions, or is safe to invoke at any time. This is a significant gap for a tool that executes something.

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 concise sentence (with a bilingual repetition) that front-loads the core purpose and then gives usage conditions. Every word contributes value, and there is no superfluous 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?

With no parameters and no output schema, the description must at least explain the return content. It mentions 'complete C++ API method matrix and any missing critical APIs,' giving an idea of the output, but it does not specify the format, size, or how to interpret the results. It also omits any warnings or prerequisites, leaving the agent with incomplete guidance for a diagnostic tool that could produce a substantial report.

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 an empty schema, so there are no parameter semantics to clarify. The description adds nothing about parameters, but none is needed; the baseline of 4 applies because the schema is fully covered (100% coverage with no params).

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

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

The description clearly states the tool's function: running full bridge diagnostics that produce a complete C++ API method matrix and identify missing critical APIs. This specific verb+resource differentiates it from sibling tools that perform concrete operations like checking health or reading 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?

It explicitly provides triggers: use when a tool fails with an API-missing error, or after upgrading/replacing the bridge DLL. This gives the agent precise conditions for invocation, leaving no ambiguity about when this diagnostic tool 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?

No annotations are provided, so the description carries the full behavioral burden. It does disclose meaningful traits: writes to disk, only_if_is_dirty skips clean packages, and saves are scoped to the asset's own package. It does not mention failure behavior or whether an asset must be loaded first, but the core behavioral profile is clear.

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

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

The English portion is compact, front-loaded, and contains no filler. The Chinese repetition of the same information adds length and does not provide new semantics for an AI agent, so it prevents a perfect conciseness score.

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 two-parameter save operation with no output schema, the description covers the essential behavior: what is saved, the dirty-check condition, and the scope boundary. It is complete enough for an agent to invoke correctly, though return or error behavior is not described.

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

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

Schema description coverage is 100%, so the baseline is 3. The description reinforces only_if_is_dirty semantics and adds the package-scoping guarantee, but it does not add meaningful detail about asset_path beyond what the schema's example already provides.

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

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

The description opens with a specific verb and resource ('Save an asset to disk') and immediately clarifies the scope: it saves only the asset's own package and never triggers a whole-project save. This makes the tool's purpose unambiguous and distinguishes it from global save or build operations among the siblings.

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

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

The description implies usage context by explaining the dirty-only save option and the single-package scope, but it never explicitly states when to prefer this tool or names an alternative for project-wide saves. The 'never triggers a whole-project save' statement is a useful exclusion, but the when-to-use guidance is left mostly implicit.

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

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

With no annotations, the description carries the full burden and does well: it discloses the return payload (image block + saved_path / camera_used provenance), a side effect (PNG saved for the dashboard), and failure behavior (fail-loud when PIE is not running). It doesn't state cost, latency, or whether capture disturbs editor state, leaving a small gap.

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

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

Front-loaded with purpose and workflow, then source semantics, then return values — a sensible ordering with no filler sentences. The piped, telegraphic phrasing and the duplicated bilingual tail make it denser than ideal but nothing is wasted.

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

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

For a 5-parameter tool with a nested camera object and no output schema, the description covers sources, return shape, provenance, and the fail-loud precondition — enough for correct invocation. The 768px default and the Pillow dependency for annotate are handled by the schema, so the remaining omission is minor.

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

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

Schema coverage is 100%, so every parameter is already documented, including the camera-required-for-agent_camera constraint. The description restates those same facts rather than adding new meaning (e.g. valid pitch/yaw/roll ranges or how annotate interacts with Pillow availability), so it sits at the baseline.

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

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

States a specific verb+resource ('Screenshot for visual self-check') and enumerates the three capture sources with their semantics, so an agent can tell exactly what it gets. No sibling tool in the list overlaps with screenshotting, so differentiation is implicit but 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 'edit -> screenshot -> inspect -> fix' workflow gives concrete usage context, and preconditions are named per source ('pie (fails loudly if PIE not running)', camera required for agent_camera). It stops short of saying when *not* to use it or pointing to a sibling alternative, so it doesn't reach 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?

No annotations are provided, so the description carries the full burden — it declares 'read-only' and discloses a real limitation: engine-library candidates return names plus owning class but empty pins because the pure-Python channel cannot read UFunction signatures. That is a genuine behavioral caveat an agent needs. It doesn't cover permissions, pagination/cap behavior (left to schema), or failure modes, keeping it below a 5.

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

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

The English text is front-loaded and efficient: purpose, then workflow ordering, then the pin-signature caveat. The full Chinese mirror roughly doubles the token cost, which is intentional for bilingual coverage but is redundant for any single agent.

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

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

With no output schema, the description usefully characterizes return content (node candidates with pin signatures; engine candidates with class name and honestly empty pins). For a three-parameter read tool that is close to sufficient, though it could say more about how results are ordered or truncated.

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

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

Schema description coverage is 100%, so bp_path, query, and limit are already fully documented in the schema. The description adds no parameter-level meaning beyond that (e.g., it doesn't clarify query matching against node titles vs. class names), so the baseline 3 applies.

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

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

States a specific verb and resource ('Search callable nodes in a Blueprint') and enumerates the node categories covered (events / function candidates / flow control / variables) plus what the results carry (full pin signatures). An agent can distinguish this from ue5_read_nodes or ue5_read_blueprint without opening any schema.

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

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

Explicitly directs usage: 'Use this BEFORE ue5_apply_blueprint_graph to get accurate targets and pin signatures for the GraphSpec,' naming the sibling and the ordering condition. It does not say when to prefer ue5_read_nodes or other read siblings instead, so it stops short of full when/when-not coverage.

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

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

No annotations are provided, so the description carries the burden. It discloses that the tool performs a runtime teleport and that it verifies the new transform via read-back. However, it does not disclose what happens on failure (e.g., if the actor is not found, if verification fails), whether the operation is reversible, or any side effects. The read-back verification is a positive behavioral disclosure, but the failure behavior is left unclear.

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: one sentence with a clear verb, scope, and verification behavior. The bilingual repetition doubles the length without adding new information, which is a minor inefficiency. The key constraint ('at least one') is included, and the structure is front-loaded with the action.

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

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

For a 3-parameter tool with full schema coverage and no output schema, the description covers the core operation and the verification behavior. However, it lacks details about error handling, what happens if the actor doesn't exist, and whether the read-back verification returns the verified transform or just a success flag. Given the runtime mutation context and no annotations, a bit more context would be valuable.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters. The description adds the constraint that at least one of location/rotation must be provided, which is useful. It does not add format details beyond the schema's [x,y,z] and [pitch,yaw,roll] hints, but the baseline of 3 is appropriate given full 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 states a specific verb ('Teleport'), a specific resource ('PIE Actor'), and the exact scope ('location and/or rotation, at least one'). It also mentions read-back verification, which distinguishes it from a plain setter. The bilingual text is redundant but not harmful.

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

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

The description implies when to use it: at runtime in PIE, when you need to move/rotate an actor. It does not explicitly state when not to use it or name alternatives among siblings (e.g., ue5_read_pie_property for reading, ue5_execute_command for other runtime actions). The 'at least one' constraint is a useful usage hint, but no exclusions or alternatives are given.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the operation is asynchronous, that it must be polled, and that it starts a play/simulate session. It does not mention side effects like needing to stop the session with ue5_stop_pie, but the async polling behavior is the most critical behavioral trait and it is clearly disclosed.

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 action and async behavior, then the polling instruction, then the purpose. The bilingual addition is compact and does not bloat the English content. 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 tool with one optional parameter and no output schema, the description covers the start action, the async nature, the polling mechanism, and the intended use case. It does not mention how to stop the PIE session, but the sibling ue5_stop_pie exists and the polling instruction is sufficient for correct invocation. Minor gap: no mention of what happens if PIE is already running.

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

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

Schema coverage is 100% and the only parameter (mode) is fully described in the schema with its allowed values and default. The description adds no additional parameter semantics, but the schema already carries the full burden. Baseline 3 is appropriate.

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

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

The description states a specific verb ('Start'), a specific resource ('PIE (play/simulate)'), and the async behavior. It also distinguishes itself from compile-only verification by saying 'Use to verify that logic actually RUNS, not just that it compiles.' This clearly differentiates it from sibling tools like ue5_compile_blueprint.

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

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

The description explicitly tells the agent when to use this tool: to verify logic runs, not just compiles. It also names the exact sibling to poll with (ue5_read_pie_state) and the condition to wait for (is_playing=true). This is explicit routing guidance with no ambiguity.

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 of behavioral disclosure, but it only conveys that this is a mutating action. It does not state what happens when no PIE session is running (error vs. no-op), whether the stop saves or discards state, or whether the operation is reversible. The word 'running' hints at a precondition but nothing more.

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 English clause is minimal and front-loaded with the action verb 'Stop,' earning its place with no wasted words. One small deduction: the Chinese clause merely translates the English sentence and adds no new semantic information, so it does not fully earn its place for an English-language agent.

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

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

For a zero-parameter tool with no output schema and no annotations, the description is callable and adequate: an agent knows what action will be taken. However, it leaves meaningful gaps — the failure behavior when no session is active, the return/acknowledgment format, and side effects on the editor state — which a richer description or annotations should cover.

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, so the baseline is 4 and the schema already fully describes the interface (an empty object). The description correctly adds no parameter information because none exists; there is nothing further it needs to explain.

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 ('Stop') with an exact resource ('the running PIE/Simulate session'), leaving no ambiguity about the action. It is inherently distinguished from siblings, especially ue5_start_pie (its functional complement) and ue5_read_pie_state (a read operation), purely by the action word.

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, no exclusions, and no context about prerequisites. It is a bare statement of function; an agent must infer from the name and sibling list that this is the counterpart to ue5_start_pie.

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

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

With no annotations, the description carries the full burden; it does disclose the important singleton constraint ('one active task at a time') and the closing tool, plus that the dashboard renders from this data. It does not state whether the call fails or overwrites when a task is already active, nor what identifier or payload comes back.

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 short sentences, front-loaded with the action and ending with the constraint and next step; nothing loops or buries the lede. Slight redundancy in echoing field names already in the schema, plus bilingual duplication, keeps it off a 5.

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

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

For a 6-parameter stateful tool with no annotations and no output schema, the agent still doesn't know the failure mode on a second concurrent declaration or what the call returns. The lifecycle framing is present but behavioral edges are not covered.

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

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

Schema coverage is 100%, so the baseline is 3. The description merely re-lists field names (goal, asset, understanding, approach, steps) that the schema already documents, and notably omits user_request, the one parameter whose purpose (verbatim user words for a 原话 vs 理解 comparison) would benefit from emphasis.

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?

Clear specific verb+resource: 'Declare a task for the dashboard' with an enumeration of the fields it carries. It also names the terminating sibling (ue5_task_end), so the agent can place it in the task-lifecycle family rather than confusing it with ue5_task_list or ue5_task_step.

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?

'One active task at a time; close with ue5_task_end' gives both a usage constraint and the explicit follow-up tool. It lacks an explicit 'use when starting multi-step work' trigger and doesn't say what to do if a task is already open, but the sequencing rule is clear.

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

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

With no annotations, the description carries the full burden. It does add real behavioral context — the dashboard computes duration and failed steps and displays the retrospective — but it omits what happens if no active task exists, whether closing is idempotent, and whether the closed task remains queryable via ue5_task_list.

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 purpose and the required status field are front-loaded in the first clause, and every sentence adds information. The full bilingual duplication roughly doubles the length without adding new semantics, which is the main efficiency cost.

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 five-parameter task-lifecycle tool with no output schema, the description covers the must-have field, the retrospective intent, and the observable side effects (dashboard duration/failure steps). The two optional fields deliverables and how_to_verify go unmentioned, but the schema documents them adequately.

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

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

Schema coverage is 100%, so the baseline is 3. The description goes beyond the schema for the key fields: it enumerates status values, glosses summary as 'what was implemented', and adds concrete guidance for lessons ('what to avoid over-complicating next time, better approaches found') that the terse schema text lacks.

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

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

The description opens with a specific verb and resource: 'Close the active task with a retrospective,' and enumerates the retrospective fields (status, summary, lessons). It is distinguishable from siblings like ue5_task_begin/ue5_task_step by the word 'close', though it never names those lifecycle siblings explicitly.

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

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

Usage is only implied: 'Close the active task' suggests calling it at the end of a task session, but there is no explicit statement of prerequisites (must a task be active?), no when-not guidance, and no mention of the begin/step siblings that form the 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?

No annotations exist, so the description carries the full burden, yet it never states that the operation is read-only, how large the result set may be, whether it paginates, or how far back 'history' extends. The only behavioral fact conveyed is that both active and historical entries are returned.

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

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

A single front-loaded sentence that leads with the verb and scope, with no filler. The bilingual duplication is a localization choice rather than padding, though it does add tokens without new 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?

For a zero-parameter tool the surface area is small, and the description does name the payload contents. But with no output schema and no annotations, an agent still cannot anticipate the response shape, volume, or ordering of the returned task list.

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 takes zero parameters, so the baseline is 4; there is nothing for the description to disambiguate. No misleading parameter hints are given.

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

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

States a specific verb ('List') and resource ('journalized tasks'), and scopes it as 'active + history' with the content included (plans, progress, retrospectives). This distinguishes it reasonably well from the write-side siblings ue5_task_begin / ue5_task_step / ue5_task_end, though it never names them explicitly.

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

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

There is no explicit guidance on when to call this versus the other task-related tools (ue5_task_begin, ue5_task_step, ue5_task_end) or versus ue5_read_logs. A reader can infer it is the read side of a task journal, but nothing states preconditions, ordering, or exclusions.

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

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

No annotations are supplied, so the description carries full disclosure burden. It reveals one non-obvious trait — evidence feeds 'the dashboard' — but does not say whether a 'done'/'failed' status mutates plan state, whether reporting is idempotent or repeated calls overwrite, or what happens if step_id is unknown to the plan. Those omissions matter for a progress-reporting tool.

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

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

The English clause is front-loaded and dense: purpose, two usage modes, and evidence semantics in two sentences. Roughly half the text is a Chinese restatement, which is duplication rather than added information, keeping it off a 5.

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

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

Four optional parameters, a nested evidence object, no output schema and no annotations — the description covers the purpose and both invocation patterns adequately. Residual gaps are the state-mutation question and the absence of any note about valid step_id ranges or error behavior when the plan is not active.

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

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

Schema description coverage is 100%, so both schema and description document all four parameters; the baseline of 3 applies. The description does add provenance for step_id (it must come from the plan declared in ue5_task_begin) and the intended content of evidence, but adds nothing about note-vs-status interaction or the accepted shape of nested evidence beyond the schema's example.

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

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

States a specific verb and resource ('Report task progress against the declared plan') and, crucially, names the source of the step_id ('from ue5_task_begin steps'), which lets an agent distinguish this from ue5_task_begin/ue5_task_end without consulting sibling schemas. The two reporting modes (step-keyed status vs. free note) are spelled out up front.

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

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

Gives clear conditional guidance on which parameter set to use: step_id + status when advancing a declared step, note when 'between steps', evidence when there is proof to attach. It stops short of stating when to use this versus ue5_task_end or ue5_task_list, so the alternative-selection guidance is implicit rather than explicit.

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 discloses the whitelist scope (101 commands) and the return shape, which implies a read-only lookup, but it never states that the call has no side effects, nor does it mention the result cap (default 8, cap 20) that materially affects how an agent should query. Adequate but leaves behavioral 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 purpose and the routing instruction to execute_command are front-loaded in the first clause. It loses a point because the full text is duplicated bilingually, roughly doubling length without adding information an English-reading 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?

There is no output schema, and the description compensates by stating exactly what is returned (names, params, one-line descriptions). For a low-risk lookup with fully documented params this is nearly complete; only the omission of side-effect behavior and result-limit implications keeps it from a 5.

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

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

Schema description coverage is 100%, so all three parameters (query, limit, include_tools) are already documented with examples and defaults. The description only reinforces that the input is a keyword; it adds no syntax or format detail beyond the schema, which is the baseline-3 case.

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 (Search) and resource (101 whitelisted commands and MCP tools), and specifies the return payload: command names, params, one-line descriptions. It also names the sibling it pairs with (execute_command), so an agent can tell it apart from node/asset/PIE tools without opening a schema.

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

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

Explicitly says 'Use this before execute_command to discover capabilities without a dedicated tool', giving both the trigger condition (no dedicated tool exists) and the alternative it precedes. Nothing is left 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 full burden and delivers the key traits: the PIE precondition, the fail-loud behavior on both missing PIE and value mismatch, and that a screenshot is captured by default. It stays silent on error semantics for missing actors/properties and on how a successful assertion is reported.

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?

Core behavior and preconditions are front-loaded in the first clause, with supporting detail after. The only waste is the full bilingual duplication of the same content, which roughly doubles length without adding 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?

For an 8-parameter tool with no output schema and no annotations, the description covers invocation prerequisites and failure policy but says nothing about the success result shape (pass payload, artifact path) or how property types outside numerics/strings are handled. Adequate but with clear gaps.

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

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

Schema description coverage is 100%, so all eight parameters (including match, world, capture, tolerance) are already documented in structured fields. The description only restates the match modes and screenshot option, adding no syntax or interaction detail beyond the schema; baseline 3 applies.

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

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

States a specific verb+resource: read a live runtime property and compare it against an expected value, with named match modes and optional screenshot evidence. This clearly distinguishes it from a plain read (ue5_read_pie_property) by the assertion semantics, though no sibling is named explicitly.

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

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

Gives a clear precondition (PIE/Simulate must be running) and failure policy (fail-loud on mismatch), which tells the agent when the tool is applicable. It does not explicitly say when to prefer ue5_verify_scenario or ue5_read_pie_property instead, so no exclusions are offered.

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 supplied, so the description carries the load, and it does disclose substantive behavior: automatic PIE start/stop, a total timeout cap, rejection of destructive command steps unless allow_destructive=true, and the return payload (verified + per-step evidence + junit_path). It stops short of edge cases like behavior when PIE is already running or how failures are recorded per step.

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 English sentence is efficient and leads with the core action, but every point is then repeated verbatim in Chinese, roughly doubling length without adding information an agent can use. Structure is front-loaded, but the duplication costs it.

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

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

For a 9-parameter orchestration tool with no output schema, the description does state what is returned (verified, per-step evidence, junit_path) and covers the safety gate and timeout. What's missing is detail on the nested 'steps' payload shape, which is the most complex part of the call.

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

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

Schema description coverage is 100%, so the schema already documents all nine parameters including defaults and the timeout cap. The description reinforces a few of them (timeout, allow_destructive) but adds no syntax or step-schema detail (e.g. what fields a 'wait' or 'assert' step object requires) beyond the schema.

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

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

States a specific verb and resource: 'Run a scripted acceptance scenario in PIE and emit a JUnit report', then enumerates the step types (wait/assert/screenshot/log_contains/command). This is clearly more than a single-behavior check, but no sibling is named (e.g. ue5_verify_behavior or ue5_execute_command), so differentiation is left implicit.

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: acceptance scenarios, CI-consumable JUnit, automatic PIE start/stop. However, there is no explicit 'use this instead of X' guidance against the many PIE/verification siblings, and no stated preconditions (e.g. whether PIE may already be running).

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