Loading ToolBench
MCP server for Cisco Catalyst SD-WAN Manager (vManage) — read-only fabric inventory, device health, BFD/OMP/control-connection state, alarms, tunnel quality, templates and policies for AI assistants.
Strong foundation with 27 well-named tools following verb_noun convention (list_, get_, update_, deploy_, activate_, check_). All tools have descriptions (avg 156 chars, within 10-1024 baseline). Input schemas present with type definitions for all parameters. However, output schemas are not explicitly documented in source code, responses are inferred from code logic rather than declared. Parameter descriptions are generally good (avg 85 chars) but some lack constraint details (e.g., 'hours' lacks min/max bounds). Error handling is minimal, no recovery guidance or actionable error messages visible. Tool composition is excellent: single responsibility, clear chaining (e.g., get_config_group → update_parcel → deploy_config_group). Naming is consistent and unambiguous. Missing: explicit output schema documentation, enum constraints for string parameters, and structured error responses.
Activate a centralized (vSmart) policy across the fabric. This changes production traffic handling fabric-wide — activating a policy deactivates whichever one is currently live. Review the target with ``list_policies`` first.
Attach a device template to devices, pushing configuration to them. This changes production configuration. Call ``get_template_input_variables`` first to build and review ``device_variables``, then pass its ``device_values`` here unchanged.
Triage one device in a single call: system health, control plane, data plane. Aggregates system status, control connections and BFD sessions, then reports what is wrong rather than making the caller compare three result sets. Use this as the entry point for "why is site X down".
Push a config group's edited profiles to its member devices. Devices show ``configGroupUpToDate: false`` until this runs — it is the commit step after ``update_parcel`` / ``update_cli_addon_config``.
Summarise alarm counts by severity and component without listing them. Cheap situational awareness — call this before ``list_alarms`` to decide which severity is worth pulling in full.
Output schemas not explicitly documented. Response structures are inferred from code logic (e.g., envelope(), project() calls) rather than declared in tool definitions. LLMs cannot reliably predict what fields to expect or plan downstream tool calls.
Numeric parameters lack bounds. 'hours' parameter accepts float with no min/max documented. LLMs may pass negative, zero, or absurdly large values (e.g., 999999 hours). Should specify range (e.g., 0.1 - 8760 hours).
String enums not enforced in schema. 'severity' parameter accepts free-form string with validation only in code (SEVERITIES tuple). Schema should declare enum constraint so LLMs see valid options upfront.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | B | 70 | 2026-07-28+ | v2 |
Show a device's BFD sessions — the data-plane tunnels to other edges. A BFD session in any state other than "up" means traffic cannot use that tunnel. Check this when sites can reach the controllers but not each other.
Get one config group with its profiles and associated devices.
Get the device variables a config group's profiles reference — the knobs that differ per device.
Show a device's control-plane connections to vSmart, vBond and vManage. The first thing to check when a device is unreachable or will not come up: without control connections the device has no OMP routes and no policy.
Get the full status record for one device.
Report which config group manages a device, if any. Answers "may I template this device?" as much as "where is its config": a device managed by a config group must be changed through that group's feature profiles and ``deploy_config_group`` — attaching a device template to it would fight the group for ownership.
Summarise fabric health in one call: counts by type, state and version. Start here when asked an open question about the network — it is one round trip and tells you whether to drill into unreachable devices, control connections or alarms next.
Get a feature profile with its parcels and their schemas.
Show a device's interfaces with status, addressing and error counters.
Show a device's OMP peering sessions and their state. OMP is how SD-WAN distributes routes. Control connections up but OMP peers down means the overlay has no reachability information.
Get one parcel's payload and schema.
Get the JSON schema for a parcel type — what fields it holds and their types.
Show a device's system health: uptime, CPU, memory, disk and last reboot.
Check whether an asynchronous vManage task has finished.
List fabric alarms raised in a recent time window.
List config groups: profiles, device counts and up-to-date state. A device count above ``numberOfDevicesUpToDate`` means edited profiles have not been deployed yet. Use ``get_config_group`` for the member devices and ``get_feature_profile`` to open a profile.
List devices in the SD-WAN fabric with their current status. Covers both edge routers and controllers as vManage knows them right now, including reachability, site, model and software version.
List fabric events in a recent time window. Events are the raw log stream behind alarms — noisier, but they show transitions (interface flaps, BFD state changes, reboots) that never become alarms.
List feature profiles by type — the building blocks of config groups.
List provisioned devices from vManage's inventory, including offline ones. Distinct from ``list_devices``: that reports devices vManage is currently talking to, while this reports everything provisioned — useful for finding devices that were never onboarded, have invalid certificates or carry no device template.
Add to or replace the CLI add-on profile — raw IOS-XE config lines. The CLI add-on is the escape hatch for anything the structured parcels cannot express (e.g. per-interface ``cdp enable`` / ``lldp transmit``). Review the result diff carefully: these lines are merged into the device configuration verbatim on the next ``deploy_config_group``.
Edit fields of a feature-profile parcel (read-modify-write PUT). Fetches the parcel, applies ``updates`` and PUTs the result back — only the named paths change. Check ``get_parcel_schema`` first when unsure which parcel owns a setting or what shape it takes; most values are ``{"optionType": "global", "value": ...}``. Devices keep running the old config until ``deploy_config_group``.
No error recovery guidance. Tools return error dicts (e.g., {'error': 'InvalidSeverity', 'message': '...'}) but do not guide LLM on next steps. Should include 'try_next' or 'recovery_hint' field.
Confirmation pattern ('confirm' parameter) relies on elicitation but lacks fallback. If elicitation unavailable, 'confirm' is ignored silently. Should document behavior and provide explicit dry-run alternative.