Skip to main content
Glama
IntelligentElectron

Universal Netlist MCP Server

Trace XNET from a net

query_xnet_by_net_name
Read-onlyIdempotent

Retrieves full extended-net connectivity for a named net by tracing through series components to return the complete electrical node, with optional component-type exclusions.

Instructions

Get full XNET (Extended Net) connectivity for a net. Traces through series components, so the result is the whole electrical node rather than the one net; circuit_hash identifies unique topologies. Traversal stops at power and ground nets, recognised by name (VCC*, VDD*, 3V3, GND*, VSS*, ...) or by carrying more than 40 pins. A rail named outside that, such as VDIO_LMS, is traversed like a signal, so a query that pulls up to one returns its whole pull-up network; visited_nets names every net the result crossed. skip_types leaves series passives out; skip_types=['C','L','R'] removes all three from the result. Rejects ground nets (GND, AGND, DGND, etc.) with an error. A name that matches no net exactly is matched ignoring leading and trailing whitespace, then as the 31-character name a PSTWRITER 16.6 Allegro export gives a longer net; notes says when that happened, and a name that could mean several nets returns them. component_notes names the parts with no MPN. If the net is not found, search_nets finds the name.

Input Schema

NameRequiredDescriptionDefault
designYesPath to design file
net_nameYesNet name. An exact match wins; otherwise it is matched ignoring leading and trailing whitespace, and for Cadence as a 31-character PSTWRITER 16.6 name
skip_typesNoComponent prefixes to exclude (e.g., ['C', 'L'])
include_dnsNoInclude DNS components
design_variantNoDesign variant name from list_designs' design_variants. Required when the design records named variants, which are its only builds. <Default> (alias: default) is the one build of a design that records none

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.0.0-development

TDQS

A4.6/5.0
Behavior5/5

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

Even with readOnly/idempotent annotations already covering safety, the description adds substantial behavioral context: traversal through series passives, stopping at power/ground nets by name or pin count, handling of non-standard rails like VDIO_LMS, skip_types effects, ground-net rejection, whitespace/31-character name matching, notes, and component_notes. This is exactly the kind of execution behavior an agent needs beyond the annotations.

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 purpose and then packs in relevant edge cases. It is dense and longer than typical, but nearly every sentence provides operational value for a complex trace tool; minor structural improvement could come from separating traversal and naming rules, but it is not wasteful.

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?

Although there is no output schema, the description names returned concepts such as circuit_hash, visited_nets, notes, and component_notes, and explains major error and edge-case behavior. For a complex 5-parameter trace tool with annotations covering safety, this is complete enough for an agent to invoke correctly.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds meaningful semantics beyond the schema: it explains net_name matching fallback behavior and the effect of skip_types (e.g. ['C','L','R'] removes all three series passives). It does not explain include_dns or design_variant beyond the schema, but the added parameter context is substantial.

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 states a specific verb and resource: get full XNET connectivity for a named net, tracing through series components to return the whole electrical node. It clearly distinguishes the result from a plain net query by explaining circuit_hash and the traversal scope, so an agent can identify this as the XNET-by-net tool rather than a generic net listing/search.

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 gives clear usage context: use it for full XNET connectivity, it rejects ground nets, and if the net is not found use search_nets. It does not explicitly compare against the sibling query_xnet_by_pin_name, but the 'by net name' scope and the search_nets fallback provide strong guidance for when to invoke it.

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