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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds meaningful behavioral context by stating the tool executes nothing and only retrieves a discovered schema. It also explains the version-check behavior, which goes beyond what annotations provide. No contradiction exists.

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

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

Three sentences with no filler: the core action is front-loaded, and the concurrency guard and execution boundary are each purposeful. Every sentence adds information an agent needs.

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

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

Given the read-only annotations and an output schema, the description is largely complete: it identifies the target, explains the version parameter, and explicitly warns against using this tool for execution. The only minor gap is that 'action preset' is mentioned but not elaborated, though the output schema likely covers that.

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

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

Schema description coverage is 0%, so the description carries the burden for parameter meaning. It clearly explains that version is the value returned by search and is used to reject a changed catalog. tool_id is not formally defined, but its role as the catalog identifier is reasonably inferable from 'one exact discovered tool 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 states a specific operation: retrieving one exact discovered tool schema and any action preset, and explicitly says it 'executes nothing.' This clearly distinguishes it from catalog search/refresh tools and from sibling execution tools like unreal_workflow_apply.

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 tells the agent to pass the version returned by search to reject a changed catalog, and directs authorized execution to the external server's own client instead of this tool. It gives clear context and a concrete alternative, though it does not explicitly enumerate exclusions versus jev_catalog_search or jev_catalog_refresh.

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?

Beyond the annotations, the description discloses atomic refresh behavior, snapshot retention on failure, untrusted external descriptions, and no automatic cloud transfer. These are meaningful behavioral traits an agent needs to know before invoking.

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

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

Three sentences deliver distinct value: purpose and safety bound, prerequisite and failure atomicity, and trust/cloud behavior. The description is front-loaded and contains no filler.

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

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

With no parameters, an output schema present, and annotations covering safety, the description covers prerequisites, failure behavior, and data trust boundaries. Nothing needed to invoke the tool correctly is missing.

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

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

There are zero parameters and the input schema is the empty object, so the description has no parameter semantics to add. Baseline 4 applies because there is no parameter gap for the description to compensate for.

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 action, 'Discover tools/schemas', and a specific resource, 'explicitly configured loopback MCP servers'. It also adds a negative constraint, 'no tools execute', which differentiates it from execution-focused sibling tools.

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

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

It provides a clear prerequisite: 'Configure JEV_CATALOG_FILE first', and the phrase 'explicitly configured loopback MCP servers' gives context for when this refresh tool is applicable. However, 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?

Annotations already mark it as read-only and non-destructive. The description adds valuable context: 'Sends the goal and shortlisted descriptions to the cloud; no editor state or tools run.' This clarifies the side-effect profile and the remote invocation, which is useful beyond the annotations.

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

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

The description is two sentences, front-loaded with the primary purpose, followed by a behavioral note and a usage hint. Every sentence earns its place; there is no wasted wording.

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 an output schema present, return format is not needed. The description covers the core behavior and side-effect profile, but it does not differentiate from other decision-oriented siblings (je_decide, je_route, je_triage) beyond the search contrast, and it leaves the 'defer' behavior ambiguous. For a tool that is one of many decision helpers, this is only partially 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 description coverage is 0%, so the description must compensate. It mentions 'goal' and 'shortlisted descriptions' indirectly, which maps to the goal and tool_ids parameters, but it does not explain their format, purpose, or constraints. The version parameter is not mentioned at all. This is insufficient for a tool with three parameters.

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

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

The description clearly states the action: ask Jev to recommend one tool from an explicit catalog shortlist, or defer. This is a specific verb-resource pair and distinguishes itself from the sibling jev_catalog_search by explicitly noting when to prefer deterministic search instead.

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 gives an explicit condition for choosing an alternative ('Prefer deterministic catalog search when it already identifies the appropriate tool'), which tells the agent when not to use this tool. However, it does not contrast with other decision tools like jev_decide, jev_route, or jev_triage, so the guidance is only partial.

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?

Even with readOnlyHint and destructiveHint already covering safety, the description adds meaningful behavioral context: results are from a local cache, so refresh is required, and search scores are explicitly not proof of correctness, permission, or capability. This materially shapes how an agent should interpret results.

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 five short sentences, front-loads the core purpose, and every sentence carries actionable information: purpose, return shape, precondition, routing to get, and an interpretation caveat. No filler or schema repetition.

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

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

For a low-complexity, read-only search tool with an output schema and safety annotations, the description covers purpose, caveats, and workflow. It only falls short by leaving server_id and limit behavior to the schema, which has no parameter descriptions.

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

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

Schema description coverage is 0%, yet the description adds almost nothing about the three parameters. It implies query semantics through 'lexical relevance,' but says nothing about limit behavior, server_id selection, or how query strings are matched; the schema only provides names/defaults, no 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 a specific verb and resource: 'Search the cached tool catalog locally.' It also states the return shape ('compact hits and their catalog version'), and the reference to jev_catalog_get distinguishes it from the schema-retrieval sibling.

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 gives an explicit precondition ('Refresh first'), directs the agent to jev_catalog_get instead of this tool when exact schemas are needed, and warns that scores indicate lexical relevance, not correctness or permission—so the agent knows when not to rely on them.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context: no tools are executed, the request limit is 64 KiB, and 'Noul is a probability, not a severity score.' These details go beyond the annotations and help the agent understand side effects and semantics. It doesn't describe response format, but the output schema exists and the description covers the key behavioral traits.

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-loaded: the core action and constraint (1–32 questions, no tool execution) appear in the first sentence. The question format examples are dense but necessary, and the final two sentences add critical limits and semantics. Every sentence earns its place; no filler.

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

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

For a tool with 2 required params, no enums, and an output schema, the description covers the essential usage: what to send, the question format, the count limit, the request size limit, and the no-execution guarantee. The main gap is that it doesn't describe what the response contains or how to interpret the returned decisions, but the output schema likely covers that. It also doesn't explicitly state when to prefer this over jev_route/jev_triage, but the sibling list is large and the description is otherwise sufficient.

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

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

Schema description coverage is 0%, so the description must compensate. It does: it explains the 'state' parameter implicitly as 'explicit state' and gives concrete shapes for the 'questions' parameter with three question types (choice, noul, score) and their fields. It also clarifies the noul semantics. This is strong compensation, though it doesn't fully document every possible field of the questions object.

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 ('Send explicit state and 1–32 Choice/Score/Noul questions to Jev') and identifies the resource (Jev) and the question types. It also explicitly says 'No tools are executed,' which helps distinguish it from sibling tools that apply or preview workflows. However, it doesn't explicitly name a sibling alternative or contrast with jev_route/jev_triage, so it falls 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?

The description gives clear context: it is for sending state and questions to Jev, with a limit of 1–32 questions and a 64 KiB cloud request limit. It also clarifies that no tools are executed, implying it is a decision/consultation tool rather than an execution tool. It does not explicitly state when to use this instead of jev_route or jev_triage, so it lacks explicit 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?

The description discloses several behavioral traits beyond the readOnlyHint annotation: it mentions optional cloud excerpt sending (use_jev=true), best-effort redaction with a security warning, input caps (128 KiB, 8192 lines), and that it reads no files. These are significant details that an agent needs to know, especially regarding data privacy and input limits. This goes well beyond the annotations and adds substantial transparency.

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

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

The description is five sentences and front-loads the core purpose. Each sentence adds necessary information: the main action, optional behavior, security caveat, input limits, and authoritative source note. It is concise without being terse, though it could potentially be tightened by merging related clauses. Overall, it is appropriately sized and well-structured.

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

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

Given the tool has four parameters, an output schema, and involves optional cloud interaction, the description leaves gaps. It does not explain max_groups and excerpt_chars, which are likely important for controlling output and excerpt size. While the output schema exists, the description still lacks essential parameter semantics and could better clarify the optional cloud feature. For a tool with these complexities, the description is incomplete.

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

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

Schema description coverage is 0%, so the description must explain the parameters. It mentions use_jev and its effect (sends excerpts), and it specifies input caps related to log_text. However, it does not explain max_groups or excerpt_chars at all. With four parameters and only partial coverage of two, the description fails to compensate for the missing schema descriptions, leaving agents uncertain about the effect of these parameters.

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

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

The description clearly states the tool's function: 'Group supplied logs locally by issue with counts, severity and line evidence.' This specifies a concrete action (grouping), a resource (supplied logs), and the output format (by issue with counts, severity, line evidence). The purpose is unambiguous and distinct from sibling tools, even without explicit 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?

The description provides some usage context: it notes that the tool reads no files and that 'build and test results remain authoritative,' implying it should not be used for authoritative conclusions. However, it does not explicitly state when to use this tool versus alternatives like jev_triage or jev_decide, nor does it name specific alternatives. The usage guidance is implied 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?

Annotations only declare readOnly/openWorld/non-destructive. The description adds meaningful behavior: local by default, the optional provider call, the failure mode for missing required metadata, and the explicit guarantee that no asset loads, edits, or visual judgments occur. No contradiction with annotations.

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

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

The description is compact and front-loaded: the first sentence states the core function, and the following sentences each add essential context (mode, opt-in, failure mode, exclusions, alternative). No filler or redundancy.

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

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

The description covers what the tool does, how it behaves locally vs via provider, what causes failure, what it does not do, and where to go for authoritative measurements. With an output schema present and annotations already covering safety, this is complete enough for correct invocation.

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

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

Schema description coverage is 0%, so the description must compensate. It adds meaning for goal, candidates, and use_jev by describing supplier-owned metadata and the provider opt-in. However, it does not clarify filters or limit beyond the schema's self-descriptive names and defaults.

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

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

The description opens with a specific verb and resource: 'Filter and rank supplied asset metadata; optional Jev choice over the shortlist.' It clearly scopes the tool to metadata filtering/ranking and explicitly points to unreal_asset_details for a different task, distinguishing it from 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 explains the local default, when to opt into the Jev provider with use_jev=true, what happens with missing metadata, and explicitly names unreal_asset_details as the alternative for authoritative mesh measurements. This gives an agent clear 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?

Annotations already mark the tool as read-only, open-world, and non-destructive; the description adds that it defers when confidence is missing/low and that thresholds are 'initial defaults, not accuracy claims.' This is extra behavioral context and does not contradict the annotations.

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

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

The description is five short sentences with the core behavior front-loaded. Each sentence adds operational detail, though 'Thresholds are initial defaults...' reads as a caveat that could be folded into the deferral statement.

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 routing tool, the description covers purpose, candidate nullability/omission, external-server shortlisting, and deferral behavior; the output schema covers return values. It is slightly incomplete only in not distinguishing this from jev_decide/jev_triage as a routing path.

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

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

With 0% schema description coverage, the description must carry parameter meaning. It explains goal/candidates as a pair sent to Jev and when candidates should be omitted vs supplied, but it does not define the expected goal format or the Candidate id/description fields beyond what the schema's type/constraints show.

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 action ('Recommend one candidate tool or defer') and identifies the resource (the supplied goal/candidates sent to Jev). It doesn't explicitly contrast with similarly named siblings like jev_decide or jev_triage, so it falls 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?

It gives concrete usage rules: omit candidates for built-in Unreal workflows, and supply a shortlist from another Unreal or future Blender MCP server to avoid loading every schema. 'Missing/low confidence defers' also says when the tool should fall back. It does not name alternative sibling tools, so it is explicit but not fully comparative.

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

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

The annotations already declare the operation read-only and non-destructive, and the description is consistent with that. It adds output-scope detail ('local provider counters', 'authenticated Unreal connection identity') but does not describe edge behavior, such as what happens when no authenticated Unreal connection exists.

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 direct sentence with no filler. Both pieces of information are compactly front-loaded.

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

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

Given the zero-parameter schema, read-only annotations, and an output schema, the definition is largely complete for successful invocation. It could add a line routing the agent away from sibling status tools, but that gap is already captured in usage guidance.

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 schema coverage is trivially complete and no parameter-specific documentation is needed. The baseline of 4 for a zero-parameter tool 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 ('Show') and specific resources ('local provider counters' and 'authenticated Unreal connection identity'). It does not explicitly differentiate from sibling tools like 'unreal_status' or 'jev_diagnostics', which weakens the otherwise clear purpose.

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

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

There is no guidance on when to use this tool compared with sibling alternatives such as 'unreal_status' or 'jev_diagnostics'. No conditions, prerequisites, or exclusion criteria are provided.

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

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

Annotations already mark the tool as read-only and non-destructive, and the description reinforces and extends this by disclosing that it performs a cloud data transfer, runs as a batched call, and does not modify the editor. This adds useful behavioral context beyond the annotations, especially the privacy-related warning about credentials and private data.

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 short and front-loads the core purpose. The standalone 'Cloud data transfer.' sentence is compact but meaningful because it flags an important behavioral consideration. All sentences contribute useful information, though a little more structure could make the input constraints flow more naturally.

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

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

For a single-parameter tool with a provided output schema and safety annotations, this description covers the essential context: what the tool does, what input is appropriate, privacy considerations, and the non-authoritative nature of the result. It does not over-explain return values, which is acceptable given the output schema exists.

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

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

Schema description coverage is 0%, so the description must carry the semantic weight for `log_excerpt`. It does this well by specifying that the input is an Unreal log excerpt, should contain only relevant lines, and must have credentials/private data removed. It does not add formatting details, but the schema already provides length constraints.

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

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

The description opens with a specific verb and resource: 'Classify a supplied Unreal log excerpt.' It clearly conveys that the tool produces a diagnostic category rather than a build certification. It does not explicitly name sibling alternatives, but the classification purpose is distinct enough from the surrounding unreal_* and jev_* tools.

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

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

The description gives concrete usage guidance: supply only relevant log lines with credentials and private data removed. It also states a clear boundary: the result suggests a category and does not certify a build or alter the editor. It stops short of naming alternative tools when certification is needed, so it is not 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?

Annotations already declare readOnlyHint=true and destructiveHint=false detach. The description adds meaningful beyond-annotation context: 'Returns one coherent measurement state; absent bounds and truncated material lists are explicit.' This discloses output semantics and edge-case handling, and 'No scene change or cloud call' reinforces side-effect expectations without contradicting annotations.

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

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

Two sentences achieve complete, front-loaded communication: the first states the purpose, the second gives constraints and output behavior. There is no filler or repetition of schema fields.

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 one parameter, an output schema, and safety annotations. The description covers the core purpose, path existence requirement, and result semantics, including explicit handling of absent or truncated data. Nothing required for correct selection or invocation is missing.

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

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

Schema description coverage is 0%, so the description must compensate for the sole parameter, actor_paths. It does by specifying that paths must exist in the editor world and must correspond to exact loaded actors. It does not spell out path format, but for a single array-of-strings parameter with schema constraints on length/count, this is sufficient added meaning.

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

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

The description opens with a specific verb and resource: 'Inspect exact loaded actors, world bounds, materials and native edit blockers.' This clearly distinguishes the tool from siblings like unreal_actors or unreal_asset_details by naming distinct inspection targets and the precision ('exact loaded actors') of the operation.

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

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

The description provides clear context for use: 'All paths must exist in the editor world' and 'No scene change or cloud call.' It does not explicitly name alternatives or state when not to use the tool, so it stops short of a 5, but the constraints and non-mutating nature are effectively communicated.

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

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

Annotations already communicate read-only and non-destructive behavior, so the description correctly avoids repeating those. It adds useful behavioral context by disclosing that the tool makes no cloud call and that returned paths/transforms are stable, which informs latency and result reliability expectations.

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 sentence front-loads the core operation and then adds two meaningful operational constraints. Every phrase earns its place and there is no filler.

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

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

The tool itself is simple, read-only, optional-parameter-only, and has an output schema, so the core call is usable. However, among roughly 50 sibling tools, the lack of selection guidance and the absence of query-parameter semantics leave a meaningful gap for an agent deciding when and how to invoke 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?

With 0% schema description coverage, the description needed to compensate for the undocumented parameters. 'Bounded' only weakly hints at the limit parameter, and the query parameter's filtering behavior is left entirely undefined. The description adds almost no semantic value beyond the schema's property names.

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

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

The description states a specific verb ('Read') and a bounded resource ('actor snapshot') while adding distinguishing constraints: stable paths/transforms and no cloud call. This clearly separates it from asset, workflow, and preview siblings even without naming them.

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

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

The use case is implied: read a bounded, local actor snapshot. The phrase 'no cloud call' hints at when this might be preferred, but the description gives no explicit guidance on when not to use it or which alternatives like unreal_actor_details or unreal_snapshot should be chosen instead.

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?

Beyond annotations, it reveals that the operation is undoable ('editor Undo transaction'), does not persist to disk, and must not be auto-retried after timeouts. These traits materially affect how an agent should invoke and monitor the call, and they do not contradict readOnlyHint, idempotentHint, or destructiveHint.

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

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

Three short sentences convey the main operation, undo/persistence behavior, and critical guardrails. Every sentence earns its place, with the most important information front-loaded.

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

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

For a one-parameter apply operation with an output schema and annotations, the description covers the operation, undo/persistence behavior, authorization, staleness, and timeout handling. The only notable omission is explicit guidance on sourcing or verifying plan_id, but the workflow context and sibling tools make this inferable.

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 description adds modest meaning by identifying plan_id as a reviewed preview plan and warning that plans may become stale or expire. With 0% schema description coverage, it does not fully compensate by saying where the plan_id comes from or how it is obtained, but the single self-describing parameter limits the gap.

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

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

The description states a clear action ('apply'), a specific object ('reviewed preview plan'), and a distinctive execution mode ('once as an editor Undo transaction'), so an agent can tell apply apart from planning/preview tools. It does not explicitly call out the sibling unreal_workflow_apply, which keeps it from being 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?

It clearly states the only authorization condition ('Call only for edits the user authorized'), defines when a plan is unusable ('stale/expired plan requires a new preview'), and gives an explicit negative instruction about timeout retries. This is strong routing and handling guidance even though it does not name sibling tools.

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

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

Annotations already mark the tool as read-only and non-destructive, but the description adds valuable behavioral nuance: it is one-hop only, and the results are evidence of references rather than guarantees of cook/load success. The caution about reading truncation and registry-loading flags is beyond what annotations provide, enriching the agent's understanding of potential edge cases.

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: the first sentence states the core purpose and scope, and the second adds a crucial caution. It is front-loaded and each sentence carries meaning without unnecessary verbosity. The structure is clear and easy to scan.

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?

An output schema exists, so return values are covered. The description explains the tool's behavior and limitations well, but parameter semantics are sparse, leaving the agent to infer the meaning of category and direction. For a tool with 5 parameters, the description could be more complete, though it covers the essential usage context and caveats.

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

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

Schema description coverage is 0%, so the description must compensate. It only mentions pagination, giving some meaning to limit/offset, but does not explain asset_path, category, or direction. The enum values for category and direction are left to the schema names, which may be ambiguous. This is a significant gap given the lack of schema descriptions.

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

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

The description clearly states the tool inspects one-hop asset registry references with pagination, and explicitly notes it does not perform recursive loads or edits. This precisely identifies the action and resource, distinguishing it from sibling tools that may do deeper analysis or modifications.

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

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

The description provides clear context for when to use the tool (one-hop inspection) and what it explicitly avoids (recursive loads, edits). It also gives interpretive guidance about registry dependencies being evidence rather than proof, and advises checking truncation and flags. While it doesn't name specific alternative tools, the scope restrictions effectively guide the agent away from misuse.

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

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

Annotations cover the read-only/destructive profile (readOnlyHint=true, destructiveHint=false), and the description adds meaningful context beyond that: the conditional loading behavior ('Static meshes may load'), the cm units and data categories returned, class-dependent behavior, and the privacy guarantee ('No content is sent to a provider'). This is genuinely valuable behavioral disclosure that the annotations do not provide.

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

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

Four short sentences, no filler. The purpose is front-loaded, followed by behavioral detail, conditional behavior, and a privacy note. Every sentence earns its place and the whole description is compact for the amount of information it conveys.

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 an output schema present, return-value documentation is already handled, and the single parameter's format is described. The description covers purpose, class-dependent behavior, and data-handling guarantees. The only gap is the lack of explicit alternative-tool routing, but for a one-parameter inspect tool with full annotation coverage, nothing essential for correct invocation is missing.

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

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

Schema description coverage is 0%, so the description must carry the semantic weight for the single 'path' parameter — and it does by specifying the expected format: an exact /Game or /Engine object path. This is the core semantic an agent needs and is not present in the schema. It doesn't mention the 512-char cap, but that is a minor constraint relative to the path-format guidance provided.

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

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

The description opens with a specific verb-resource pair ('Inspect one exact /Game or /Engine asset object path') and adds the 'one exact' qualifier that separates it from search/list siblings like unreal_assets. It also names the specific output domains (mesh measurements, registry metadata), so an agent can differentiate it from unreal_asset_dependencies and unreal_asset_import_info without opening their schemas.

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

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

The description gives useful context — use for a single exact asset path, and outcomes vary by asset class (static meshes get measurements, other classes get registry metadata). However, it never explicitly names alternatives or states when NOT to use this tool versus siblings like unreal_actor_details or unreal_asset_dependencies; the routing is implied rather than stated.

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

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

Beyond the readOnlyHint annotation, the description adds meaningful context: it never inspects source files, reports missing metadata explicitly, and explicitly lists what it does NOT establish (source availability, DCC units, import quality, texture completeness). This gives agents a clear picture of limitations without overstating capabilities.

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, both dense with relevant information. The core purpose is front-loaded, followed by a crucial limitation. No filler or repetition—every word earns its place.

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

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

For a simple one-parameter read tool, the description covers what it does, its constraints, and its limitations. The output schema exists, so return values are presumably documented elsewhere. However, the lack of parameter guidance is a notable gap, making it slightly incomplete for an agent to call correctly without additional context.

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

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

The description makes no mention of the asset_path parameter, and the schema description coverage is 0%. Since the schema only provides type and length constraints, the description should have explained the expected format or semantics (e.g., full path vs. relative). This is a clear gap, as the description does not compensate for the schema's lack of explanation.

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 registry import provenance, explicitly noting it uses only source basenames and never inspects source files. This gives a specific verb, resource, and a key behavioral distinction from other tools, making the purpose unambiguous.

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

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

The description implies usage by defining its function but provides no explicit guidance on when to use this tool versus alternatives. It doesn't mention conditions or exclusions, leaving selection to inference. For a tool with many siblings, this is a moderate gap.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is fully covered. The description adds one genuinely useful behavioral fact beyond the annotations: results are metadata with no visual/acceptance significance, which sets expectations for the payload. Return-shape details are covered by the output schema, so no further burden falls on the description. No contradiction with annotations.

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

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

Two short sentences with zero filler: the first delivers action and target, the second a decision-relevant caveat. The most important constraint (metadata vs visual) is front-loaded, and every word earns its place.

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

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

For a simple read-only search tool with three optional parameters, an output schema, and safety annotations, the definition is nearly complete — an agent can invoke it correctly. The residual gap is unspecified search semantics (whether query is substring/name match and whether path scopes or filters results), which 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 0%, and the description contributes nothing about path, query, or limit. The parameter names and defaults ('/Game', 100) make meanings partially inferable, but per the rubric the description must compensate for low schema coverage and does not — it never explains, for example, that path scopes the search to a content-browser directory or how query matches asset names.

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

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

The description states a specific verb ('search') and resource ('the Unreal asset registry'), and the 'metadata, not visual acceptance' caveat separates it from the many preview-focused siblings (unreal_preview, unreal_mesh_preview). It stops short of a 5 because it never names the closest alternatives (unreal_asset_details, unreal_asset_dependencies), so differentiation from detail-lookup tools is implicit rather than explicit.

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

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

The description implies the primary use case — locating assets in the registry — and the metadata warning tells the agent not to rely on these results for visual acceptance. However, there is no explicit when-to-use/when-not-to-use guidance and no named alternative, leaving the agent to infer boundaries against roughly 50 sibling tools.

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

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

The description discloses consumption semantics, synchronous execution with SkipSave, possible side effects from callbacks, no timeout/cancellation/retry/rollback guarantees, stale-attempt consumption, timeout recovery advice, and success limitations. This goes well beyond the sparse annotations and strongly informs the agent of the destructive, non-idempotent nature.

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 action is front-loaded in the first sentence, with each subsequent sentence adding a distinct behavioral fact. There is no filler or redundancy; the density is high but every clause earns its place.

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

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

Given the destructive, non-idempotent, timeout-prone nature of the tool, the description covers the essential operational behaviors: plan consumption, failure semantics, side effects, prerequisites, and success interpretation. The presence of an output schema covers return-value details, so nothing critical is missing for an agent to invoke this safely.

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 provides only a bare plan_id with length constraints and 0% description coverage. The description compensates by establishing that plan_id refers to a reviewed native compile plan, that the plan is consumed, and that the same plan's receipt should be read after timeout. It does not fully explain how to obtain a valid plan_id, but the single-parameter context makes this adequate.

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 ('consume') and resource ('one reviewed native compile plan') and states the output ('fresh bounded compiler diagnostics'). This clearly differentiates it from siblings like preview or receipt tools, which do not consume a plan or produce fresh 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?

It gives clear context for when to call: on a reviewed native compile plan, with explicit expected project configuration, and not for PIE/simulation or as gameplay/visual acceptance. It stops short of naming specific alternative tools or explicitly saying 'use X instead,' so it lacks full alternative routing.

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

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

Discloses important behavioral traits beyond the annotations: the plan expires in 120 seconds, scene/notified object edits invalidate it, native compiler callbacks can affect other assets/instances, and effects cannot be sandboxed or rolled back. This is exactly the kind of side-effect and lifecycle context that annotations do not provide.

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

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

Compact and front-loaded: the first sentence states the core purpose, and each subsequent sentence adds essential caveats without padding. 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?

Covers the key operational constraints: no actual compilation, plan expiration, invalidation, callback side effects, rollback impossibility, and exact binding requirement. It is complete enough given the output schema, though it could explicitly tell the agent to use the actual compile tool when compilation is needed.

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 description maps 'approved alias' to target_id and 'inspected editor state' to expected_state, and 'exact project binding' hints at the state fields. However, with 0% schema description coverage, it does not explain how to construct expected_state or where to obtain the approved alias. Partial compensation only.

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 operation: 'Preview one explicit compiler run for an approved alias using inspected editor state.' The phrase 'Does not compile' immediately distinguishes it from actual compile tools. The resource and scope are clear enough that an agent can separate it from siblings like unreal_blueprint_compile.

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 usage context: use it to review the plan and side effects before a real compile, and it explicitly says it does not compile. However, it does not name an alternative tool or give explicit when-not-to-use conditions, so it falls just short of full 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?

Beyond the readOnlyHint and destructiveHint annotations, the description adds valuable behavioral details: receipts expire after 15 minutes, persistence across MCP reconnects, and diagnostics may contain private project text. It also reinforces the no-retry behavior, making side effects and constraints 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?

Three tight sentences deliver the core purpose, an explicit negative instruction, a retention constraint, and a privacy warning with no filler. The most important usage constraint is front-loaded.

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

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

With an output schema present, return values need no explanation. The description covers retention, privacy, and the no-retry rule, but it could be more complete by explaining how to obtain a valid plan_id, such as from a compile preview or compile 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?

The schema has one required plan_id with 0% description coverage, and the description only indirectly explains it as identifying an existing compile plan/result or receipt. It does not specify where plan_id comes from, its format, or how it relates to the sibling compile tools, so the agent must infer part of the parameter's meaning.

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

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

The description states a specific action ('Read an existing compile plan/result') on a clear resource, and the directive 'never retry compilation' explicitly separates it from the sibling compile tools like unreal_blueprint_compile. This gives an agent a precise understanding of what the tool does.

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

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

The description gives clear context that this tool is for reading an existing compile result, not for triggering compilation, and it explicitly warns against retrying compilation. It does not name a specific alternative tool, but the exclusion is strong enough to route an agent correctly.

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

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

Annotations already mark readOnlyHint=true and destructiveHint=false, but the description goes beyond that by specifying exact behavioral constraints: it does not load or compile assets, it only lists aliases that are 'already loaded and listed by their project owner,' and it is disabled by default. These details materially change how an agent should interpret results and prerequisites. No contradiction with annotations.

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

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

Three sentences with no filler. The primary action is front-loaded, followed by necessary caveats (disabled by default, eligibility constraints, no authorization). Every sentence earns its place; it is concise yet informative.

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

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

For a no-parameter listing tool, the description covers the key aspects: what it lists, that it is safe (no loading/compiling), prerequisites (configuration), and eligibility restrictions. It also hints at the separation between discovery and execution. Since an output schema exists, the description need not explain return values. Nothing essential is missing.

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

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

The tool has zero parameters, so per the rubric the baseline is 4. There is nothing for the description to add about parameter meaning, and the schema is empty. The description correctly focuses on behavior rather than 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 opens with a specific verb and resource: 'List project-approved Blueprint compile aliases' – it clearly states what the tool does and the scope (project-approved). It also distinguishes itself from siblings like unreal_blueprint_compile (which compiles) and unreal_blueprint_compile_preview by emphasizing 'without loading or compiling assets.' No ambiguity.

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

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

The description implies when to use this tool: for discovery of compile aliases without side effects, and it explicitly states 'Discovery does not authorize execution,' hinting that a separate tool is needed for compilation. It also gives a prerequisite (configure locally if disabled). However, it does not name specific alternative tools, so it falls short of a 5.

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

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

Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds valuable behavior: no compile, no implicit asset load, no graph edit, limits are totals across graphs, truncation flags, stale compiler messages, and error handling for asset_not_loaded. This goes beyond the annotations and gives the agent actionable behavioral context.

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

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

The description is three sentences with no waste. It front-loads the core purpose, then lists exclusions and important warnings. The structure is logical and easy to parse, earning every sentence.

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

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

For an inspection tool with an output schema, the description covers what is returned, limits, staleness of diagnostics, and required preconditions (already-open). It also provides error handling guidance. Nothing essential is missing 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 description coverage is 0%, so the description must compensate. It explains that node/pin limits are totals across graphs and mentions truncation flags, which helps interpret node_limit and pin_limit. It also implies asset_path refers to an already-open native Blueprint. However, it does not detail graph_limit or the exact format of limits, leaving some semantics under-specified.

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 an already-open native Blueprint and returns graph IDs, pins, variables, and diagnostics. It distinguishes itself from siblings like unreal_blueprint_compile and unreal_workflow_inspect by specifying 'no compile, implicit asset load or graph edit', making the purpose unambiguous.

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

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

The description provides clear context: it is for inspection only, not for compilation or modification. It implies when to use this tool (when the Blueprint is already open and you need diagnostics) and what to do if asset_not_loaded is returned. However, it does not explicitly name alternative tools, so the guidance is implied 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 all annotations false and no read-only or idempotency hints, the description carries the behavioral burden. It clearly warns that compilation can fail, edits are retained for Undo/correction, rollback is not guaranteed, and runtime/semantic success is not assured. This goes beyond the structured fields and gives an agent realistic expectations about side effects and risk.

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

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

The description is front-loaded with the core purpose and immediately follows with supported node types and hard constraints. Each sentence adds meaningful context, and the risk warnings are placed after the main usage guidance. It is somewhat dense and could be tightened, but it earns its length.

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

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

For a specialized native Blueprint editing/preview tool, the description covers supported nodes, preconditions, constraints, follow-up commit path, failure behavior, and rollback limitations. With an output schema present, the return shape does not need to be explained. Some context is still missing, such as exact tool semantics around the 'preview' edit and how it interacts with the compile receipt, but the essentials are present.

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

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

Schema description coverage is 0%, so the description must compensate for the three required parameters, but it only vaguely references node/pin GUIDs and 'one unconnected literal'. It does not explain what target_id identifies, the expected_state fields, or how the value parameter should be formatted. The mention of supported types and 'no arbitrary expressions' helps slightly, but not enough to make the parameters actionable without opening 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: 'Preview one unconnected bool/int/real input literal on an approved native math node.' It further narrows scope by enumerating the exact supported node types (Add_IntInt, Multiply_IntInt, etc.) and by stating what it does not do ('No new nodes, links, object defaults or arbitrary expressions'). This clearly separates it from inspect, compile, and broader preview 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 gives concrete use conditions: the Blueprint must be 'loaded ordinary' and 'approved for compilation', and it instructs the caller to 'Inspect graph node/pin GUIDs first'. It also routes follow-up work to unreal_blueprint_compile. It does not explicitly contrast with sibling tools or list when-not-to-use cases, 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?

Annotations already mark the tool read-only and non-destructive; the description goes further by disclosing that no image is sent to Jev, no desktop capture, arbitrary file writing, or camera change occurs. It also names a concrete failure mode (headless NullRHI). This is valuable behavioral detail beyond the static annotations and does not contradict them.

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

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

Three sentences, each carrying distinct information: purpose, prerequisite/failure mode, and side-effect-free behavior. The description is front-loaded with the core action and avoids fluff.

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

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

For a tool with one optional parameter and no output schema, the description covers the core behaviors and the key prerequisite/failure case. It states the output is an MCP image with revision metadata, though it does not detail what that metadata contains or how the image is returned. The main weakness is the unexplained parameter, which prevents full completeness.

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

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

The single parameter max_dimension is not mentioned in the description at all, and schema coverage is 0%, so the description does not compensate. The schema's title and constraints ('Max Dimension', default 1024, min 64, max 1024) provide some intrinsic meaning, but the description leaves the agent without any guidance on how the dimension applies or why they might adjust it.

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

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

The description opens with a specific verb and resource: 'Capture the active Unreal editor viewport as an MCP image with revision metadata.' It clearly distinguishes this capture tool from the many preview and inspection siblings by stating exactly what is captured and adding explicit non-behaviors. This makes the tool's role unambiguous.

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

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

The description provides clear context: it requires a rendered level-editor viewport and notes that headless NullRHI returns viewport_unavailable, which signals when not to use it. It also clarifies that the image is not sent to Jev, implying this tool is for direct client consumption. However, it never references a specific alternative tool by name, so the 'when to use versus what' is implied 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces this with 'Reads the editor world.' It adds valuable caveats: PIE is supported and 'the revision tracks actor state; it does not fingerprint all asset contents,' preventing a common misunderstanding. The 'truncation flags' remark is somewhat cryptic but still contributes behavioral context.

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

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

The description is short and front-loaded with the core purpose. The three sentences are mostly economical, though the phrase 'Inspect independent truncation flags' is vague and does not clearly earn its place. Overall, it avoids bloat and keeps the most important information at the top.

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 an output schema present, the response shape is covered elsewhere, and the read-only annotations cover safety. But the description still leaves notable gaps: it never explains what 'bounded actors' means, what 'query' filters, or how 'limit' applies. It is minimally viable for a default call but incomplete for intentional parameter use.

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

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

Schema description coverage is 0%, so the description carries the full burden of explaining the parameters. It does not mention 'limit' or 'query' at all, leaving their purpose, scope, and filtering behavior undocumented. The names are mildly suggestive, but the description adds no meaning beyond the raw schema.

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

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

The description opens with a specific verb and resource list: 'Get project/world, play state, selection, dirty packages and bounded actors together.' This clearly identifies the tool as an aggregate context reader and distinguishes it from single-purpose sibling tools like unreal_actor_details or unreal_status. The scope is concrete and actionable.

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 saying it 'Reads the editor world, including while PIE is running,' which signals when the tool is appropriate. However, it gives no explicit when-not-to-use guidance and does not name alternatives or conditions for choosing another sibling tool. The guidance is implied rather than stated.

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

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

Annotations already declare readOnlyHint and destructiveHint, and the description goes beyond them with important semantics: no scene change and missing/unavailable inspections are unverifiable rather than proof of deletion or success. This adds non-obvious behavioral context that an agent needs to interpret results correctly.

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

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

The description is concise and front-loaded, with the core comparison stated first and caveats following. Every sentence earns its place, though the final 'No scene change' partially duplicates information already available in the annotations.

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 diff tool with an output schema, the description covers the key semantics, safety profile, and result interpretation. It does not explicitly say where snapshot_id comes from or what happens with invalid IDs, but the context is adequate for selecting and invoking the tool.

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

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

With schema description coverage at 0%, the description must carry parameter meaning; it indirectly explains snapshot_id by calling it a retained selected-actor baseline. However, it never names snapshot_id or explains how to obtain/format it, so the compensation is partial despite the parameter name being fairly self-explanatory.

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

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

Description clearly states the operation: compare a retained actor baseline against a fresh read, and lists what it reports (field changes, identity/freshness limits). It is specific about the resource and verb, though it does not explicitly name or differentiate against sibling tools such as unreal_verify or unreal_workflow_inspect.

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 conveys the context in which the tool is useful—comparing a stored baseline with a current editor state—and warns that missing actors are unverifiable rather than deletion proof. It never states when to choose unreal_diff over alternative inspection or verification tools, leaving usage boundaries 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?

Annotations provide idempotentHint and destructiveHint, but the description adds meaningful behavioral detail beyond them: it validates every target before moving the view, preserves actor selection, preserves projection for presets, and clarifies that geometry is not edited. These are useful operational traits that an agent could not infer from annotations alone.

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

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

Four short sentences, each earning its place: what it does, prerequisites, validation behavior, and next step. The key scoping point ('without editing geometry') is front-loaded, and there is no redundant or filler language.

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

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

Covers the important context: prerequisites, validation behavior, viewport restrictions, selection preservation, and the recommended follow-up tool. Since an output schema exists, return-value documentation is not required. The main shortfall is the lack of parameter-semantics explanation, which prevents a perfect completeness score.

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

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

Schema description coverage is 0%, so the description must compensate, but it never names or explains actor_paths, padding, or the view enum values. It obliquely refers to 'explicit actors' and 'presets', but padding's purpose, range, and effect on framing are left entirely to inference. The parameter names and enum carry some meaning, but the description adds very little concrete parameter guidance.

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: 'Frame explicit actors in the current level-editor viewport'. It immediately distinguishes itself from editing tools by adding 'without editing geometry' and from capture tools by ending with 'Follow with unreal_capture'. The purpose is unambiguous and distinct from the listed 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?

Gives concrete usage conditions: requires project binding, a rendered/unlocked editor camera, and perspective viewport for presets. It also suggests the next step, unreal_capture. It does not explicitly name alternatives or state when not to use this tool, so it stops just short of a 5.

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

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

The annotations already indicate this is destructive and not read-only, so the description's extra note that it 'leaves the user's PIE session running' adds valuable nuance about what is and is not cleaned up. It does not contradict the annotations, and it helps prevent an agent from assuming the whole session is terminated.

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 short sentences with no filler. The primary action is front-loaded, and the important side-effect note about the PIE session is placed clearly. 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 simple one-parameter destructive tool, annotations and the output schema cover safety and return values, and the PIE-session note is helpful. However, the description does not explain where job_id comes from, what qualifies as a 'bridge-owned test', or how this tool differs from other cancel tools, leaving an agent with meaningful 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?

The single parameter, job_id, has 0% schema description coverage and is not addressed in the description. The description's reference to 'this bridge-owned test' weakly implies job_id identifies such a test, but it never explicitly explains what job_id should be, where it comes from, or how it maps to the test being cleaned up.

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 concrete action ('Finish/clean up this bridge-owned test') and identifies the resource being acted on. It is clearly a cancellation/cleanup tool, but the terms 'bridge-owned test' and 'PIE session' are jargon that is not explained, and it does not explicitly differentiate it from sibling cancel tools like unreal_validation_cancel or unreal_performance_cancel.

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 use this tool versus alternatives. The phrase 'this bridge-owned test' implies it is for tests started by the bridge, but no conditions, prerequisites, or exclusions are provided, so an agent cannot confidently decide between this and related functional/validation/performance cancel 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds beyond that: it states the tool does not retry and that it reads 'native result and cleanup status.' This is useful behavioral context that the annotations do not convey, and it is consistent with the read-only annotation.

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

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

The description is a single, front-loaded sentence with no filler. Every word earns its place: 'Read' (action), 'functional test's' (resource), 'native result and cleanup status' (what it reads), 'without retrying' (key behavioral boundary).

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 one simple parameter, output schema present, and annotations covering read-only safety, the description is nearly complete. It covers what the tool reads and the non-retry behavior, and the output schema can document return fields. A minor gap is the lack of explicit precondition like 'after unreal_functional_start,' but this is not essential for a read-only polling-style tool.

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

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

Schema description coverage is 0%, so the description must compensate. It identifies the resource as 'a functional test,' implying job_id is a functional test job ID, but it does not explicitly explain the source or format of job_id (e.g., from unreal_functional_start). For a single required string parameter, this is moderate but incomplete.

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 is specific: 'Read a functional test's native result and cleanup status without retrying.' It names the exact resource and action, and the qualifier 'without retrying' distinguishes it from any sibling that may retry or start/cancel tests. It clearly separates this from unreal_functional_start, unreal_functional_cancel, and unreal_functional_tests.

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 use this tool versus alternatives. The phrase 'without retrying' implies a contrast with some retrying tool, but no sibling is named and no usage context is provided (e.g., after starting a functional test, to inspect its final status). An agent would have to infer when this 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?

Annotations already mark this destructive, but the description adds crucial context: 'Trusted test callbacks can change gameplay state' and 'callbacks are not sandboxed.' It also clarifies cancellation/timeout semantics via FinishTest/CleanUp, which is valuable behavioral information beyond the annotation flags.

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?

Five compact sentences, each earning its place. The main action is front-loaded, followed by preconditions, limitations, side effects, and follow-up behavior, with no filler or repetition of structural schema 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 destructive nature, the 2-parameter schema, and the presence of an output schema, the description is complete. It covers when to use it, prerequisites, side effects, exclusions, and how to obtain the result. Nothing essential is left for the agent to guess.

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

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

Schema description coverage is 0%, so the description must compensate. It maps 'exact project/session/world/revision' directly to the required expected_state fields and implies test_id refers to the AFunctionalTest to run. It does not spell out each field individually, but it provides enough semantic grounding for a 2-parameter 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 precise verb and resource: 'Run one approved placed AFunctionalTest in an existing standalone PIE session.' It clearly delimits scope with exclusions ('does not start or stop PIE, run arbitrary functions, retry failures...'), distinguishing it from sibling workflow, validation, and job 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 gives explicit preconditions ('Inspect context and list tests first', 'Requires exact project/session/world/revision') and explicit when-not guidance ('does not start or stop PIE... save maps or certify the whole game'). It also instructs the agent to poll the job for outcomes, which is an actionable follow-up step.

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

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

Annotations already mark it read-only and non-destructive, and the description adds meaningful behavioral detail: execution is disabled by default, configuration location is [JevEditor.FunctionalTesting], and discovery causes no tests, actor loads, or PIE sessions. This goes beyond the structured annotations and gives an agent confidence that the call has 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?

Three tight sentences: the first leads with the purpose, the second gives configuration context, and the third reinforces the no-side-effect guarantee. There is no repetition, filler, or schema duplication.

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, read-only discovery tool with an output schema, the description covers scope, configuration, and behavioral safety completely. An agent knows exactly what to expect and that no execution side effects will occur.

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 there is nothing for the description to document. The baseline of 4 applies, and the description's mention of what is listed (tests and PIE eligibility) is sufficient contextual value.

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

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

The description opens with a specific verb and resource: 'List named project-approved functional tests and the current single PIE eligibility.' This clearly separates discovery from execution-oriented siblings such as unreal_functional_start, unreal_functional_job, and unreal_functional_cancel by stating that no tests run during discovery.

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 choose this tool over alternatives, and no named sibling or condition such as 'use before starting tests' or 'do not use for execution.' The sentence about execution being disabled hints at safe discovery, but does not tell the agent when to invoke this versus start/job/cancel.

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

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

The annotations already establish read-only and non-destructive behavior. The description adds genuinely useful behavioral context: units are centimeters, yaw rotates around the origin, each recipe generates at most 20 Cube operations, and origin conventions differ by layout kind. It doesn't describe the exact return format, but an output schema exists to cover that.

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

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

Four short sentences deliver the core behavior, safety profile, units, rotation behavior, operation limit, origin conventions, and next workflow step. Everything earns its place and the most important information is front-loaded.

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

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

Given the complexity of the nested layout schema, the description covers the essential shared semantics precisely: units, origin, yaw, preview safety, operation limits, and the follow-up apply step. With output schema present, the missing return-value details are not a gap. It is complete enough for an agent to invoke and route the result 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?

The schema has no top-level per-property descriptions, so the description compensates by adding global meaning: centimeters, yaw pivot behavior, operation caps, and per-kind origin semantics. Individual fields like wall_thickness_cm and tread_depth_cm still rely on their names and defaults, so a bit of per-field enrichment is missing.

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: 'Preview a measured grid, staircase or room blockout.' This clearly identifies the domain and distinguishes the tool from sibling preview tools like mesh, surface, or spatial preview. The follow-up 'Review then use unreal_apply(plan_id)' reinforces that this is a preview-before-apply 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?

The description makes the intended workflow clear: preview first, review, then call unreal_apply(plan_id). It also signals when the tool is not appropriate by stating 'No model request or scene mutation.' It does not explicitly compare against alternative preview tools, so it stops just short of full 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is set. The description adds substantial behavioral context: requires explicit material policy, uses centimeter offsets and label prefix/suffix, accepts only exact native StaticMeshActors, refuses custom components/attachments/physics, limits to one bounded copy per source, and clarifies it never clones arbitrary actor state. This goes well beyond what annotations provide.

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

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

The description is dense yet properly front-loaded: purpose first, then requirements, constraints, and workflow. Every sentence adds necessary constraints or steps; no filler. The paragraph structure is logical and the length is justified by the two recipe variants and the explicit refusal conditions.

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 two recipe types, multiple constraints, and a follow-up workflow, the description covers all critical aspects: what it targets, what it refuses, required parameters, and how to proceed after the preview. It even points the agent to result.preview.plan_id and verification_checks, so an agent can call it correctly without additional documentation. Output schema exists, so not describing return values in detail is acceptable.

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

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

Schema description coverage is 0%, so the description carries the full burden for explaining the recipe parameter. It clarifies the two recipe kinds (replace and duplicate), their required policies, offsets, label behavior, and actor constraints. Although it doesn't enumerate every schema field, it conveys the practical meaning and requirements for the discriminator and key properties, which is sufficient for correct invocation.

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 first sentence states a specific action and resource: 'Inspect and preview mesh replacements or one bounded native mesh copy per source.' This clearly distinguishes it from generic preview tools like unreal_preview by restricting to mesh replacements/copies of native StaticMeshActors, and the rest of the description reinforces that 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?

Provides clear usage context: material policy requirements for replace, offset/label behavior for duplicate, and explicit refusals for non-native actors. It also outlines a follow-up workflow (review plan_id, apply separately, run verification_checks with unreal_verify). It does not explicitly name alternative tools for other cases, so it misses the full 'when-not-to-use' contrast, but the constraints strongly imply when this 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?

The description adds valuable behavioral context beyond the annotations: it explains that receipts are session-bound and expire, and that they are not evidence of the current scene. This goes beyond the readOnlyHint and destructiveHint annotations, though it does not detail all behaviors like pagination.

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

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

The description is concise, front-loaded with the main action, and uses a separate paragraph for key constraints. Every sentence adds value with no redundancy.

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

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

Given the tool is read-only with a simple limit parameter and an output schema exists, the description covers the essential aspects: what it lists, the source, and critical caveats. However, it does not specify the output format, but the output schema likely handles that, so it's adequately complete.

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

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

The only parameter, 'limit', is well-defined by the schema (with default, min, max). The description does not add extra semantics, but since it's a simple, self-explanatory parameter, the schema coverage is effectively complete for the agent's needs.

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

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

The description clearly states the tool lists 'native one-shot previews shared with Window > Jev Review', making the purpose clear. However, it does not explicitly differentiate from siblings like unreal_workflow_preview or unreal_preview except by mentioning the specific source, which is somewhat distinct.

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 implies the tool is for listing previews and warns not to apply them, but does not explicitly state when to use this tool over alternatives. It suggests a context of session-bound memory, but lacks a direct comparison to sibling tools.

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

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

Beyond the annotations, the description reveals the key behavioral trait that cancellation is non-destructive because it preserves partial results. It does not explain retry behavior or what happens to finalized captures, but the preservation detail adds real value over the structured fields.

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 sentence with no wasted words; the action, resource, ownership constraint, and result-preservation behavior are all packed in eleven words. Front-loaded and easy to scan.

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 only one parameter, an output schema, and supporting sibling tools, the description covers the essential semantics of cancellation. It could mention prerequisites such as the capture being owned and in-progress, but the core information an agent needs to invoke it correctly is present.

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

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

The schema has 0% description coverage and only one parameter, job_id. The description does not explicitly define job_id, though the noun phrase 'timing capture' and the parameter name make the mapping inferable. A short note about where the ID comes from would have compensated for the missing schema description.

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

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

Description uses specific verb 'Cancel', resource 'timing capture', and scope 'owned', and adds 'preserve its partial result' to distinguish from simple cancellation. This clearly separates it from sibling tools like unreal_performance_start, unreal_performance_job, and unreal_performance_compare.

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 establishes the clear context: call when you own a timing capture and need to stop it while keeping partial data. It does not explicitly name alternatives or exclusions, but the sibling names and 'owned' constraint provide enough routing context for 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?

Annotations already mark the operation as read-only and non-destructive. The description adds behavioral context beyond that: it requires matching protocol/project/session/world, reports specific change metrics, and explicitly states the analytical limitation regarding significance and bottleneck detection. This gives an agent useful expectations about what the tool can and cannot conclude.

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

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

The description is three sentences with no filler. The main action is front-loaded, the reporting behavior is stated next, and the critical limitation closes the description. 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 read-only comparison tool with an output schema, the description covers what is needed before calling: matching context, required input types, output type, and a key analytical limitation. The annotations cover safety, and the output schema covers return structure, so nothing essential is missing.

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

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

Schema description coverage is 0%, so the description must compensate. It does connect baseline and candidate to the two timing receipts and 'configured threshold crossings' to maximum_regression_percent, which is helpful. However, it does not explicitly define how the job IDs are used, what 'complete' means for a receipt, or how the regression threshold is applied, leaving partial gaps.

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 ('Compare') and resource ('two complete native timing receipts') with clear scope restrictions (same protocol, project/session, world). It also states what the tool reports (absolute/percent changes and threshold crossings), making it distinguishable from sibling capture/start/cancel tools.

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

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

The description clearly implies when to use the tool: when two complete timing receipts from the same context need comparison. It also gives an important exclusion by warning that a pair of captures cannot establish significance or identify bottlenecks. It does not explicitly name an alternative, but the context and limitation are clear.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description goes beyond them by disclosing that it reports 'incomplete or changed-state outcomes' – a non-obvious behavioral trait about what state information is returned. This adds context the annotations do not provide.

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

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

The description is a single 13-word sentence, front-loaded with the core action and scope, containing no filler or redundancy. Every word contributes to the meaning.

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

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

For a simple one-parameter tool with an output schema and annotations, the description covers the read-only nature and the kind of data returned. However, it does not explain job_id semantics or when to call the tool, so an agent may not know what value to pass. It is adequate but has 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 0% for job_id, and the description does not explain what job_id refers to, its format, or how to obtain it. The agent can only guess from the tool name that it identifies a performance job, which is a serious gap for the only 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 states a specific action ('Read') and a resource ('timing progress and scope'), and adds detail about outcome states. It does not explicitly name 'performance job' or differentiate from siblings like unreal_performance_start or unreal_performance_compare, but it is not tautological and conveys the core purpose.

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

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

No guidance is given on when to use this tool versus alternatives. There is no mention of prerequisites (e.g., needing to start a job first) or when to prefer this over unreal_performance_compare or unreal_performance_cancel. The agent must infer usage from the tool name and sibling context.

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

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

Annotations are all false, so the description carries the burden of behavioral disclosure. It discloses that the capture is bounded (10..600 samples, 60-second limit), that it is a non-freezing editor ticker capture, and that it does not measure packaged gameplay FPS. It also indicates the operation is asynchronous by saying 'Poll by job id.' This is meaningful behavioral context beyond the schema and annotations.

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

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

The description is three sentences with no wasted words. It front-loads the core action and bounds, then adds exclusions and the polling mechanism. 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?

The tool has an output schema and sibling tools that cover job status and cancellation, so the description does not need to explain return values. It covers the key constraints, exclusions, and async behavior. It could be slightly more complete by mentioning that the capture is tied to a protocol_id and expected_state, but the schema already defines those required parameters clearly.

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

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

Schema description coverage is 0%, so the description must compensate. It explains the sample_count range (10..600) and the 60-second limit, which adds meaning to sample_count. However, it does not explain protocol_id or expected_state beyond what the schema provides. The schema already defines protocol_id as a string pattern and expected_state as an inspected editor state, so the description adds partial value but leaves the key parameters' semantics mostly 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?

The description clearly states the tool starts a bounded editor ticker timing/memory capture with specific sample and time limits. It distinguishes itself from related performance tools by explicitly noting it does not freeze the scene or measure packaged gameplay FPS, and mentions polling by job id, which aligns with sibling tools like unreal_performance_job and unreal_performance_cancel.

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

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

The description provides clear context for when to use this tool: to start a bounded editor ticker capture while holding settings constant in a named protocol. It does not explicitly name alternative tools or state when not to use it, but the negative constraints ('Does not freeze the scene or measure packaged gameplay FPS') help an agent avoid misuse. It could be improved by explicitly referencing sibling tools like unreal_performance_compare or unreal_performance_job.

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?

Beyond the readOnly/destructive annotations, the description discloses retention limits (64 records/2 MiB/15 minutes), unknown transport-loss/cancellation outcomes, staleness after editor changes, durability across MCP reconnect but not editor restart, and no Undo/replay/save. This is substantial behavioral context that the annotations do not provide, and it contradicts nothing.

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 is front-loaded, and every subsequent sentence adds a distinct operational caveat or routing hint. Despite its density, there is no filler; each clause earns its place by preventing a wrong inference about freshness, durability, or side effects.

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

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

For a read-only lookup with an output schema, the description covers selection, freshness, durability, transport behavior, and side-effect absence. The only notable gap, plan_id semantics, is a parameter-level gap rather than a contextual completeness gap, and the tool's caveats are otherwise unusually thorough.

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

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

Schema description coverage is 0%, so the description carries the burden of explaining plan_id, but it never mentions or defines the parameter. The agent is left with only the property name 'plan_id' and maxLength to infer meaning, which is thin for a tool with retention and fallback semantics.

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

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

The description opens with a specific verb-resource pair: 'Review native plan outcome' and adds the fallback behavior to the MCP process's retained observation. It also distinguishes itself from unreal_verify and unreal_diff by positioning them as sources of fresh evidence, which lets an agent separate 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?

The description explicitly says to 'Use unreal_verify or unreal_diff for fresh evidence,' which gives a clear alternative when current state matters. It also implies stale-usage risk by noting records can become outdated after editor changes, though it never states a crisp 'when to use this tool' rule beyond its first sentence.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces 'No scene changes occur,' adding clarity. It also discloses limitations (edits only for exact native, unattached StaticMeshActors, not Blueprint actors), the rule of at most one edit per existing actor, and the invalidating condition (changes to tracked actor state invalidate a plan). This exceeds the annotations by explaining constraints and consequences.

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 dense but well-structured, front-loading the core purpose and safety guarantee. Each sentence adds critical information: what is previewed, safety, units, prerequisites, editing constraints, and expected_state behavior. It is concise given the tool's complexity, with 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?

The description covers the essential constraints: units, rotation degrees, actor type limitations, and the expected_state behavior. It does not detail return values, but an output schema exists to cover that. It also doesn't mention error conditions like invalid paths, but the schema constraints (minLength, maxLength) provide basic validation context. Given the complexity of the operation list and the output schema, this is largely complete.

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

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

Schema description coverage is 0%, so the description must compensate. It mentions operations and the expected_state parameter but does not explain individual parameters like slot, label, or actor_path in detail. The schema provides enough structure for enum and types, but the description adds no semantic detail beyond naming the operations and expected_state's purpose.

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

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

The description clearly states the tool previews bounded actor operations such as spawns, transforms, materials, metadata, mesh swaps, and copies, and explicitly notes no scene changes occur. While it is a multi-operation tool, it is distinguished from sibling tools like unreal_workflow_preview by its focus on bounded actor edits, though it doesn't explicitly name a sibling for contrast.

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 context on when to use the tool (previewing actor changes) and states prerequisites (JEV_EXPECTED_PROJECT), but it does not explicitly contrast with alternatives like unreal_workflow_preview or unreal_spatial_preview. It implies usage through purpose but lacks a clear when-not-to-use or mention of alternative tools.

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

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

The description goes well beyond the annotations. It discloses the ephemeral nature ('15 minutes in this MCP process'), the storage limits ('at most 32 snapshots, 2 MiB total'), the invalidation behavior ('Restarting the server clears all snapshot IDs'), and the non-persistent side effects ('no files, cloud, saves or edits'). This is rich behavioral context that the annotations (readOnlyHint=true, destructiveHint=false) do not provide. No contradiction with annotations.

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

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

The description is compact and front-loaded. The first sentence states the core purpose and the key negative constraints. The second sentence adds the selection scope. The third sentence packs the retention limits and invalidation behavior. Every sentence earns its place; no filler or repetition.

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

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

For a tool with one parameter, an output schema, and annotations covering the safety profile, the description is complete. It covers what the tool does, its scope, its limits, and its lifecycle. The only minor gap is the exact path format, but the schema's minLength/maxLength and the description's 'exact selection' provide enough for an agent to invoke it correctly. The output schema presumably documents the return value, so the description needn't explain 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 0%, so the description must compensate. The description explains the meaning of the parameter indirectly: 'selected-actor baseline' and 'Exact selection only' clarify that actor_paths is a precise list of actors to snapshot, not a scene-wide filter. It also implies the maxItems=20 constraint by emphasizing 'exact selection only'. However, it doesn't explicitly describe the format of the paths (e.g., full path vs. name), which would be needed for full compensation.

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 ('Record'), a specific resource ('selected-actor baseline'), and its purpose ('for later diff'). It also explicitly distinguishes itself from scene-wide operations ('Exact selection only, not the entire scene'), which differentiates it from sibling tools like unreal_diff and unreal_capture. The negative constraints ('no files, cloud, saves or edits') further clarify what the tool does not do.

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 clearly implies when to use this tool: when you need a baseline of selected actors for later diffing. It explicitly states the selection scope ('Exact selection only, not the entire scene'), which is a key usage constraint. However, it does not explicitly name alternative tools or state when NOT to use it (e.g., 'use unreal_diff to compare, use unreal_capture for full scene capture'), so it falls short of a 5.

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

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

Beyond the readOnly/destructive annotations, the description discloses important behavioral details: rotation/scale are preserved, bounds come from the editor, ground targets a world Z plane rather than terrain tracing, and session/world/revision must match native preview. This materially reduces the risk of incorrect invocation.

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

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

The description is four tight sentences with the core operation front-loaded first. Every sentence adds meaningful information: what it does, key constraints, and follow-up workflow. There is no repetition of schema or annotation content.

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

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

Given the rich input schema, output schema, and safety annotations, the description covers the essential non-obvious context: preserved transforms, editor bounds, ground behavior, and the pre-apply verification workflow. It is slightly less complete in explaining when alternatives should be chosen and what 'apply once' precisely refers to.

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

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

With 0% schema description coverage, the description compensates only partly by naming the four recipe kinds and clarifying that ground uses a specified world Z plane rather than terrain tracing. The schema itself provides field names and enumerations, but semantics for fields like axis, anchor, mode, grid_cm, and origin_cm are not enriched by the description.

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

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

The description states a specific verb and resource: preview transformations to existing actors, enumerating align, distribute, snap_grid, and ground operations. It is clear and self-contained, though it does not explicitly distinguish itself from sibling preview tools like unreal_layout_preview or unreal_surface_preview.

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

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

The description gives clear context for when to use it: when measuring existing actors and previewing spatial translations. It adds workflow guidance (review plan_id, apply once, run verification_checks), but it does not explicitly name alternative tools or state when not to use this 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description is consistent with that ('Inspect'). It adds useful context by specifying that this reports live editor state rather than a preview or plan, and enumerates the data areas covered. It does not cover failure modes, but the read-only annotation lowers the 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?

Single sentence, no wasted words, and the key term 'Inspect' is front-loaded. Very efficient.

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

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

For a zero-parameter, read-only status tool with a provided output schema, this description is complete enough: it states what data will be inspected and the safety profile is covered by annotations. The only real gap is alternative routing, which is already penalized under usage guidelines.

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 there is nothing for the description to clarify. Baseline 4 is appropriate.

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

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

The description uses a specific verb ('Inspect') and names a concrete resource set: engine version, project file, session, and world revision. This clearly identifies the tool's role, though it does not explicitly contrast with sibling tools such as unreal_context or jev_status.

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

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

No guidance is given on when to prefer this over the many sibling inspection tools, and no alternatives or exclusions are mentioned. The word 'actual' implies current-state inspection, but that implication is not developed into usable selection 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?

Annotations include readOnlyHint=false, but the description says 'preview' and 'Requires a native mesh actor,' which implies a read-only inspection. The description contradicts annotations indirectly by implying mutating behavior (readOnlyHint false) while the name and language suggest a preview. Beyond that, it does not disclose side effects, output format, or what 'reject' means behaviorally.

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 short and front-loads the action, but it includes a confusing sentence 'Does not apply' that adds no clarity. It could be more concise and structure information logically, but it is not overly verbose.

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

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

Despite having an output schema, the description lacks critical context: it doesn't explain what the output contains, how the agent should interpret 'preview' results, when to reject with errors, or how to proceed after preview. The requirement for a 'native mesh actor' is noted but not defined. Siblings like unreal_apply and unreal_preview imply a workflow, but the description does not connect this tool to them beyond a vague reference.

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

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

Schema description coverage is 0%, meaning the description must explain parameters. The description mentions 'trace,' 'slopes/overlap,' and 'measured transform,' but does not explain the purpose of 'query,' 'trace_up_cm,' 'surface_paths,' 'align_to_normal,' or 'max_slope_degrees.' The nested object's parameters remain completely unexplained, leaving the agent to infer from names 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 states the action ('Trace to approved collision surfaces... preview'), the resource (surfaces), and a distinct purpose (filtering and preview) that separates it from the sibling unreal_apply. It is not a tautology, though it does not explicitly name a sibling to contrast against.

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

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

The description mentions 'Review the trace and native scene plan, then use unreal_apply' and 'Requires a native mesh actor,' which gives some direction. However, it does not specify when to choose this tool over siblings like unreal_spatial_preview or unreal_mesh_preview, nor does it provide explicit exclusions beyond the vague 'Does not apply.'

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces this with 'Bounded diagnostic inspection only'. It adds useful behavioral context about the tool's limited scope: inspection focuses on scan_incomplete and per-check evidence rather than full project certification. No contradiction with annotations is present.

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-loaded: the first sentence states the core action, and the second adds essential boundaries in one efficient phrase. Every sentence earns its place with no redundant 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 overall purpose and safety profile are clear, and the output schema exists, but the two input parameters, especially 'query', are not explained at all. An agent cannot fully know how to invoke the tool correctly (what to pass as a query or what the limit constrains). This is a meaningful completeness gap for a tool that otherwise has good safety and scope disclosure.

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

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

Schema description coverage is 0%, so the description must compensate, but it does not explain either parameter. 'limit' and 'query' remain entirely undocumented in both schema and description. The mention of mesh/material/collision/scale warnings hints at what might be queried, but this is not connected to the actual query parameter semantics.

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

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

The description states a specific verb and resource ('Check loaded editor actors') and lists concrete inspection domains (mesh, material, collision, scale warnings). It also explicitly says it does not compile Blueprints, run gameplay, or certify the project, which helps distinguish it from compile/certification tools, though it does not clearly differentiate from the similarly named 'unreal_verify' sibling.

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

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

The description gives clear context: this is a bounded diagnostic inspection of loaded editor actors. It also provides exclusions ('does not compile Blueprints, run gameplay, or certify the complete project'), which prevents misuse. However, it does not name specific alternative tools or give explicit when-to-use versus when-not-to-use criteria beyond those 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?

Annotations already indicate destructive and non-idempotent behavior. The description adds the important caveat that cancellation does not undo validator side effects, which tells the agent that this operation has persistent consequences beyond simply stopping a pending task.

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 deliver the core action and the critical side-effect caveat with no filler. The main behavior is front-loaded, and every phrase 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 simple one-parameter cancel tool with a destructiveHint annotation and an output schema, the description covers the essential action and the key behavioral consequence. It leaves minor gaps around how job_id is obtained and what 'between callbacks' precisely means, but these are not blocking for correct selection and 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?

The schema documents job_id only as a string with length constraints and 0% description coverage. The description does not explicitly explain what job_id refers to, how to obtain it, or how it relates to the pending validation, so it fails to compensate for the missing schema-level semantics.

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

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

The description uses a specific verb ('Cancel') and a clear resource ('pending validation'), and the phrase 'Does not undo validator side effects' adds precision about what the tool does not do. This distinguishes it from sibling tools like unreal_validation_start and the unrelated cancel tools.

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

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

The description gives clear context: use this when a validation is pending between callbacks and needs to be canceled. It does not explicitly state when not to use it or name alternatives, but the resource-specific wording is enough to route an agent away from functionally similar siblings like unreal_functional_cancel.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description does not need to restate safety. It adds value by specifying 'authoritative bounded errors' and the behavioral prohibition 'never restart it', which goes beyond the annotations. No contradiction exists.

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 entire description is one compact sentence. Every phrase earns its place: 'Read' states the action, 'native validation job' names the target, 'authoritative bounded errors' clarifies the output, and 'never restart it' gives a critical safety guard.

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 one-parameter, read-only tool with an output schema and safety annotations, the description covers what the agent needs to invoke it safely. A minor gap is that 'native' is not defined and the source of job_id is not mentioned, but these are not blockers given the output schema and simple input.

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

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

With schema description coverage at 0%, the description carries the burden for parameter meaning. job_id is a single simple identifier whose role is inferable from the description, but the description does not explain where the ID comes from or provide any additional constraints. The schema's own title 'Job Id' and min/max length cover the technical limits.

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 the specific verb 'Read' and identifies both the resource ('native validation job') and the result ('authoritative bounded errors'). This makes the tool's purpose immediately clear and distinguishes it from mutating or job-control siblings such as unreal_validation_start and unreal_validation_cancel.

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 read-only usage and explicitly warns 'never restart it', which is a useful exclusion. However, it does not name alternatives or state when to choose this tool over related validation tools, leaving the agent to infer the routing from the sibling list.

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

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

Annotations already mark the tool readOnly and non-destructive. The description adds important non-schema behavior: the tool is disabled unless project policy enables it, and only loaded native validator classes are eligible, so results are not exhaustive across all possible rules.

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

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

Three short, purposeful sentences lead with the core purpose, then add the two most important constraints. No filler or repetition of schema/annotation 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 parameterless listing tool with an output schema, the description provides the purpose and the key eligibility/availability constraints. Nothing else is needed for an agent to decide whether and how to call 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?

The tool takes zero parameters, so there is no parameter meaning for the description to add. The schema coverage is complete and the baseline of 4 applies.

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

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

The description opens with a specific verb+resource: 'List named project-approved native Data Validation rules and their availability.' This clearly distinguishes the tool from sibling validation/workflow tools by scoping to rule discovery rather than executing or inspecting jobs.

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

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

The description gives clear context: the tool lists project-approved native rules only, and it explicitly excludes Blueprint/Python rule discovery. It does not name alternative sibling tools for those cases, but the scope constraints make the appropriate use case 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?

Beyond the destructiveHint annotation, the description discloses side effects, cooperative cancellation, absence of automatic retries, that nothing is saved, and that 'not_validated is never a pass.' It also explains automatic binding to the authenticated project and rejection on editor changes. This is rich, non-obvious behavioral context that the annotations alone do not provide.

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

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

The description is dense but efficient; the core purpose is front-loaded, and each following sentence adds meaningful caveats. Some jargon ('PIE', 'expected project binding') is terse, but the overall size is appropriate for a tool with notable behavioral complexity.

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

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

Given the destructive, non-idempotent nature, the description covers the necessary operational expectations: side effects, no retries, cooperative cancellation, polling via job_id, nothing saved, and project-binding behavior. An output schema exists, so return-value documentation is not required here. The description is complete enough for an agent to invoke this tool correctly.

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

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

Schema description coverage is 0%, but the description maps 'validators' to rule_ids and 'exact assets' to asset_paths. It does not further specify the expected identifier format, path syntax, or how the rule_ids are obtained beyond implying they are approved project validators. This provides partial compensation for the missing schema descriptions.

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

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

The description opens with a specific verb and resource: 'Run only selected approved project validators on exact assets as a bounded native job.' This clearly identifies the operation and scope, and distinguishes it from related sibling tools like unreal_validation_rules (listing) and unreal_validation_job (querying results).

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 practical usage context: listing validators is separate from authorization, this adapter requires an expected project binding, no PIE or retries, and callers should poll the returned job_id. It stops short of explicitly naming sibling alternatives for listing vs. running, but the guidance is enough to steer an agent toward correct use.

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

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

Annotations only declare read-only and non-destructive behavior; the description adds substantial operational detail: per-check result states, a 20-selected-actor limit, 'missing evidence never passes,' world-axis bounds instead of collision clearance, and identity/revision behavior after edits. This is exactly the kind of non-obvious behavior an agent needs and goes well beyond the annotations.

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

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

Five dense sentences, front-loaded with the core operation, followed by constraints and edge cases. Every sentence contributes new information and none merely repeats schema or annotation content. The size is appropriate for a verification tool with multiple check types and revision-sensitive behavior.

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 rich input schema, output schema, and read-only annotations, the description covers purpose, invocation context, result semantics, and key edge cases. It could be slightly more complete by explicitly naming sibling alternatives and clarifying how to obtain the pre-edit identity, but nothing essential for selecting the tool is missing.

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

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

Schema description coverage is 0%, so the description must compensate. It does add meaning: it clarifies expected_identity/expected_revision semantics ('pre-edit identity ... not its old revision'), defines how gap axes are measured, and caps verification at 20 selected actors. It does not walk through every nested check field, but the schema's detailed titles, defaults, and discriminator carry much of that load.

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 exact actors again and check explicit transforms, bounds, gaps, materials or labels.' It also states the result vocabulary (passed/failed/unverifiable per check), which sharply separates verification from preview, apply, or inspection tools 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?

It gives a concrete invocation context: after an edit, use the pre-edit identity but not the old revision, because edits change revisions. It also provides exclusions ('checks supplied requirements locally; it does not infer them or run gameplay'), so an agent knows this is not for inferred validation or gameplay simulation. It stops short of explicitly naming sibling alternatives, but the context is clear.

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

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

Annotations say destructiveHint=true and idempotentHint=false, but the description goes beyond: it specifies no auto retry, notes partial application on timeout (must inspect receipt), explains undo behavior per change type, and warns about visual capture for material/light. This is critical for safety and not in annotations.

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

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

Four concise sentences, each imparting necessary operational detail. Front-loaded with the core action and return format, then safety and failure handling. No wasted words; fully justified.

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 complexity (destructive, non-idempotent, side effects) and rich output schema, the description covers the key points: single application, partial failure, side effects on undo, and post-conditions for capture. Minor gaps: doesn't specify how to interpret before/after state format, but output schema likely handles that.

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

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

Schema has only one parameter (plan_id) with zero description coverage, so the description should add meaning. It mentions 'domain plan' which implies plan_id refers to a plan, but doesn't spell out the type or format (e.g., UUID vs name). Lacks explicit correlation but is acceptable given single param.

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 it applies a 'reviewed domain plan once' and returns before/after state, making the core action clear. It distinguishes itself from siblings like unreal_workflow_preview (preview vs apply) and unreal_apply (another apply tool), though it doesn't explicitly name them.

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 context for when to use: after a plan is reviewed, and notes no automatic retry. It doesn't explicitly mention alternatives, but the 'reviewed' qualifier implies it should be used only on reviewed plans, and bad outcomes route to unreal_workflow_receipt. Missing explicit when-not-to-use.

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