AI helper for choosing and speccing network & security products from Cisco, Arista, Juniper and more
Scored across 3 tools
Each tool targets a distinct operation: demand-based platform discovery, exact platform-id lookup, and alternative-product lookup. The descriptions make the input semantics clear (port demand vs. platform id vs. part number/family), so an agent can select the right tool without ambiguity.
All three tools use the same catalog_ prefix followed by a clear verb_noun pattern: find_alternatives, get_platform, search_platforms. The convention is predictable and readable throughout.
Three tools is on the thin side, but each covers a distinct catalog workflow and earns its place. A small set is defensible for a focused catalog API, though one or two additional browsing/lookup tools would round it out.
The surface covers demand-based search, detail retrieval, and alternatives, but lacks a general browse/list or name/vendor/family search operation. Agents cannot easily enumerate platforms or filter by non-port criteria without already knowing a part number or platform id.
Find published alternatives to a product named by part number or family (for example "Cisco 9300X" or "C9300X-48HX"): one class up, the same class, and one class down, all in the same role, same vendor first. Each alternative states the single dimension it was compared on, so present it as "comparable on ", not as a drop-in replacement. An ambiguous name returns the candidate families to choose from. Answers carry catalog_url (the public catalog page) and build_bom_url (Open in SKUit to build a full bill of materials; the builder requires a SKUit account).
Inputs: product (required).
Get the published facts for one platform by its exact platform id (as returned by the other catalog tools). Answers carry catalog_url (the public catalog page) and build_bom_url (Open in SKUit to build a full bill of materials; the builder requires a SKUit account).
Inputs: platform_id (required).
Find published platforms that can serve a port demand (for example 60×100G plus 4×400G for a data-center top-of-rack switch), closest fit first: fewest spare ports, then fewest rack units, then least capacity headroom. Each result explains the fit and lists caveats (breakout cables, a non-default port mode, port-pairing rules) that you should pass on to the user. Also reports how many platforms of the use case meet the demand, how many could not be evaluated, and the nearest misses when nothing fits. Answers carry catalog_url (the public catalog page) and build_bom_url (Open in SKUit to build a full bill of materials; the builder requires a SKUit account).
Inputs: use_case_id (required), port_requirements (required), limit, vendors, +3 more.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
Network hardware BOMs, built inside your AI assistant
AI network lab: build and validate real multi-vendor router and switch labs from a prompt.
IP intelligence, network diagnostics, and AI service availability tools for AI agents.
AI-native product and pricing configuration (CPQ) for manufacturers, every rule checked.
Add one secure layer between your agents and this server.
