eda-agent

Overview Schema Source Related Servers Discussions Admin

pcb_get_clearance_violations

Read existing PCB clearance violations already stored on the board, optionally filtered by net, without triggering a DRC run.

Instructions

Read the violations ALREADY on the board, optionally filtered to one net. Does NOT run DRC.

This is a pure board read: it walks the eViolationObject records the last DRC run (batch or online) left behind. It opens no dialog and cannot block the bridge. Use it as the default way to inspect violations.

It used to trigger PCB:DesignRuleCheck first, which raises Altium's MODAL "Design Rule Checker" setup dialog: on a 241-component board that wedged the whole bridge for 30+ min until the client timed out. A "get" tool must not do that, so the trigger is gone. pcb_run_drc(allow_modal=True) is now the only way to force a fresh run.

CAVEAT -- violation_count: 0 means "no violations are stored on this board", NOT "the board passes". If DRC has never been run in this Altium session, there is nothing to read and the answer is 0 either way. The response carries drc_triggered: false and a note saying so. To get fresh data, run DRC from Altium's UI (Tools > Design Rule Check) or call pcb_run_drc(allow_modal=True) and be ready to click the dialog.

Filter is substring-matched against the violation's Description and Name, so it catches both "Net USB_DP and Net GND" clearance warnings and net-named via antennas.

Each violation carries x_mils / y_mils / layer for the agent to navigate to, plus primitive1 / primitive2 objects with {detail, type, net, layer, x_mils, y_mils}.

Args: net: Net name to filter by (substring match). Empty string returns ALL stored violations. offset: How many matching violations to skip, for paging. limit: How many to return, 200 by default.

Returns: Dict with {violation_count, offset, limit, returned, has_more, drc_triggered, note, violations}. violation_count is every violation that matched; when has_more is true, call again with offset raised by returned.

Input Schema

Name	Required	Description	Default
`net`	No
`limit`	No
`offset`	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?

With no annotations the description carries the full load, and it delivers: pure board read over eViolationObject records, no dialog, cannot block the bridge, historical 30-minute bridge wedge, and the key caveat that violation_count:0 means 'nothing stored', not 'board passes'. It even discloses the drc_triggered:false and note fields in the response.

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 core purpose and the 'does not run DRC' constraint, and most sentences earn their place. The multi-sentence retelling of the historical 241-component bridge wedge is slightly overlong for what it justifies, though it does explain why the behavior exists.

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 read tool with no annotations and a 0%-documented schema, this is complete: paging protocol (raise offset by returned when has_more), the semantics of a zero count, per-violation fields (x_mils/y_mils/layer, primitive1/primitive2 shape), and the fallback path for fresh data. Nothing an agent needs to call and interpret it correctly is missing.

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 coverage is 0%, and the description compensates fully: net is substring-matched against Description and Name (with concrete examples of what it catches), empty string returns all, offset is a paging skip, limit defaults to 200. None of this is recoverable from the bare schema.

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+resource+scope: 'Read the violations ALREADY on the board, optionally filtered to one net. Does NOT run DRC.' That negative clause cleanly distinguishes it from pcb_run_drc, so an agent can pick correctly without consulting either 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?

Explicitly states 'Use it as the default way to inspect violations' and routes the alternative ('pcb_run_drc(allow_modal=True) is now the only way to force a fresh run'). It also warns that fresh data may require Altium's UI or the modal path, giving both when-to-use and when-not-to-use guidance.

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

Deploy Server