Skip to main content
Glama

obj_highlight_net

Highlights a named net in the focused schematic or PCB document, clearing old highlights by default and optionally forcing schematic or PCB context for accurate visual net tracing.

Instructions

Highlight a net by name in the focused schematic or PCB document.

PCB path sets IPCB_Net.IsHighlighted on the matched net (the documented property). Schematic path walks net labels / power ports / ports / sheet entries on the active sheet and marks those whose name matches as Selection=True, the closest thing Altium exposes to a "highlight" on schematic without interactive commands.

If a schematic is the focused document, this paints the schematic even when a PcbDoc is also open. Pass context="pcb" or context="schematic" to force one side. The previous behaviour always preferred the PCB whenever any board was loaded, which made a schematic Find-Net look like it did nothing.

Args: net_name: Exact net name to highlight (e.g., "VCC", "GND", "NET_D0"). Returns NOT_FOUND if the net doesn't exist on the PCB, or highlighted=0 on schematic if no primitive carries that net name on the active sheet (check other sheets). clear_existing: Clear existing highlights first (default True). context: Empty (default, follow the focused document), "schematic", or "pcb".

Returns: Dict with success, net, context ("pcb" or "schematic"), and highlighted (count of matches, 1 for PCB, N for sch).

Input Schema

NameRequiredDescriptionDefault
contextNo
net_nameYes
clear_existingNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.6.1

TDQS

A4.7/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 burden and does so well: it states the exact PCB property set (IPCB_Net.IsHighlighted), the schematic fallback behavior of marking Selection=True on matching labels/ports/sheet entries, and the limitation that schematic matching only covers the active sheet. It also discloses the previous bug-like behavior and the new context override.

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?

The description is front-loaded with the core action and then structured into behavior, Args, and Returns. It is somewhat verbose for a three-parameter tool, but the detail is relevant and mostly earns its place.

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?

Given no annotations, an output schema, and a dual-context operation, the description provides everything needed: selection behavior, return values, context forcing, matching limitations, and failure signals. An agent can invoke it correctly without additional context.

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%, so the description must explain the parameters, and it does: net_name is exact and returns NOT_FOUND if absent, clear_existing defaults to true, and context accepts empty, "schematic", or "pcb" with clear semantics. This fully compensates for the schema gap.

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 description opens with a precise verb and resource: highlight a net by name in the focused schematic or PCB document. It clearly scopes behavior across the two document types and explains the context selection, letting an agent distinguish this from clearing or selecting objects.

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 clearly explains the default context behavior, how to force PCB or schematic with context="pcb"/"schematic", and why the previous PCB-preferring behavior was problematic. It does not explicitly compare against sibling tools such as obj_clear_highlights, though clear_existing covers the clearing use case.

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