Skip to main content
Glama

proj_get_erc_violations

Retrieve electrical rule check violations from the last ERC run without recompiling. Returns each violation with its related pin, net, or port objects and cross-probe data for locating the exact offender.

Instructions

Return the ERC violation list produced by the last proj_run_erc() invocation.

Two-step pattern by design: proj_run_erc() performs the compile-and-check (slow, can be 30+ s on a large project); this tool reads back the violations cheaply so the agent can re-query without re-running ERC.

Each violation names the OBJECTS it is about, not just a category. related_objects carries one entry per offending object with its kind (Pin, Net, Port), its document, and a cross_probe string, which is what Altium itself uses to jump to that exact object and is therefore what identifies the specific pin or net.

That detail is the difference between a report and something actionable. A category plus a sheet name cannot be acted on: the only safe response to "floating input pin, somewhere on this sheet" is to do nothing, because a NoERC marker placed by guesswork silently suppresses a real disconnection and is worse than the warning it clears.

related_object_count is reported separately, so a violation that genuinely exposes no objects is distinguishable from one whose objects could not be read.

Returns: {"violation_count", "violations": [{"index", "description", "detail", "related_object_count", "related_objects": [{"kind", "document", "cross_probe"}]}]}

Input Schema

NameRequiredDescriptionDefault

No arguments

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.6.1

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses the cost asymmetry (run is 30+ s, this read is cheap), the dependency on a prior invocation, and the exact meaning of related_object_count as a signal that objects were unreadable rather than absent. The missing piece is the no-prior-run case, which is a meaningful behavioral gap for a read-back tool.

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

Conciseness3/5

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

The purpose and the two-step rationale are correctly front-loaded, but the middle section editorializes — 'the difference between a report and something actionable' and the NoERC-by-guesswork anecdote — without adding call-relevant facts. Roughly a third of the text could be cut with no loss of agent guidance.

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

Completeness4/5

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

An output schema exists, so the Returns block is redundant but harmless, and the dependency on a prior proj_run_erc call is well covered. The definition is complete enough to invoke correctly except for the missing note on preconditions and result staleness.

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

Parameters4/5

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

The tool takes zero parameters, so there is nothing to document and the baseline of 4 applies. The description instead spends its space on output semantics, which is the correct choice.

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?

The first sentence names a specific verb and resource and pins the data source: the ERC violation list from the last proj_run_erc() invocation. That immediately separates it from the sibling proj_run_erc (which performs the check) and from pcb_get_clearance_violations (a different domain).

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

Usage Guidelines4/5

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

It explicitly frames the two-step pattern and tells the agent to call this instead of re-running ERC to re-query — a clear when-to-use signal with the alternative named. It stops short of stating the precondition failure mode (what happens if proj_run_erc was never run) or whether stale results can be detected.

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

Deploy Server

Other Tools