Query network devices on platforms NetClaw's Cisco- and Juniper-specific servers cannot reach — MikroTik RouterOS, VyOS, SONiC, Nokia SR Linux, Extreme, Huawei, Dell, Ubiquiti EdgeOS, and roughly eighty more.
MCP server: multivendor-cli-mcp (results identify themselves as multivendor-cli)
Decide which server to use FIRST
This skill is wrong for most Cisco and Juniper work. Check here before using it:
| Your device | Use |
|---|---|
| Cisco IOS / IOS-XE / NX-OS / IOS-XR | pyats-* skills — ~2000 Genie parsers, state diffing |
| Juniper Junos | junos-network skill — PyEZ/NETCONF |
| Streaming telemetry, any vendor | gnmi-telemetry skill |
| No direct reachability | radkit-remote-access skill |
| Anything else | this skill |
| "Compare X across Cisco and Arista and Nokia" | this skill (read-only) |
That last row is the exception worth understanding. NAPALM returns one shape across vendors, so this is the only server that can answer a genuinely cross-vendor question. It answers those read-only, even on Cisco and Juniper.
Configuration writes on Cisco and Juniper are refused, naming the correct server. That is deliberate, not a limitation: one write path per platform is what makes "verify the change" mean something. Reads may overlap between servers; writes may not.
Tools
| Tool | Purpose |
|---|---|
server_info |
Server identity, read-only vs write mode, which platforms have destructive-syntax modelling |
check_command_policy |
Would this command be permitted? Answers without touching a device |
list_devices |
Inventory, with the source that answered and why |
check_device_readiness |
Is this device resolvable, authenticable, and mine to act on? Contacts nothing |
Workflow
list_devices— confirm the device is in inventory and seeowning_server. If that ispyatsorjunos-mcp, stop and use that server for single-device work.check_device_readiness— verify credentials resolve and check what this server may do. Run this before anything else on a new device: it separates not in inventory from credentials missing from owned by another server, which need three different fixes.check_command_policy— before an unusual command, confirm it passes policy.
Reading the results
source_used names which inventory source answered: live_sot, generated, or operator. When
it is not live_sot, fallback_reason says why — treat those results as potentially stale.
credential_path says vault or environment. Both are supported; Vault is not required.
status: refused with owning_server means routing sent you elsewhere. This is a successful
call, not an error — read refused_reason and use the named server.
Safety
Read-only by default; write tools are absent from the tool list unless an operator sets
MULTIVENDOR_WRITE_ENABLED. Command filtering is enforced server-side, so it cannot be bypassed
by rephrasing a request. Evaluation order: chaining (;, &&, ||, >, <) is rejected first,
then per-platform destructive verbs, then the read-only allowlist.
Chaining is checked first because show version; write erase begins with an allowlisted verb.
A single | is fine — on network devices that is a display filter, not a shell pipe.
Environment variables
See .env.example for the full set. MULTIVENDOR_INVENTORY_SOURCE,
MULTIVENDOR_INVENTORY_PATH, MULTIVENDOR_USERNAME/MULTIVENDOR_PASSWORD,
MULTIVENDOR_WRITE_ENABLED. Never put credentials in an inventory file — the server rejects
inventory records containing credential-shaped fields.
Caveat worth knowing
Netmiko also drives Fortinet, PAN-OS and Check Point, so this server gives CLI-level reach to them. That is not equivalent to their dedicated API integrations — FortiManager's policy-package model and Panorama's device groups have no CLI equivalent. Do not treat CLI reach as full vendor support.
Caveat: CLI reach is not full vendor support
netmiko also drives Fortinet, Palo Alto PAN-OS and Check Point, so this server gives CLI-level reach to them today. That is not equivalent to their dedicated API integrations:
| Vendor | What CLI gives you | What it does NOT give you |
|---|---|---|
| Fortinet | FortiOS CLI reads | FortiManager policy packages, ADOM model, install preview |
| Palo Alto | PAN-OS CLI reads | Panorama device groups, templates, commit validation |
| Check Point | GAiA CLI reads | Management API policy layers, threat intel |
Roadmap items R3 (Fortinet) and R4 (Palo Alto) are still needed. Do not treat CLI reach as completing them.
SSH trust and write boundary
SSH host keys are verified by default. If an unknown or changed key is refused,
verify the identity through a trusted console/administrator and follow
docs/MULTIVENDOR-SSH-MIGRATION.md; never disable checking as an automatic retry.
Raw commands remain read-only even when write tools are enabled. Configuration
must use the gated apply_config path with the required approvals and baseline.