Detect MIKE Zero installation details, including engine count, headless entry points, and mikeio availability. Specify a year to check a specific version, or default to the latest installed.
探测本机 MIKE Zero 环境：安装位置、bin/x64、无界面入口、引擎数量、mikeio 可用性。
Args: year: 可选，指定 MIKE Zero 年份（如 "2023"）；不传则取最新安装。
| Name | Required | Description | Default |
|---|---|---|---|
| year | No |
Changes observed during successful MCP inspections.
v1.0.1Does 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.