Skip to main content
Glama
Sign In
IntelligentElectron

Universal Netlist MCP Server

by IntelligentElectron
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Run electrical rule checks

run_erc
Read-onlyIdempotent

Run electrical rule checks on a design's netlist and return complete findings grouped by severity and rule to flag connectivity and naming issues.

Instructions

Run electrical rule checks (ERC) on a design's netlist and return findings grouped by severity (errors, warnings) then rule id. Full output, never truncated. Rules: net.single_pin (error: a net with one functional pin and no test point), net.testpoint_orphan (error: a net touched only by test points), net.testpoint_stub (warning: one functional pin plus test point(s)), net.whitespace_in_name (warning: a net name with leading or trailing whitespace; for Cadence, the Allegro netlister trims it), net.whitespace_name_collision (error: separate nets whose names read the same once trimmed, such as " SIG" and SIG), net.unnamed (warning: an auto-generated net name on a real 2+-pin net). Test points are identified by the TP refdes prefix. Findings key each net to its REFDES.PIN endpoints (always arrays); net.unnamed lists bare net names. checked lists the rules that ran, so a rule absent from the findings found nothing, and skipped counts the parts left out of the run, such as Do-Not-Stuff ones. Use include_rules/exclude_rules (rule ids) to scope the run and include_dns to count Do-Not-Stuff parts; an unknown rule id returns an error rather than silently checking nothing. Unconnected pins without a no-connect symbol are NOT checked: the parsers cannot reliably tell them apart from intentional no-connects.

Input Schema

NameRequiredDescriptionDefault
designYesPath to design file
include_dnsNoInclude DNS (Do Not Stuff) components in the checks
exclude_rulesNoSkip these rule ids
include_rulesNoOnly run these rule ids (e.g., ['net.single_pin']). Omit for all
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?

Goes well beyond the readOnly/idempotent annotations: full output never truncated, findings grouped by severity then rule id, keys are `REFDES.PIN` arrays, `checked` versus `skipped` semantics, and an explicit non-coverage caveat that unconnected pins without a no-connect symbol are not checked. That limitation is exactly the kind of trait an agent cannot infer from annotations or schema.

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 with purpose and output shape before the rule catalog, and every rule entry carries its severity and meaning rather than being a bare id list. The rule enumeration is long and dense, but each item is load-bearing; it stops just short of maximal tightness.

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?

There is no output schema, and the description compensates fully by describing the returned `errors`/`warnings` grouping, the endpoint keying, and the `checked`/`skipped` fields. For a read-only single-design check with 5 params, nothing needed to call or interpret it 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?

Schema coverage is 100%, so the baseline is 3; the description earns extra by explaining that rule ids drive `include_rules`/`exclude_rules` and that a bad id hard-errors, plus that `include_dns` controls whether DNS parts are counted. It adds nothing for `design_variant`, which is left entirely to the schema.

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?

States a specific verb and resource ('Run electrical rule checks (ERC) on a design's netlist') plus the shape of what comes back. It is unmistakably different from every sibling, which are all list/search/query tools; this is the only validation tool in the set.

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?

Gives concrete operating guidance: use `include_rules`/`exclude_rules` to scope, `include_dns` to count Do-Not-Stuff parts, and an unknown rule id errors rather than silently checking nothing. It does not state when to prefer this over inspecting nets via list_nets/search_nets, so it stops short of full when-not/alternative coverage.

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