Arguments arrive through a single 'params' object rather than named fields, and the key that call needs is stated in the description — 'device_name' for the per-device tools, 'service_type' for get_services — so a caller has to read the description to construct the request. What that buys is the investigative work of an NSO session without a shell: get_device_config and get_device_state answer what is on the box, check_device_sync answers whether NSO agrees, and sync_from_device closes the gap. Nothing here creates or modifies a service, so an agent given this can investigate a network it cannot reconfigure.
A server fronting a Cisco NSO instance, exposing its device inventory, per-device configuration and state, service catalogue and the sync-from operation.
- Device facts by name: get_device_platform, get_device_config and get_device_state return a named device's platform information, full configuration and state, addressed by a 'device_name'.
- Drift detection and the correction for it: check_device_sync reports whether NSO agrees with a named device, and sync_from_device pulls that device's configuration back into NSO.
- Inventory to work from: get_device_groups returns the device groups NSO has configured, and get_device_ned_ids returns the available Network Element Driver (NED) IDs.
- The service side of the same instance: get_service_types lists the service types NSO knows about, and get_services lists the instances of one, addressed by a 'service_type'.
A reachable Cisco NSO instance at a known address and port, an NSO username and password for it, and a file path for LOG_FILE.
One command plus a key — pip install cisco-nso-mcp-server, then supply credentials