Skip to main content
Glama

audit_find_orphan_net_labels

Detect schematic net labels placed off any wire or bus to catch orphan labels that create phantom nets before fabrication.

Instructions

Find schematic net labels whose location is NOT on any wire or bus.

In Altium, a net label labels whichever wire passes through its (x, y). If the label sits in empty space (because the wire was moved during a layout pass, or was never placed), the compile produces a phantom net -- the label looks correct on paper but the signal it "names" connects to nothing under the label. ERC sometimes catches this (no driver / no load) but not always -- the other end of the same-named net often provides a load, so the violation never fires.

Spatial-iterates a 1-mil square at each net label's location for any eWire / eBus object. Absence → orphan.

Pattern: SDK-derived. No community-script reference; surfaced by reviewing the ISch_NetLabel interface in the Altium Schematic API docs.

Returns: Dict with {checked, violations, items[]} where each item carries {label, sheet, x_mils, y_mils} for an orphan net label.

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 at all, the description carries the full burden and does so well: it discloses the detection mechanism (1-mil spatial probe at each label's coordinates for eWire/eBus objects) and the absence criterion. It never explicitly states the operation is read-only, though 'audit/find' plus the probing description strongly imply it.

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 core explanation is front-loaded and useful, but the 'Pattern: SDK-derived. No community-script reference...' paragraph is meta-commentary about provenance that gives the agent nothing actionable, and the 'Returns' block restates the output schema. Both could be cut without loss.

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?

Output schema exists and the description redundantly but harmlessly restates it. Given zero parameters and no annotations, the definition supplies everything needed to decide to call it: what it finds, why it matters, how it detects, and what comes back.

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 and the schema is empty, so there is nothing for the description to disambiguate. Baseline 4 applies; the description correctly describes a whole-design scan with no scoping inputs.

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: 'Find schematic net labels whose location is NOT on any wire or bus.' The Altium-specific explanation of what a net label attaches to makes the failure mode unambiguous and distinguishes it from generic ERC or net-label-conflict checks.

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?

Explicitly frames when ERC will and will not catch this condition ('the other end of the same-named net often provides a load, so the violation never fires'), which is effectively a when-to-use rationale versus proj_run_erc / audit_find_net_label_conflicts. It stops short of naming those sibling tools outright, so it is strong but not a full routing statement.

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