eda-agent

Overview Schema Source Related Servers Discussions Admin

audit_find_net_label_conflicts

Detect net labels that conflict at the same point, sit inert on pin roots, or duplicate, and get coordinates to correct silent shorts or floating pins before fabrication.

Instructions

Find net labels that silently merge, short, or do nothing.

Three failure modes that all look correct on a printed sheet:

conflicting_labels -- two labels with DIFFERENT text at the same Location (x, y), not merely overlapping text boxes. Altium merges both names into one net and one name wins; the losing net ceases to exist and everything on it is absorbed. This is a real short between two named nets, and the usual symptom is "net X has zero pins" while some unrelated pin turns up on net Y. Adjacent labels on a 100-mil pin pitch are not conflicts.
labels_on_pin_root -- a label sitting on a pin's Location instead of its electrical end. Location is the BODY-side root; a pin connects at Location + PinLength along Orientation (0=right, 1=up, 2=left, 3=down). A label on the root is inert, so the sheet reads as fully wired while the pin floats on an auto-generated net. Each item reports the label's coordinates AND the connect_x_mils / connect_y_mils the label should move to.
duplicate_labels -- same text twice at one point. Harmless electrically, but it is clutter and it hides class 1 underneath.

Complements audit_find_orphan_net_labels, which only asks whether a wire sits under the label and therefore reports genuinely-connected labels (those on a pin end, with no wire) as orphans.

Returns: Dict with {checked, conflicts, on_pin_root, duplicates, conflicting_labels[], labels_on_pin_root[], duplicate_labels[]}.

Input Schema

Name	Required	Description	Default
No arguments

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.6.1Oct 29, 2026

TDQS

A4.4/5.0

Behavior4/5

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

No annotations are provided, so the description carries the full burden and does so well: it explains the electrical consequence of each mode (losing net ceases to exist, pin floats on auto-generated net), the pin geometry rule for class 2, and reports remediation coordinates. It never states read-only/no-side-effect semantics explicitly, which is the main gap for an unannotated tool.

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 one-line thesis, then a numbered taxonomy, then the sibling contrast — a genuinely useful structure. The closing 'Returns' block largely restates the output schema, which is the one portion that does not fully earn its space.

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 zero-parameter, read-only audit with an output schema already present, the description covers everything an agent needs: what each result class means, what triggers it, what is a false positive, and which sibling to use instead. Return values are additionally summarized, so nothing material is missing.

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?

Zero input parameters, so the baseline of 4 applies. The description correctly implies a whole-document audit with no scoping arguments, and adds meaning where it can by explaining the returned coordinate fields (connect_x_mils / connect_y_mils) that an agent would need to act on.

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?

Specific verb + resource (find net labels that merge/short/do nothing) with an enumerated taxonomy of the three failure classes. It explicitly names and distinguishes itself from the closest sibling, audit_find_orphan_net_labels, so an agent can route between them without opening schemas.

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?

The description frames the tool's scope ('on a printed sheet' symptoms, three failure modes) and gives an explicit exclusion rule for class 1 ('Adjacent labels on a 100-mil pin pitch are not conflicts'). The final paragraph routes the agent away from the sibling tool, which is a clear use-vs-alternative statement; it stops short of prescribing when in a workflow to run it.

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

Deploy Server