Related Servers

The set is deliberately pairwise: list vs search for nets and components, and query_xnet_by_net_name vs query_xnet_by_pin_name differ only in their input anchor. Each description explicitly steers callers (e.g. 'Rejects patterns that match all items; use list_components for full results', 'if the refdes is not found, search_components_by_refdes finds it'), so the boundaries are unambiguous. The three search_components_by_* variants are cleanly separated by field, with fallback guidance when a field is absent.

All names are snake_case verb_noun with a consistent suffix grammar (_by_refdes, _by_mpn, _by_description, _by_net_name, _by_pin_name). The only wrinkle is three retrieval verbs (list_ for enumeration, search_ for filtered lookup, query_ for detail fetch), which is semantically motivated but not a single rigid pattern, and query_component sits slightly apart from the search_components_* family.

Eleven tools is well within the sweet spot and each one maps to a distinct question an agent would ask of a netlist (discover designs, enumerate/search nets, enumerate/search/detail components, trace XNETs from either end, run ERC). No tool looks redundant padding, and no core operation is split across multiple near-duplicates.

The surface covers the full read-only analysis lifecycle: design discovery and variant handling, net and component enumeration and search, detail lookup, connectivity tracing, and ERC. Gaps are minor: there is no direct net-detail tool (net info must be reached via search_nets or an XNET query) and no BOM/export or differential-pair/bus-level query, though agents can approximate these with existing tools.