Verify PCB design rule compliance by running a DRC check. Returns true if the design passes, with optional strict mode and UI feedback.
pcb_Drc.check(strict: boolean, userInterface: boolean, includeVerboseError: false) -> Promise 检查 DRC returns: DRC 检查是否通过
| Name | Required | Description | Default |
|---|---|---|---|
| args | No | 按官方签名顺序排列的JSON参数数组 | |
| windowId | No | 目标EDA窗口ID；省略时使用当前活动窗口 |
Changes observed during successful MCP inspections.
v2.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose side effects, such as whether it modifies the board, opens a UI (though the userInterface parameter suggests it might), or requires permissions. It only states the return type. For a check operation, it likely has no destructive side effects, but this is not 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?
The description is extremely short, containing only the signature and a two-word purpose. It is concise and wastes no words, but it is also minimal. It does include the return type, which is useful.
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 no annotations and no output schema, the description is incomplete. It does not explain the meaning of the parameters, potential side effects (like opening a UI), or how to interpret the boolean result beyond 'pass/fail'. It also does not mention any requirements like an open PCB document.
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 describes the top-level arguments array and windowId, but not the meaning of the parameters within the args array. The description provides the signature (strict, userInterface, includeVerboseError) but does not explain what these parameters do or their expected formats. Schema coverage is 100% for the two properties, but the description adds only the parameter names, not semantics.
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 '检查 DRC' (check DRC) and provides the function signature, making it clear this tool performs a design rule check on the PCB. It is distinguished from the schematic DRC check (eda_sch_drc_check) by the pcb prefix, and from other pcb_drc tools that query or modify rules. However, it lacks elaboration on what the check entails, so it is clear but minimal.
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 provided on when to use this tool versus alternatives such as eda_pcb_drc_get_real_time_drc_status or starting real-time DRC. It does not mention prerequisites like having a board open or whether it should be used before manufacturing. The description only states what it does, not when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.