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

With no annotations, the description must carry the behavioral burden; the explicit verb '读取' does signal a read-only operation and the format list explains which backends are used. It does not mention errors on unsupported files, file-size performance, or what happens when metadata is unavailable, leaving some behavioral uncertainty.

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 front-loads the purpose in a single sentence and then gives only the supporting format and argument details. Every sentence adds information 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?

For a one-parameter metadata reader with no output schema, the description covers the expected return facets (type, item names/units, time axis, grid size), accepted file families, and the required absolute path. It could be more complete by noting failure behavior on invalid paths or unsupported files, but nothing essential is missing for normal 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?

Although schema description coverage is 0%, the Args section supplies 'path: 结果文件绝对路径', adding the crucial requirement that the path be absolute, which the bare schema ('Path') omits. The supported-format list in the main description also constrains what path should point to.

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 '读取结果文件元信息' and then enumerates exactly what is returned: 类型、条目名称/单位、时间轴、网格规模. This clearly distinguishes it from siblings mz_dfs_read and mz_dfs_plot by scoping it to metadata retrieval rather than data reading or plotting.

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 which file families are supported (.dfs0/.dfs1/.dfs2/.dfs3/.dfsu and .res1d/.res11), so suitable inputs are clear. However, it does not explicitly state when to prefer this over mz_dfs_read or mz_dfs_plot, nor any when-not conditions; the routing is only implied by the word 'info' and the file-type 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?

No annotations are provided, so the description carries the burden. It discloses the core side effect (creates a PNG file), the return value (image path), and default naming/location of the output. However, it does not mention overwrite behavior, error conditions, or whether the input file is left untouched, which would improve 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 main purpose is front-loaded in one sentence, followed by a compact, structured Args list. Every sentence provides useful information 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?

For a simple plotting tool with no output schema and no annotations, the description gives enough to invoke it correctly: required path, optional parameters with defaults, and return value. It could mention overwrite or failure behavior, but those are minor for basic usage.

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

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

Schema description coverage is 0%, but the description fully compensates by explaining all three parameters: path is an absolute result file path, item selects a named entry or index and defaults to the first item, and out_png defaults to a sibling of the result file. This adds real meaning beyond the bare 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 clear verb–resource pair: plot result sequences into a PNG image and return the image path. It also names supported input classes (dfs series and 1D results), which distinguishes it from sibling tools like mz_dfs_read or mz_dfs_info.

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

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

The intended use is clear from the description: whenever a result sequence needs to be visualized as a PNG. It states supported input types and default behaviors. It does not explicitly name alternatives or exclusions, but there is no competing plotting tool among the siblings, so clear context suffices.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states that data is auto-sampled to max_points to avoid context overflow, explains how 'item' works for 1D results with examples, and notes that omitting 'item' defaults to the first item. It does not cover error handling or exact return structure, but the key behaviors are 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 appropriately concise and front-loaded with the purpose. The Args section is somewhat verbose but each sentence adds necessary detail, especially the item handling example. The structure is logical: purpose, behavior, then parameter explanations. No waste, though it could be tightened slightly.

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 output schema and no annotations, the description is fairly complete. It covers all parameters, explains sampling behavior, and gives item examples. It does not describe the exact return format of statistics or series, nor error cases, but these are minor given the tool's scope and the absence of output schema. Overall, an agent can use this description effectively.

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 zero descriptions (0% coverage), so the description must fully explain parameters. It does: path is absolute path, item is explained with examples for both dfs and 1D cases, start/end are time strings with format example, and max_points is clearly the sampling limit. Every parameter is addressed with practical detail, going well beyond the schema's type/default information.

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 result data and returns statistics (max/min/mean) plus sampled series. The verb '读取' (read) is specific, and the resource is well-defined. It distinguishes itself from siblings like mz_dfs_info (metadata) and mz_dfs_plot (visualization) by focusing on actual data extraction.

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 what the tool does and how to use its parameters, but it provides no guidance on when to choose this tool over alternatives. It does not mention exclusions or conditions that would make another sibling more appropriate, such as when to use mz_dfs_plot instead for visualization or mz_dfs_info for metadata. The usage context is only implied by the tool's name and purpose.

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

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

No annotations are provided, so the description carries the burden. '列出' implies a read-only listing operation, and the mention of MzEngines.cfg adds useful source context, but side effects, error behavior, and output format are not disclosed.

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

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

The description is compact and well-structured, with the purpose front-loaded and parameter details presented in a clear Args block. 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 two-optional-parameter list tool, the core invocation details are present, but with no output schema and no annotations, the return shape and the exact effect of the year filter are left unspecified. 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 0%, and the description compensates by explaining both parameters: extension is optional and demonstrated with '.m21fm', and year is optional and scopes the MIKE Zero version. This adds real meaning beyond the bare 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 a specific verb ('列出' / list) and a concrete resource ('扩展名 -> 引擎 映射' from MzEngines.cfg). It clearly identifies what the tool does, though it does not explicitly contrast itself with any sibling tool.

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

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

There is no guidance about when to use this tool versus alternatives, nor any exclusions or prerequisites. The Args section explains parameters but not usage 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 carries the full burden of behavioral disclosure. It lists what is probed, implying a read-only diagnostic tool, but it never explicitly states that it is non-destructive, whether it requires special permissions, or what happens if no MIKE Zero installation is found. This is a significant gap because there are no other behavioral cues.

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 extremely concise: two sentences, with the purpose stated first and the argument explained second. Every word earns its place, and 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?

For a one-parameter probe tool with no output schema, the description covers the core purpose and the parameter semantics well. However, it does not describe the shape or format of the probe results (e.g., fields returned, error behavior), which an agent would need to interpret the output correctly. Given the lack of an output schema, this omission leaves the agent partially in the dark.

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

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

The schema only defines year as an optional string or null with default null, so the description adds crucial meaning: year selects a specific MIKE Zero version and omitting it defaults to the latest installation. It also provides an example value ('2023'), which is exactly the kind of compensation needed when schema description coverage is 0%.

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 action ('探测') on a defined resource ('本机 MIKE Zero 环境') and enumerates the exact aspects checked (installation location, bin/x64, headless entry, engine count, mikeio availability). This distinguishes it from many siblings, though it does not explicitly contrast with mz_engines, which likely overlaps on engine count.

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 mz_env versus alternatives like mz_engines or mz_scan. The description explains what the tool does but never provides a selection condition, exclusion, or reference to siblings, leaving the agent to infer the appropriate use case.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does mention that child processes are killed (taskkill /T) and that force defaults to true, but it does not warn about irreversibility, permissions, or side effects on other jobs. For a destructive operation, this leaves significant gaps.

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

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

The description is extremely concise: a one-sentence purpose statement followed a short parameter list. No filler or repetition. The purpose is front-loaded, and every sentence is informative. It earns its place entirely.

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 tool with 2 parameters and no output schema, the description is thin on context. It omits what happens after a successful kill, error handling, prerequisites (e.g., the job must exist or be running), and how to obtain job_id. It also doesn't reference siblings like mz_jobs for listing jobs, leaving agents to infer basic operational details.

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 'job_id' explanation ('作业 id') merely restates the schema title, adding no meaning. 'force' does add meaning (whether to force-terminate, default True), but this is minimal and does not fully substitute 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 clearly states a specific verb and resource: '终止一个作业' (terminate a job) with the extra detail that it kills child processes using taskkill /T. This distinguishes it from siblings like mz_job_status and mz_job_log, so an agent can select it 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?

Usage is implied by the action itself—'terminate a job'—but there are no explicit when-to-use/when-not-to-use conditions or named alternatives. An agent must infer that this is the tool for stopping jobs rather than checking status or logs, which is clear from the verb but not spelled out.

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

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

没有注释信息，描述承担了揭示行为的责任。它说明了读取范围（末尾若干行）、默认行数（200）以及日志位置（结果目录下的 .log），但未提及输出格式、可能的失败模式或读取是否安全。对于只读工具，这些信息部分足够，但仍不完整。

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?

描述简短精炼，先给出一句话功能概括，再列出参数说明，没有任何冗余。每一句都有实际价值，结构清晰，易于快速理解。

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?

工具结构简单（2 个参数、1 个必填），描述覆盖了核心行为、参数含义和默认值。虽然没有输出 schema，但“读取日志末尾若干行”已经暗示返回内容是日志文本，足够支持正确调用。缺失的部分主要是与兄弟工具的区分和异常行为说明。

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 没有任何参数描述（覆盖率为 0%），描述中为 job_id 和 lines 补充了含义：job_id 是作业 id，lines 是读取末尾行数并默认 200。这远超 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?

描述明确说明了工具功能：读取作业日志末尾若干行，并指出 MIKE Zero 将进度写入结果目录的 .log 文件。有清晰的动词和资源，但没有与其他兄弟工具（如 mz_progress、mz_job_status）做显式区分，因此未达到 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?

描述仅说明该工具读取日志尾部，未说明何时应使用 mz_job_log 而非 mz_progress 或 mz_job_status，也未提供替代工具或排除场景。缺少实际使用指导，只能从功能上推断用途。

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

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

No annotations are provided, so the description carries the full burden. It discloses that the tool lists recent jobs and that limit caps the count, but it does not mention ordering, whether the list is read-only, whether it includes running/completed/failed jobs, or any side effects. For a listing tool this is a moderate 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 short and front-loaded with the core purpose. The Args section is minimal but useful. It earns its place, though it could be slightly more structured with explicit notes on ordering or status filtering.

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 list tool with one optional parameter and no output schema, the description is mostly adequate. However, it lacks any mention of what fields are returned, how jobs are ordered, or whether the list includes all statuses. Given the sibling tools for job status/log/kill, an agent would benefit from knowing what 'recent jobs' means in terms of status and time window.

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 explain the only parameter, limit, with a default of 20, which matches the schema. However, it adds no detail about allowed range, semantics of 'recent', or how the limit interacts with pagination. Baseline 3 is appropriate because the single parameter is at least explained.

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 ('列出' = list) and resource ('最近的作业' = recent jobs), and clarifies the scope by enumerating job types (模拟/批量/工具箱). It is clear enough to distinguish from siblings like mz_job_status or mz_job_log, though it does not explicitly name a sibling 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?

The description implies usage: call this to list recent jobs, and the limit parameter controls how many are returned. It does not explicitly state when to use this versus mz_job_status, mz_job_log, or mz_progress, so the agent must infer the distinction from the job-type enumeration.

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

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

No annotations are provided, so the description carries the burden of explaining behavior. It does so by explicitly listing the status dimensions returned: process liveness, elapsed time, log file, error line, and new result files. It does not cover return format or error handling, but for a read-oriented status query the behavioral disclosure is reasonably complete.

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 well-structured: one sentence summarizes the query purpose and output facets, followed by an Args section defining the parameter. No filler or redundant information is present.

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

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

For a simple one-parameter status query with no annotations and no output schema, the description is mostly complete: it defines the parameter source and the kind of information returned. It could be more complete by describing the response format or expected error behavior, but the essential context for invoking 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 0%, so the description must compensate for the parameter's meaning. It does this well by explaining that job_id is the identifier returned by mz_run, mz_run_batch, or mz_toolbox, adding meaningful provenance beyond the schema's generic 'Job Id' string.

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 purpose: query job status and enumerates what it reports (process liveness, duration, log file, error line, new result files). It identifies the job_id as coming from mz_run/mz_run_batch/mz_toolbox, but it does not explicitly distinguish itself from closely related siblings like mz_progress, mz_jobs, or mz_job_log.

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 used with a job id returned by mz_run, mz_run_batch, or mz_toolbox. This implies the tool is meant to be called after launching a job, but it does not explicitly state when to prefer this over alternatives such as mz_progress or mz_job_log.

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 that data is sourced from an engine-written `<setup名>._spi_` file, with the example `PROGRE 1000` meaning completion, and that it reads an archived copy if MzLaunch deleted the original. This explains the tool's internal fallback behavior. It could add failure handling or latency notes, but for a read-only progress tool the disclosure is above average.

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: a one-line purpose, a concise data-source note, a fallback sentence, and the Args line. Every sentence serves a purpose and there is no filler. The most important information is front-loaded in the first line, and the parameter note is clearly separated.

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, no-output-schema tool, the description covers purpose, data source, fallback behavior, and parameter origin. It does not specify the exact response structure or error scenarios, and the absence of an output schema could merit more detail on the return format, but the listed metrics partially compensate. Overall it is nearly complete for the task of retrieving progress.

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 0%, but the description explicitly documents job_id as "mz_run 返回的作业 id" (the job id returned by mz_run). This adds meaningful provenance beyond the bare schema property, telling the agent exactly where the value comes from. It doesn't give format examples, but for a single simple string parameter this is sufficient.

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 opens with a specific verb and resource: "读某个作业的实时进度" (read a job's real-time progress), then enumerates the exact metrics returned (percentage, current simulation time, steps, speed, remaining time). This is clearly distinct from sibling tools like mz_job_status or mz_job_log, making the purpose unambiguous without needing to reference 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 clear context: it reads progress data written by the engine to a `_spi_` file, and falls back to an archived copy if the original was deleted by MzLaunch. It also states that job_id comes from mz_run, which tells the agent when this tool is relevant. However, it does not explicitly name alternatives or explain when not to use it, so it misses the top bar for exclusion 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 full burden of behavioral disclosure. It states the tool 'parses' and 'returns' data, implying a read-only operation, but does not explicitly confirm no side effects, nor does it mention potential errors, file existence requirements, or output format. The level of transparency is minimal but not misleading.

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 extremely concise—two sentences total—with the purpose front-loaded and parameter details following. Every word contributes, and the format (description followed by Args) is clean and scannable.

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

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

The tool has no output schema, so the description should clarify return structure. It lists what is returned (engine, sections, file references, key parameters) but does not specify the format (e.g., dict, list) or error behavior. Given the tool's simplicity, this is a minor gap, but for an agent invoking it, knowing the return shape 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 description explains both parameters meaningfully: setup is an absolute path with concrete examples, and year is an optional MIKE Zero version selector. This adds value beyond the bare schema types, which only define string/null. Given 0% schema coverage, the description effectively compensates, though it could be more explicit about year's effect.

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 parses MIKE Zero setup files in PFS format and enumerates the extracted content (engine, sections, file references, key parameters). This distinguishes it from sibling tools like mz_dfs_read which read data files, and mz_scan which likely scans projects. The verb 'parse' and resource 'setup file' are specific.

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 for reading setup files by providing file extension examples (.m21fm, .sim11, etc.) but does not explicitly state when to use this tool versus alternatives like mz_dfs_read or mz_scan. There is no mention of exclusion criteria or alternative selection, leaving some inference required.

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

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

With no annotations, the description carries full behavioral burden, and it does so thoroughly: it discloses background execution, return of a job id, the side effect that MzLaunch deletes `._spi_` progress files (archived first), direct-mode preservation of those files, unsupported flags in direct mode, and wait/timeout behavior. This materially exceeds what the schema alone provides.

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 long but structured: a one-line purpose, a short tracking pointer, a compact two-mode comparison, and then a clean bullet-style Args list. Every sentence adds operational value, and the most decision-critical 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?

For a 14-parameter, side-effect-heavy launch tool with no annotations and no output schema, this description is unusually complete. It covers what is returned, background behavior, progress tracking, mode-specific differences, version caveat, parameter effects, and wait/timeout semantics. An agent has enough to call the tool correctly in most real scenarios.

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, and it does: every one of the 14 parameters is given meaningful semantics, including defaults, exact CLI flags they map to, and conditional effects (e.g., direct mode disables -mpi/-gpu/-z). This is far beyond raw schema 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 opens with a precise statement: '无界面启动一次 MIKE Zero 模拟，返回作业 id' – a specific verb, resource, and observable result. It also orients the agent relative to sibling tracking tools by naming mz_progress / mz_job_status / mz_job_log for follow-up, which helps 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 clearly explains the default background execution model and when to use the progress/job-status tools, and it gives detailed guidance on choosing direct=False vs direct=True. It does not explicitly contrast with mz_run_batch or say 'do not use this when...', so it falls just short of fully explicit 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?

The description discloses key behavioral traits: it generates .bat files, runs them in the background, and leaves the .bat files in the workdir for inspection or manual re-run. It also explains the wait parameter controls synchronous waiting and timeout applies when wait=True. No annotations are provided, so the description carries the burden, and it does a good job.

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 with the core behavior (batch sequential execution, .bat generation, background running). The Args section is structured and readable. It could be slightly more concise, but every sentence earns its place.

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

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

For a tool with 11 parameters, no annotations, and no output schema, the description covers the essential behavioral context: what it does, where artifacts go, how wait/timeout work, and how to interpret the shared parameters. It doesn't describe return values or error behavior, but the core invocation context is complete enough for an agent to use 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 setups (absolute paths, executed in order), workdir (defaults to first setup's directory), wait (whether to synchronously wait for the whole batch), timeout (waiting limit in seconds when wait=True), and defers engine/engine_flag/mpi/gpu/priority/extra_args to mz_run. This covers most parameters meaningfully, though year is only mentioned as 'optional, specify MIKE Zero year' without deeper detail.

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 purpose: batch sequential execution of multiple setups, generating .bat files (DHI official approach) and running them in the background. It distinguishes itself from mz_run by explicitly mentioning batch execution of multiple setups and the .bat generation behavior.

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

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

The description explains when to use this tool (for batch sequential execution of multiple setups) and references mz_run for parameter semantics. It doesn't explicitly state when NOT to use it or name alternatives, but the batch context is clear enough for an agent to differentiate from the single-run sibling mz_run.

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 transparency burden. It discloses useful behavioral constraints: max_files caps how many files are scanned and year determines setup-extension matching. However, it does not clarify whether the scan is recursive, what the output/return structure looks like, or whether the operation is strictly read-only.

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, front-loaded with the core purpose, and uses a clean Args block for parameter details. Every sentence or line adds information without redundancy.

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

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

The description covers the tool's purpose and all parameter semantics, which is enough to invoke it with just root. But with no output schema and no annotations, it should say more about the return format, whether scanning is recursive, and what '按类型归类' produces in practice.

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 fully compensates. It explains root as an absolute path, max_files as a scan limit with a default of 5000, and year as an optional selector that determines MIKE Zero setup extensions. These semantics go well beyond the bare schema types.

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 action ('扫描一个工程目录') and a concrete result ('按类型归类 MIKE Zero 的 setup 文件与结果文件'). It is distinct from mz_read_setup/mz_dfs_read, though it does not explicitly name or differentiate from 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?

Usage is implied: this is the tool to use when you want to scan a project directory and classify MIKE Zero files. However, it gives no explicit when-to-use/when-not-to-use guidance and never mentions alternatives like mz_read_setup or mz_dfs_info.

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

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

No annotations are provided, so the description carries the full burden of disclosing behavior. It does reveal that the tool runs via ToolboxShell.exe in non-GUI modeaine, and the wait/timeout parameters imply synchronous vs asynchronous execution. However, it does not disclose what the tool outputs or returns (e.g., exit code, job ID), what side effects occur (e.g., generated files), or whether errors are surfaced. This is only partial 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 highly efficient: one sentence establishes the purpose and supported file types, followed by a clean bullet list of all parameters. Everything is front-loaded, and there is no redundant or filler text. It earns its keep with every word.

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 external-process-execution tool with no output schema, an agent would need to know what the invocation returns, how to interpret failures, and how this relates to sibling tools like mz_jobs or mz_progress. The description explains inputs and execution flags but is silent on return values, logging, and post-run behavior. Given the tool's complexity, this is a notable gap.

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

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

Schema description coverage is 0%, so the description must compensate. The 'Args' section defines each of the five parameters: setup as an absolute path, extra_args as appended arguments, year as an optional MIKE Zero year, wait as whether to synchronously wait, and timeout as the wait limit when wait=True. This adds meaning beyond the raw schema. extra_args is somewhat vague, but overall the parameter semantics are clearly communicated.

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 states that the tool runs a Toolbox setup headlessly using ToolboxShell.exeaine, listing the supported file extensions (.mzt / .21t / .3t / .lpkt / .mst). The verb '运行' (run) plus the specific resource 'Toolbox setup' clearly differentiates it from sibling tools such as mz_run (likely for engine simulation) or mz_read_setup (reading setups). This is a distinct, unambiguous 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?

The description provides no explicit guidance on when to choose this tool over its siblings. It states that it runs setup files without a GUI, but never mentions alternatives like mz_run or mz_read_setup, nor does it say 'use this tool for .mzt setups and that tool for engine runs'. The only implicit hint is the file extension list, which is not sufficient for an agent to make an informed selection.

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