Skip to main content
Glama
Sign In
IntelligentElectron

Universal Netlist MCP Server

by IntelligentElectron
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Search components by MPN

search_components_by_mpn
Read-onlyIdempotent

Search components by Manufacturer Part Number regex pattern in a netlist design to locate parts; if MPN data is unavailable, use reference designator or description search instead.

Instructions

Search for components by MPN (Manufacturer Part Number) pattern. Not all netlists include MPN data; if unavailable, fall back to search_components_by_refdes or search_components_by_description, or ask the user for a BOM. component_notes names the parts with no MPN. Rejects patterns that match all items; use list_components for full results.

Input Schema

NameRequiredDescriptionDefault
designYesPath to design file
patternYesRegex pattern for MPN
include_dnsNoInclude DNS components, flagged dns=true. Pass false for fitted parts only
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.4/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the description adds genuinely new behavior: MPN data may be absent, `component_notes` enumerates parts lacking an MPN, and broad match-all patterns are rejected. It stops short of describing result ordering or how many matches are typical, so not a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four short sentences, each carrying distinct load: purpose, data-availability caveat plus fallbacks, a diagnostic field, and a failure-mode guard. Purpose and fallback path are front-loaded with no filler.

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?

Covers the failure modes that matter most for this tool (missing MPN data, over-broad pattern rejection) and the escape hatch, which is sufficient given 100% schema coverage and a simple read-only shape. Return shape is unspecified but no output schema exists, so a small gap remains.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so `pattern`, `design`, `include_dns`, and `design_variant` are already documented. The description restates that `pattern` targets MPN but adds no syntax, anchoring, or matching-semantics detail beyond the schema. Baseline 3 is appropriate.

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 ('Search for components by MPN pattern') and immediately names the distinguishing axis versus siblings search_components_by_refdes and search_components_by_description. An agent can route correctly without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit when-to-use ('by MPN pattern'), when-not (netlists without MPN data), concrete alternatives (refdes, description search, ask user for a BOM), and a full-listing alternative (list_components). This is the strongest form of routing guidance.

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