check_device_sync
Check the sync status for a specific device in Cisco NSO. Requires a 'device_name' parameter.
LABSCO SUMMARY
A read-mostly window onto NSO: sync_from_device is the call that changes anything, and it pulls from the device rather than pushing configuration to it.
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.
What it is
A server fronting a Cisco NSO instance, exposing its device inventory, per-device configuration and state, service catalogue and the sync-from operation.
What you get
- 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'.
Requirements
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.
Setup effort
One command plus credentials — pip install cisco-nso-mcp-server, then supply credentials
USE CASES
01
Settling whether the box matches what NSO thinks it has
Ask NSO for its sync verdict on the device, read the configuration it is holding, and pull the device's own state back in when the two have drifted apart.
02
Getting oriented in an NSO deployment you did not build
Read what the instance already knows — how devices are grouped, which drivers are loaded, and what services it is set up to render.
03
Reading a device's platform and state while an incident is open
Pull what the device is, what it is doing now, and what configuration it is running, without opening a session to it yourself.
9 tools
Counted once with only startup setup. Other versions, modes or optional credentials may expose a different list.
get_device_config
Retrieve the full configuration for a specific device in Cisco NSO. Requires a 'device_name' parameter.
get_device_groups
Retrieve the available device groups in Cisco NSO.
get_device_ned_ids
Retrieve the available Network Element Driver (NED) IDs in Cisco NSO.
get_device_platform
Retrieve platform information for a specific device in Cisco NSO. Requires a 'device_name' parameter.
get_device_state
Retrieve the state for a specific device in Cisco NSO. Requires a 'device_name' parameter.
get_service_types
Retrieve the available service types in Cisco NSO.
get_services
Retrieve the available services in Cisco NSO. Requires a 'service_type' parameter.
sync_from_device
Sync from a specific device in Cisco NSO. Requires a 'device_name' parameter.
BEFORE YOU INSTALL
What to know first
Tools you get
9 tools when we connected. Eight tools read; the only state-changing one is sync_from_device. You cannot deploy or modify services or devices.
Requires
- uvx on PATH
- Python 3.12+
- A Cisco NSO instance with the RESTCONF API enabled, reachable from this machine
- Your NSO username and password, passed as --nso-username / --nso-password (or NSO_USERNAME / NSO_PASSWORD)
Where it runs
Both documented setups run the server on your machine.
CONTEXT COST
Light Standing cost
Rated by the size of the 9 tool definitions that ride along on every turn, not by how many there are
INSTALLATION
Connect your client
Server setup
TERMINAL
pip install cisco-nso-mcp-serverMCP Clients
Windsurf — uvx
WINDSURF — UVX · JSON
{
"mcpServers": {
"nso": {
"command": "uvx",
"args": [
"cisco-nso-mcp-server",
"--nso-address=127.0.0.1",
"--nso-port=8080",
"--nso-username=admin",
"--nso-password=admin"
],
"env": {
"LOG_FILE": "<YOUR_PATH_TO_LOGS>/nso-mcp.log"
}
}
}
}Both blocks pass the NSO login as --nso-username and --nso-password, filled with the README's defaults (admin / admin), and point at 127.0.0.1:8080; yours are your own NSO's address, port, username and password. The env block is optional — LOG_FILE only adds logging to a file.
Windsurf — pip
WINDSURF — PIP · JSON
{
"mcpServers": {
"nso": {
"command": "<YOUR_PATH_TO_ENV>/bin/cisco-nso-mcp-server",
"args": [
"--nso-address=127.0.0.1",
"--nso-port=8080",
"--nso-username=admin",
"--nso-password=admin"
],
"env": {
"LOG_FILE": "<YOUR_PATH_TO_LOGS>/nso-mcp.log"
}
}
}
}Both blocks pass the NSO login as --nso-username and --nso-password, filled with the README's defaults (admin / admin), and point at 127.0.0.1:8080; yours are your own NSO's address, port, username and password. The env block is optional — LOG_FILE only adds logging to a file.
