eda-agent

Overview Schema Source Related Servers Discussions Admin

pcb_run_drc

Run a Design Rule Check on the active PCB only when a human is available to dismiss Altium's modal dialog; otherwise read stored clearance violations to avoid blocking the bridge.

Instructions

Run Design Rule Check (DRC) on the active PCB. MODAL -- BLOCKS THE BRIDGE. Opt in with allow_modal=True.

DANGER: Altium has no non-interactive DRC trigger exposed to DelphiScript. PCB:DesignRuleCheck raises the MODAL "Design Rule Checker [mil]" setup dialog and the worker sits behind it until a HUMAN clicks Cancel/OK. Nothing else on the bridge runs meanwhile: one observed call left the loop dead for 30+ min, the client timed out at 1800 s, and every in-flight job was stranded. No parameter suppresses the dialog, so this tool refuses to fire unless the caller passes allow_modal=True, which is a promise that a human is at the keyboard.

PREFER pcb_get_clearance_violations -- it reads the violations already stored on the board, runs no DRC, and cannot block.

PATHOLOGICAL CASE: a full DRC on a placed-but-unrouted board (many components, zero tracks, everything unrouted) checks every pad pair against every rule and is enormously slow for an answer that is already known -- "nothing is routed yet". Check pcb_get_board_statistics / pcb_get_unrouted_nets first; if track count is 0, do not run DRC.

With allow_modal=True it executes the DRC and returns up to 100 violations with full location data, so the agent can jump straight to the offending spot instead of guessing from the description.

drc_confirmed is true only when Altium rewrote the .DRC report during this call. A cancelled dialog leaves the old report untouched, so its count, 0 included, belongs to an earlier run. It also stays false when the checker's Create Report File option is off.

Per-violation shape:

name, description, rule: text from Altium
x_mils / y_mils / layer: violation's bbox centre (the "go here" hint)
primitive1 / primitive2: objects with {detail, type, net, layer, x_mils, y_mils}. type is the object kind (Track / Pad / Via / Region / Comp); net is the net name. Two primitives are involved in most rule kinds (Clearance, Short Circuit); a single- primitive violation (e.g. AcuteAngle) leaves primitive2 with empty fields.

Use primitive1.net and primitive2.net to spot the nets in conflict; use x_mils / y_mils to drive proj_cross_probe or the dashboard's Drawing tab to the site.

Args: allow_modal: Must be True to actually run DRC, and it means "I accept that the bridge blocks on a modal dialog until a human clicks it". Default False refuses without touching Altium.

Returns: Dict with violation_count (full count even if > 100), drc_triggered, and violations array (first 100). With allow_modal=False: {ok: False, reason: ...} and no bridge call at all.

Input Schema

Name	Required	Description	Default
`allow_modal`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.6.1Oct 29, 2026

TDQS

A4.9/5.0

Behavior5/5

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

No annotations exist, so the description carries the full burden and does so exceptionally: it discloses that the call blocks the entire bridge on a modal dialog, cites an observed 30+ minute hang and a 1800 s client timeout with stranded jobs, and explains that no parameter can suppress the dialog. It also clarifies the subtle semantics of drc_confirmed (only true if Altium rewrote the .DRC report this call; false when cancelled or when Create Report File is off).

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

Conciseness4/5

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

Front-loaded with the highest-risk fact ("MODAL -- BLOCKS THE BRIDGE") and organized with named sections and bullets, so the length is largely earned by the danger it prevents. However, the lengthy per-violation field breakdown duplicates what the existing output schema already documents, and the Args/Returns sections restate points made earlier in prose.

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

Completeness5/5

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

For a single-parameter tool with no annotations, the description supplies the safety profile, the alternative route, the pre-flight checks, the failure mode, and the success/cancel semantics of the returned flag. An agent has everything needed to decide whether to call it and how to interpret the result.

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

Parameters5/5

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

Schema description coverage is 0% and the single parameter has only a bare title, so the description must compensate — and it does, defining allow_modal as a promise that a human is present and stating that the default False refuses without touching Altium at all. This is far more meaning than the schema provides.

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

Purpose5/5

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

Opens with a specific verb and resource ("Run Design Rule Check (DRC) on the active PCB") and immediately names the preferred alternative (pcb_get_clearance_violations) and the blocking behavior. An agent can distinguish this from run_drc, design_validate, and pcb_get_clearance_violations without opening any schema.

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

Usage Guidelines5/5

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

Gives explicit when-not guidance ("PREFER pcb_get_clearance_violations -- it reads the violations already stored on the board"), a precondition for use (allow_modal=True means a human is at the keyboard), and a concrete pathological case to check first (track count 0 via pcb_get_board_statistics / pcb_get_unrouted_nets). Nothing is left to inference.

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

Deploy Server