Verilog 仿真 (iverilog+vvp)

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

No annotations are present, so the description and parameter schema carry the full burden. They disclose the core workflow (compile + run, return logs, ok verdict), default source selection excluding ._fpga_* files, log truncation behavior via the detail parameter, VCD generation, waveform rendering, and optional browser opening. This is more than a bare description, though it could still mention file side-effects or exact return shape.

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 description is a single concise sentence that front-loads the toolchain and essential action, with the optional VCD behavior attached without extra fluff. Every word carries meaning; no redundancy beyond an acceptable restatement of the title.

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 10-parameter tool with no output schema and no annotations, the definition covers the essential invocation surface: required workdir/top, source selection, VCD options, wave rendering artifacts, timeout, and log granularity. It explains return essentials (logs + ok) and the main artifacts, sufficient for an agent to invoke and interpret results, although a more explicit return structure would push it to 5.

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

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

Schema description coverage is 100%, so the baseline is 3. The main description adds only a general note about optional VCD wrapper injection, which loosely maps to vcd/vcdPath, but it does not meaningfully go beyond the already detailed parameter descriptions for wave, detail, sources, etc.

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

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

States a specific verb and resource: uses iverilog to compile and vvp to run a Verilog/SystemVerilog design with testbench, returning logs and an ok determination. The title's 'iverilog+vvp' and the description's optional VCD injection clearly distinguish it from ModelSim-based siblings like fpga_msim_sim.

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 identifies the toolchain (iverilog/vvp) and the optional VCD injection, giving an agent clear context about what this tool is for. However, it never explicitly states when to prefer this over fpga_msim_sim or other simulation tools; the only alternative mentioned is fpga_wave, and that appears only indirectly in the wave parameter description ('免再调 fpga_wave'), not as main usage guidance.

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