仿真波形绘图 (VCD→SVG/HTML 图像)

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

With no annotations, the description carries the full behavioral burden. It discloses that the tool writes .wave.svg and .wave.html files, returns paths, optionally embeds a full SVG via inlineSvg, and can open a browser with open:true. It also notes truncation behavior for maxSignals. Minor gaps remain, such as overwrite behavior, but the disclosed side effects are substantial.

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

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

Four dense sentences cover purpose, outputs, two boolean behaviors, parameter control, and the sibling alternative, all without redundant filler. The core function is front-loaded, and every clause contributes actionable 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?

Given six parameters and no output schema, the description explains the key return artifacts and option behaviors well. It covers all major invocation decisions and the interactive fallback. It stops short of perfect completeness by not describing failure modes or exact return path structure, but it is strong for this complexity level.

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 adds value beyond the schema by clarifying defaults and behavioral effects: inlineSvg default true returns an embeddable SVG, open launches the browser, signals selects signals, and maxSignals defaults to 40 with truncation.

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: '把 VCD...渲染成数字时序图' and names the concrete output artifacts (.wave.svg + .wave.html). It also distinguishes itself from the interactive sibling fpga_msim_view by framing itself as the static rendering path.

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

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

The description explicitly tells the agent when to use this tool vs. the alternative: '需要交互式深查/缩放用 fpga_msim_view 打开 ModelSim GUI'. It also identifies valid input sources (fpga_sim/iverilog or fpga_msim_sim/ModelSim artifacts.vcd), giving clear context for invocation.

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