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 provided, the description carries the full burden and discloses important behavior: atomicity, rollback of created assets on any failure, optional compilation, and accepted node reference formats. It does not mention whether an existing asset with the same name is overwritten or whether results are saved to disk, but the disclosed transactional behavior goes well beyond a trivial 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 compact despite the inherently complex spec. It front-loads the core atomic behavior, then provides a dense but parseable field listing. The bilingual tail is minimal and does not duplicate the main explanation.

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

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

Given the complexity and absence of an output schema, the description does not fully stand alone: it omits return-value/result behavior, which fields are required versus optional, and some nested-field syntax details like coordinate format or property value representation. The tool is highly complex, and while the description is rich, these gaps make it not fully complete for a cold-start agent.

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

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

The input schema only provides an opaque 'spec' object pointing back to the description, so the description effectively documents all parameter semantics. It enumerates every spec field with nested structure, lists the event/function node formats, and explains how node references can be specified (32-hex GUIDs recommended or titles).

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 ('Create a Blueprint from scratch') and a precise resource scope: asset, variables, components, interfaces, events, function nodes, connections, and optional compile. The phrase 'one atomic call' and 'from scratch' clearly distinguishes this from siblings like ue5_compile_blueprint or ue5_connect_pins.

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 makes it clear this tool is for full blueprint creation in a single atomic operation, which implies it is the right choice when building a new asset rather than modifying or compiling an existing one. It does not explicitly name alternatives or state when not to use it, but the 'from scratch' framing gives strong contextual 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 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?

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 behavioral disclosure burden. It usefully notes that arguments are 'less validated' and unregistered commands 'fail-loud', which are meaningful safety signals. However, it does not explicitly warn about potentially destructive side effects (delete_asset, set_actor_transform, etc.) or state permission requirements, leaving the agent to infer mutability from the command 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 description is front-loaded with purpose and usage guidance before the long command list, which is necessary for a valid invocation. The bilingual repetition ('白名单命令透传（专用工具未覆盖时使用）') is redundant but not harmful. Overall each sentence serves a role, though the list makes it unavoidably lengthy.

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 tool covering 72 commands with no output schema, the description provides the essential context: role, when to use, the full valid command set, and failure behavior. It lacks a description of the return format and per-command parameter specifics, but given the breadth and the thin schema, it is reasonably complete. The safety profile is less full without annotations, though the 'less validated' caveat partially covers 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%, so the baseline is 3. The description adds substantial value by enumerating the complete command whitelist, effectively providing all valid enum values for `command`, and clarifying that `params` is the command arguments object. This goes beyond the schema's terse field descriptions.

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

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

The description opens with 'Escape hatch: run any whitelisted bridge command by name', a specific verb-resource pairing that immediately conveys a generic execution role. It distinguishes itself from dedicated siblings by stating 'Prefer the dedicated tool whenever one exists' and listing the full 72-command surface, making its scope unmistakable.

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

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

Explicit guidance is provided: 'Prefer the dedicated tool whenever one exists for the operation; this generic entry point is the last resort.' It further explains that arguments are less validated and unregistered commands fail loudly, giving the agent clear criteria for when to invoke this tool versus its siblings.

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 full burden and does a good job: it explicitly discloses the read-only/safe behavior, states that it returns structured JSON, and explains the L1/L2/full behavioral distinction. It still leaves some gaps such as error behavior and exact return structure, but it is far above the minimal bar.

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

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

The description is compact and front-loads the core purpose and level semantics in the first sentence. The bilingual suffix adds useful localization but partially duplicates the English text, and the CLI-reader mention is slightly tangential, so it is not perfectly lean.

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

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

The description captures the essential purpose, level semantics, safety, and output type, which is adequate for a basic read operation. However, there is no output schema and the description does not specify the shape of the structured JSON, error behavior, or how this relates to the sibling read tools, leaving a meaningful completeness gap.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value by explaining how the level parameter maps to content (L1 = class info + variables + CDO, L2 = node graph + connections), which clarifies the relationship between level, include_cdo, and include_connections beyond the schema descriptions alone.

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

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

The description clearly states the tool reads a Blueprint asset and defines meaningful read levels (L1 class info/variables/CDO, L2 node graph/connections, full). It is specific and actionable, though it does not explicitly contrast itself with sibling tools like ue5_read_nodes or ue5_read_connections, so it stops short of a 5.

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

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

The description gives clear usage context by saying it is read-only and safe to call any time, and the L1/L2/full distinctions imply when each level is useful. However, it does not provide guidance on when to prefer this tool over the dedicated ue5_read_nodes, ue5_read_connections, or other read tools, nor any when-not-to-use conditions.

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. It states the tool reads connection topology, which is a read operation, but doesn't mention any side effects, performance implications, or error conditions. The description is terse and lacks detail about what happens if the blueprint is not found or the graph is invalid.

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

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

The description is very concise, with a single clear sentence and a bilingual repetition. The key purpose and usage hint are front-loaded, making it easy to scan. No wasted words.

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

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

Given the tool's moderate complexity (read-only topology inspection with optional graph filtering), the description provides the essential purpose and usage context. However, with no output schema or annotations, it lacks details on the return format (e.g., list of connections, structured JSON), which could help agents understand what to expect. The description is adequate but not comprehensive.

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

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

The input schema has 100% coverage with descriptions for both parameters (bp_path and graph_name). The description adds minimal semantic value beyond the schema, but it implicitly indicates the tool focuses on connections, which helps understand parameter relevance. However, it doesn't elaborate on graph_name semantics beyond what the schema states.

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

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

The description clearly states the verb 'Read' and the resource 'Blueprint connection topology', specifying what is read (which pin connects to which node/pin). It distinguishes itself from sibling tools like ue5_read_nodes (which reads nodes) and ue5_connect_pins (which modifies connections), though it doesn't explicitly name alternatives.

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

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

The description explicitly states when to use it: 'Use to verify wiring before and after edits.' This provides clear context for the tool's purpose, though it does not mention when not to use it or name alternative tools for different scenarios.

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

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

With no annotations 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 provided, so the description carries the full burden. It discloses the data returned and the all-graphs search behavior, but does not explicitly state that the operation is non-destructive, nor does it mention permissions, error conditions, or performance. The word 'Read' implies safety, but the description could add more explicit behavioral context.

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

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

Two sentences, front-loaded with the verb and resource, then a parameter hint and a usage tip. The bilingual translation is compact and adds no redundancy. 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 only 2 parameters (1 required) and no output schema, the description supplies the essential return fields (titles, positions, GUIDs, pin defaults) and the scoping behavior. It lacks explicit error handling or prerequisites, but the agent can call it correctly without further info. Adequate 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?

The schema covers both parameters with 100% description coverage, establishing a baseline of 3. The description adds meaningful value by explaining the semantic of omitting graph_name (search all graphs), which goes beyond the schema's 'omit to search all graphs' by reinforcing it in the tool's core instruction. This extra guidance earns a 4.

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

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

The description states a specific verb ('Read') and resource ('Blueprint nodes'), and enumerates exactly what is returned: titles, positions, GUIDs and pin defaults. This distinguishes it clearly from siblings like ue5_read_blueprint (whole blueprint) and ue5_read_connections (connections). No ambiguity remains.

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 a concrete use case: 'Use before connecting pins so you have the GUIDs,' and explains parameter behavior: 'Omit graph_name to search all graphs.' It does not explicitly name alternative tools or exclusions, but the context is clear enough for an agent to know when to invoke 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?

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?

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.