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

With no annotations, the description carries full responsibility for behavioral disclosure. It lists what information is returned but does not state that the operation is read-only, side-effect-free, or non-destructive. The nature of the tool strongly implies a query, but the description never explicitly confirms that it performs no mutations or has no external effects.

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

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

The description is a single line that lists the four content categories directly. It is efficient, front-loaded, and contains no fluff or unnecessary prose.

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 absence of an output schema, the description effectively describes the return content (tool list, format matrix, limitations, runtime status). It is sufficient for an agent to understand what to expect, though it lacks detail on the structure or granularity of the output. For a zero-parameter meta-tool, this is reasonably 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 tool has zero parameters, so the schema already fully documents them (empty object). Baseline 4 applies; the description adds nothing parameter-related, which is appropriate because no parameters exist.

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

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

The description explicitly names the resource content: tool list, supported format matrix, limitations, and native runtime library status. It clearly distinguishes this meta-tool from the project-specific siblings (project_inspect, il_read, etc.) by focusing on environment-wide capabilities rather than any single artifact.

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

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

The description provides no explicit guidance on when to use this tool vs alternatives. It does not state that it should be used to discover available tools or formats before calling other operations, nor does it mention any exclusions. Usage context is only weakly implied by the tool's name and content, but not articulated.

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

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

With no annotations provided, the description carries the behavioral burden. It discloses meaningful details: the copy is published only after success, old artifacts are isolated, and remaining files are verified. This goes well beyond a generic patch/copy statement, though it stops short of describing exact failure modes or source-modification guarantees.

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

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

The description is a single compact sentence that front-loads the main action, then adds essential success semantics without filler. 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 three required parameters, 100% schema coverage, no output schema, and no annotations, the description provides enough context to select and invoke the tool: it explains the batch scope, non-overlap requirement, success-gated publishing, and artifact isolation. It does not explicitly describe return values or detailed failure behavior, but those are secondary when the schema already covers parameter meaning.

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

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

Schema description coverage is 100%, and the input schema already documents all three parameters with constraints and meanings, including dest being a nonexistent directory and patches being organized by file with expected_sha256 and edits. The prose description adds no extra parameter-specific detail, so the baseline of 3 is appropriate.

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

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

The description states a specific action: verify multiple files and multiple non-overlapping patches in one pass, then publish a copy only on success. The 'batch' and 'multi-file/multi-patch' wording clearly distinguishes it from single-patch sibling tools like il_patch_copy.

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 this tool is for batch scenarios with multiple files and non-overlapping patches, but it never explicitly names when to choose this tool over alternatives like il_patch_copy, nor does it list exclusions or fallback conditions. The usage context is present but must be inferred.

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

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses that the source project is not modified and that invalid caches/stale artifacts are moved to quarantine. It does not describe failure modes, return semantics, permission requirements, or behavior when old_text is not unique or expected_sha256 mismatches.

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

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

The description is one dense sentence with no filler; the key constraint, action, and side effect are all present. The long Chinese clause chain makes it slightly less scannable than separate short sentences, 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 7-parameter tool with no output schema and no annotations, the description covers the high-level outcome and a key side effect, and the schema covers parameter details. It omits expected return values, failure behavior, and how quarantine relates to the quarantine parameter, leaving it minimally adequate but not fully 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 100%, so the baseline is 3. The description reinforces concepts like 'unique match' and quarantine, but it does not add meaning beyond the parameter schema, which already documents old_text uniqueness, dest non-existence, and expected_sha256 concurrency protection.

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 operation: generate a new project copy with a unique-matching text patch applied, without modifying the source project, and quarantine stale/invalid artifacts. This is specific about verb and resource, though it does not explicitly name or differentiate sibling tools like ld_to_il_copy or native_compile_copy.

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

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

The phrase '在不改动源工程的前提下' implies the tool is intended for scenarios where the source must remain untouched while a patched copy is produced. However, it gives no explicit when-to-use/when-not-to-use guidance and does not compare against sibling copy/patch tools, so an agent must infer the appropriate selection 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?

No annotations are provided, so the description is responsible for behavioral disclosure. It discloses encoding (GBK) and line ending normalization (LF), which are important. However, it does not specify whether the tool returns the raw content, handles missing files, or errors on non-plain-text. For a read-only tool, the absence of side-effect warnings is acceptable, but the return behavior is left implicit.

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

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

The description is a single, front-loaded sentence that specifies the verb, resource, and key format details (plain-text, GBK, LF). No wasted words; efficient and clear.

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

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

For a simple two-parameter read tool, the description is essentially complete. It covers the file type (plain-text .IL), encoding, and newline handling. It does not mention error conditions or the return type, but those can be inferred (returns the text). The absence of an output schema and the low complexity mean the description does not need to explain much more.

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

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

Schema description coverage is 100% – both parameters (project and file) have descriptive comments. The tool description itself does not add any extra meaning to the parameters, but it reinforces that the file is a plain-text .IL POU. Since the schema already documents the parameters clearly, a baseline of 3 is appropriate.

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

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

The description states a clear, specific action: read the IL source text of a plain-text .IL POU. It also notes the file is plain-text and specifies encoding (GBK) and line endings (LF), which makes the purpose unmistakable. While it doesn't explicitly name sibling alternatives, the resource and verb are so specific that an agent can easily distinguish it from the copy/probe siblings.

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

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

The description implies its use case: reading plain-text .IL source files. It does not explicitly say when to use this over siblings like il_patch_copy or ld_to_il_copy, nor does it mention exclusions (e.g., not for binary files). However, the 'plain-text' qualifier and the read action give enough implicit guidance for a simple 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?

With no annotations, the description carries the burden, and it does more than the bare verb: it discloses independent IL readback, cache-clearing compile, and a machine-code-consistency gate before delivery. It does not say what happens on mismatch or what filesystem side effects '清缓存' has, so it is not fully transparent.

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 dense, front-loaded sentence: purpose first, then verification condition. There is no filler, and every clause carries operational 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?

The description is sufficient to invoke the tool for a straightforward IL→LD conversion with verification, and the schema covers parameter details. It lacks explicit failure behavior and return/output semantics, which matters more because there is no output schema or annotations.

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

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

Schema description coverage is 100%, so the parameters are already documented; the description adds no per-parameter meaning. Baseline 3 is appropriate because the tool-level context is useful but does not elaborate on project/file/dest syntax.

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 conversion ('原厂 IL 转梯形图') plus a verification workflow, so the core action is unmistakable. The direction IL→LD also distinguishes it from the sibling ld_to_il_copy without needing to open the schema.

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

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

It gives clear context: this is for converting original factory IL to ladder and delivering only after machine-code verification. It does not explicitly name alternatives or state when-not-to-use, but the '原厂' qualifier implies the scoping condition.

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

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

With no annotations, the description carries the full burden and discloses key behaviors: it calls an original vendor API, requires byte-identical compiled artifacts before delivering a new copy, and needs no GUI. It does not detail failure handling or effects on an existing dest, but the core safety gate and external-call behavior are clearly stated.

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 tight sentence front-loads the main action, then states the critical delivery condition, then adds the GUI note. Every part earns its place with 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 conversion/copy tool with four parameters and no output schema, the description covers the essential semantics: what is converted, how delivery is gated, and that it is headless. It could be more complete by naming sibling alternatives or failure behavior, but the core information needed 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?

Schema coverage is 100%, so the schema already documents all four parameters. The description adds global context about converting LD to editable IL but does not explain individual parameters beyond the schema, so the baseline 3 applies.

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

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

States a specific action: invokes the vendor interface to convert a specified LD into editable IL, and qualifies the delivery with a byte-identity condition. This makes it clearly distinct from siblings like il_read or native_compile_copy, which involve reading or native compilation rather than LD-to-IL conversion.

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 an automated/headless use case via '无需 GUI' and states the delivery condition, but it does not say when to prefer this tool over sibling tools such as il_read or native_compile_copy, nor does it list any exclusions. Usage context 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 no annotations, the description carries the behavioral disclosure burden and does well by revealing that it operates on a fresh copy, validates complete coverage, stable artifacts, and unchanged configuration, and outputs a ZIP only on success. It does not detail failure behavior or cleanup, but the main safety-relevant traits are covered.

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

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

The description is a single dense sentence with no filler; each clause adds operational information, the core action is front-loaded, and the environment constraints are concise. 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 compilation tool with no output schema, the description adequately covers purpose, isolation, verification criteria, output behavior, and execution environment. The main gaps are lack of explicit failure/error semantics and exact output format, but the essential context for calling 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?

Schema description coverage is 100%, and each parameter already has meaningful inline documentation such as read-only project, dest must not exist, and DLL fingerprint matching. The description adds overall compilation context but no parameter-specific semantics beyond the schema, so baseline 3 is appropriate.

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

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

The description states a specific action and resource: invoking the original vendor x86 DLL to compile H3U IL/LD in a fresh copy, with verification and a ZIP output. It also distinguishes itself by emphasizing copy-based isolation, no GUI, and no PLC connection, which separates it from siblings like project_inspect or native_compile_probe.

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

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

The description provides clear usage context: this is for headless compilation of H3U IL/LD using the vendor DLL, without connecting to a PLC. It does not explicitly name alternatives or state when not to use it, so it stops short of a 5.

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

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

With no annotations, the description carries the full burden of behavior disclosure. It discloses that the tool is static, does not execute DLLs, does not fake compilation, and reports specific metrics. This is above-average transparency for a tool without annotations, though it omits details about return format or possible edge-case behavior.

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

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

The description is a single, well-structured sentence that front-loads the core purpose and includes critical negative guarantees at the end. Every word earns its place, and it avoids redundancy.

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

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

For a simple probe tool with three optional parameters and no output schema, the description covers the essential aspects: what it reads, what it reports, and its non-destructive nature. It does not describe the exact return format, but given the tool's scope and the presence of a descriptive schema, this is an acceptable gap.

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

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

The input schema already describes all three parameters with 100% coverage (dlls, evidence, install_dir). The description loosely references 'PE evidence/install directory' which maps to evidence and install_dir, but does not add significant new meaning beyond what the schema provides. Since coverage is high, a baseline of 3 is appropriate.

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

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

The description states a specific verb (reads), resource (PE evidence/install directory), and specific outputs (architecture, SHA256, compile-related exports). It also explicitly excludes execution and fake compilation, which distinguishes it from sibling tools like native_compile_copy or il_patch_copy. Clear and unambiguous.

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

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

The description implies this is a static inspection tool and explicitly says it does not execute DLLs or fake compilation, which conveys a safe, read-only usage context. However, it does not name alternative tools or provide explicit guidance on when to choose this over siblings. Usage is clear but not fully explicit about 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?

With no annotations provided, the description carries the full burden. It discloses useful behaviors such as excluding derived tables/stale compilation results and producing a hash manifest. However, it does not mention whether the source tree is modified, whether existing files are overwritten, or any side effects beyond creating the ZIP.

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

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

The description is a single compact sentence that front-loads the primary purpose, then adds the key exclusions and output format in parentheses. Every element is meaningful and there is no redundant 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?

Given the moderate complexity, the description sufficiently explains the tool's output (ZIP plus SHA256/CRC32 manifest) and its core exclusion policy. It does not spell out the full manifest contents or detailed handling of stale artifacts, but the essentials needed to invoke and interpret the result 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?

The input schema already covers all three parameters with 100% description coverage, including include_stale's default behavior. The tool description adds little beyond restating the exclusion behavior that is already present in the schema, so the baseline score of 3 is appropriate.

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

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

The description states a specific action ('packages source code and configuration') and the concrete deliverables (a ZIP archive and a SHA256/CRC32 manifest). This clearly separates it from sibling tools like project_inspect or native_compile_copy, which serve different purposes.

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 clarifies what is included and excluded during packaging, giving clear operational context. It does not explicitly name alternative sibling tools or state when not to use it, but the packaging role is distinct enough that the usage context is unambiguous.

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

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

No annotations are provided, so the description carries the full burden. It discloses the specific checks performed and explicitly excludes simulation and logic proof, which is good. However, it does not state whether the operation has side effects (likely read-only, but not confirmed) or describe the output format.

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

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

A single, compact sentence that front-loads the primary function (static checks) and adds exclusions. No wasted words; every part adds value.

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

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

For a tool with one parameter and no output schema, the description adequately covers what the tool does and what it does not do. The main gap is the lack of explicit side-effect or return-value information, but given the simplicity, this is reasonably complete.

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

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

The schema covers 100% of the parameter, describing 'project' as a complete directory with an HCP index. The description does not add additional syntax or format details beyond the schema, so baseline 3 is appropriate.

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

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

The description clearly states it performs static checks (缺失文件、多处 OUT、跨块写入和未知指令) on a project, using a specific verb 'audit' and resource 'project'. It distinguishes from simulation tools by explicitly stating what it is not, though it does not name specific 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 explicitly states it is 'not running simulation or logic qualification proof', giving a clear when-not-to-use condition. However, it does not reference alternative tools or provide context for when it should be chosen over siblings like project_inspect or project_diff.

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

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

With no annotations, the description carries the behavioral burden and does add one important guarantee: '失败不发布中间工程' (on failure, intermediate project is not published), implying transactional behavior. However, it does not disclose success outputs, whether the source project is mutated, required permissions, or what artifacts are produced, so transparency is partial.

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 dense sentence that front-loads the composite workflow and ends with the critical failure behavior. There is no filler or repetition, and every clause contributes decision-relevant 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 5-parameter tool with no annotations and no output schema, the description gives the essential orchestration-level context and the key failure guarantee. Still, it leaves unspecified the return or artifact details, execution order, and success behavior, though the rich schema covers parameter-level facts.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does reinforce how the pipeline stages map to meaningful parameter groups, particularly that patch hashes relate to converted IL, but the detailed semantics are already well documented in the input 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 names a specific composite workflow: optional full LD conversion, multi-file patching, factory compile, and packaging in one call. This distinguishes it from the granular sibling tools like il_batch_patch_copy, native_compile_copy, and package_project. It stops short of an explicit verb-resource statement about copying or building into dest, so it's clear but not maximally precise.

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

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

The phrase '一次调用' clearly signals that this tool is for combining multiple pipeline stages into a single invocation rather than calling siblings separately. This provides clear usage context, but the description does not state explicit when-not-to-use conditions or name specific alternative sibling tools.

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

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

With no annotations, the description carries the behavioral disclosure burden. It does this well by stating sequential conversion, per-item machine-code equivalence verification, and final compile/deliver; '交付' remains slightly vague but the core side effects are visible.

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 that front-loads the core conversion and then states the verification and delivery stages; every clause is informative 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 operation's steps are clear, but with no output schema the description does not cover return values or behavior if machine-code equivalence fails, which an agent would reasonably need for a verification-heavy 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?

All three parameters are fully described in the schema, so the description is not required to add parameter detail. It adds no extra meaning beyond the schema, matching the baseline.

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

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

The description names the exact operation: convert all LD in the project to IL, with verification and a final compile/delivery step. This distinguishes it from sibling tools like ld_to_il_copy or project_build_copy by signaling batch conversion plus compilation.

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

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

The intended batch use is implied by '全部 LD' and '最后统一编译交付', but there is no explicit statement of when to prefer this over ld_to_il_copy or project_build_copy, nor any exclusions for single-block conversions.

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

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

With no annotations provided, the description carries the full burden. It does disclose what the tool analyzes (file changes, IL text diffs, config/index changes), which is useful. However, it does not clarify whether the operation is read-only, whether it modifies anything, what output format is returned, or any performance/availability considerations.

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, well-structured sentence that front-loads the core action and then enumerates the diff categories. Every clause earns its place with 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?

Given the tool has only two required string parameters and no output schema, the description does a reasonable job of stating what the comparison covers. It lists the diff categories, which gives an agent expectations about the result. A small gap remains: it does not describe the exact output format or any error conditions, but this is acceptable for a focused comparison tool.

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

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

Schema coverage is 100%, and both parameters (before, after) are documented as old and new project directories. The description reinforces that these are directories to compare, but adds no detail beyond the schema about expected formats, path types, or constraints.

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

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

The description uses a specific verb ('对比' / compare), names the resource ('两个工程目录' / two project directories), and lists concrete comparison dimensions: added/deleted/modified files, IL text diff, and config/index changes. This clearly differentiates it from siblings like project_inspect or il_read, which are about inspecting a single project or reading IL rather than computing a diff.

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

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

Usage is implied: an agent can infer to use this tool when needing to compare two project directories. However, the description does not explicitly state when to prefer it over alternatives, nor does it mention exclusions or prerequisites such as requiring both directories to exist or be valid project layouts.

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

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

With no annotations provided, the description carries full behavioral burden. It implies side effects by exporting files to a new directory, but does not clarify whether the source project is modified, what response is returned, or what happens on errors. This leaves important operational behavior undisclosed.

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 compact sentence front-loads the verb, output contents, destination, and purpose. There is no redundant or filler content.

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

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

The core information is present: two well-described parameters, a clear export target, and the review-oriented purpose. However, the lack of annotations, absence of an output schema, and no sibling differentiation leave the agent with gaps around return behavior and tool selection.

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

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

Schema description coverage is 100%: both required parameters ('project' and 'dest') have meaningful descriptions. The tool description adds context about the output contents but does not materially improve parameter understanding beyond the schema, so the baseline 3 applies.

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

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

The description states a clear verb ('导出' / export) and specific output artifacts (UTF-8 IL text, hashes, references, static check JSON) to a new directory. This makes the tool's function identifiable, though it does not explicitly contrast it with sibling tools like package_project.

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

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

The phrase '供审查' (for review) implies an intended use case, and the schema preconditions (complete project, new non-existent destination) provide some context. However, there is no explicit guidance on when to choose this tool over alternatives or when not to use it.

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

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

No annotations are provided, so the description must carry the burden of behavioral disclosure. It states it lists information, implying a read-only operation, but does not explicitly confirm safety, mention output format, pagination, or any side effects. For a tool with no annotation coverage, this is a significant gap.

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

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

The description is a single sentence, front-loaded with the action and the list of data it returns. There is zero waste; every phrase adds 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 simple listing tool with one well-described parameter, the description is mostly complete. However, it does not mention the output format or any error conditions. Given the lack of annotations, a more explicit statement of read-only behavior and return structure would improve 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 'project' has a schema description that fully explains it as a directory containing a unique .hcp file. Since schema description coverage is 100%, the description adds no additional meaning beyond the schema, so a baseline of 3 is appropriate.

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

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

The description clearly states a specific verb ('列出' / list) and resource (project machine types, POU/file types, SHA256, support levels, derived tables). It is distinct enough from siblings like il_read or project_diff, though it does not explicitly name an alternative.

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. The description only states what it does, leaving the agent to infer usage context. There is no mention of when to prefer it over project_diff or other inspection tools.

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

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

With no annotations provided, the description carries the full burden. It discloses scope (literal text, not regex implied by 'literal') and a key limitation (LD/protected blocks), and states output includes file, line, and context. However, it does not explicitly say the operation is read-only or describe any side effects, leaving some safety profile implicit.

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

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

A single sentence with the main action front-loaded and the exclusion clause appended compactly. Every word earns its place, 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?

For a simple search tool with fully documented parameters, the description covers purpose, output (file/line/context), and scope limitation (LD/protected). It lacks a precise return schema, but the stated output elements are sufficient for most use cases.

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

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

Schema description coverage is 100%, so the schema already explains all five parameters. The tool description adds no additional parameter-specific meaning beyond restating 'literal text', which is already in the query parameter description. Baseline of 3 applies.

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

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

The description clearly identifies the tool as searching literal text within registered IL and returning file, line numbers, and context. It explicitly states that LD/protected blocks are not covered, which distinguishes it from sibling tools like il_read or project_xref without opening 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 provides an exclusion (LD/protected blocks not covered), which implies when not to use it, but it does not name alternative tools or give explicit when-to-use guidance. Usage context is largely implied rather than directly 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?

With no annotations, the description carries the behavioral burden. It usefully discloses a key limitation: range, implicit double-word, and indirect addresses are not guaranteed complete. It also implies a read-only listing operation, though it does not describe output format or failure behavior.

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

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

The description is a single sentence that front-loads the core action and result, then appends the important completeness caveat. There is no filler and no 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?

For a simple two-parameter tool with no output schema, the description provides enough to understand the purpose and a critical limitation. It does not fully specify the return structure, but the stated output content and caveat are largely sufficient 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 100%, so the schema already explains `project` and optional `device` with examples. The tool description adds no additional parameter-level semantics beyond the general explicit-address focus, matching the schema baseline.

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

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

The description names a specific verb and resource: it lists the instructions and read/write classification for explicit device addresses. It states the scope and exclusions clearly, but it does not explicitly differentiate itself from sibling tools such as project_search or symbols_read.

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?

Intended use is implied: use it when you need cross-reference information for explicit device addresses. However, it does not explicitly state when to prefer this tool over alternatives, nor does it name any when-not conditions or sibling substitutes.

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

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

With no annotations, the description carries the behavioral burden. It discloses meaningful traits: a separate process reads back results, machine code must match before/after, and only a new copy is delivered. It does not state what happens on mismatch or explicitly guarantee the source tree is untouched, but it is substantially transparent.

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

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

The description is one dense, front-loaded sentence with no filler. Each clause contributes either to what the tool does, how it verifies, or what it outputs.

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 schema richly documents all five parameters, including index=-1 semantics, expected_sha256 source, and the nonexistent-dest requirement. The description adds the critical verification and copy-only behavior. Failure-mode behavior is unspecified, but the information needed to invoke the tool correctly is essentially 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 100%, so the baseline is 3. The description reinforces the add-versus-modify intent and the copy/verification workflow, but it adds no per-parameter detail beyond what the schema already provides.

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

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

The description states a clear verb and resource: '新增或修改全局符号' (add or modify global symbols), and distinguishes itself from read-only siblings like symbols_read by specifying separate-process read-back and copy-only delivery. An agent can tell what this tool does and how it differs.

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

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

The description implies the tool is for modifying global symbols while producing a fresh copy, but it never explicitly says when to prefer it over alternatives such as symbols_read, il_patch_copy, or project_build_copy. It gives no when-not-to-use guidance.

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

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

With no annotations provided, the description carries the behavioral transparency burden. It explicitly states the operation is a read ('读取') and restricts execution to project copies, which implies non-destructive intent. It does not mention side effects or permissions, but for a read-only-style tool this is sufficient and more informative than the tool name 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?

The description is a single compact sentence with no filler. Each clause contributes meaning: the resource and action are front-loaded, and the operational constraint is appended without repetition. It is exemplary in brevity and structure.

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 straightforward read tool with two well-documented parameters and no output schema, the description covers the essential behavior and constraints. It specifies the data read (names, addresses, comments) and the execution scope (project copy). Some details like output format are absent, but they are not critical for selecting or calling 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 100%, so the schema already documents both parameters. The description adds no parameter-specific information beyond what the schema provides (e.g., project copy context matches the schema's '含唯一 HCP 索引的完整工程目录'). Baseline 3 applies because the schema does the heavy lifting.

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

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

The description clearly states a specific verb (读取/read) and resource (global symbol names, addresses, comments), and adds a key constraint (只在工程副本中运行) that distinguishes it from write/patch siblings like symbols_patch_copy. An agent can tell exactly what this tool does and what it 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 implies usage context by requiring a project copy, but it does not explicitly say when to prefer this tool over alternatives such as symbols_patch_copy or il_read. It offers no 'use this when' or 'not when' guidance, only a technical constraint.

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