ENSP-MCP AI
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| logging | {} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| register_deviceC | Register an eNSP device by name and TCP port. |
| unregister_deviceC | Remove a registered eNSP device. |
| list_devicesB | List registered eNSP devices. |
| auto_discoverB | Auto-discover eNSP devices by scanning local ports. |
| execute_cliB | Execute a single display/query command on a device. |
| mcp_executeC | Execute a single command on a topology-synced eNSP device by its name via local MCP console port. |
| push_configA | Push configuration commands sequentially; stop on the first failure and report unexecuted commands. Applied commands are not rolled back. |
| mcp_push_configA | Push commands to a topology-synced device; stop on the first failure. Applied commands are not rolled back. |
| multi_device_push_configA | Validate all batches, then push configuration sequentially. Stop remaining commands and devices on the first failure; no automatic rollback. |
| save_configB | Save configuration, answering Y/N and accepting a default filename. Success requires a save completion message and final console prompt. |
| get_running_configC | Read the running configuration of a device. |
| ping_from_deviceC | Run ping from a device. |
| traceroute_from_deviceC | Run traceroute from a device. |
| health_checkC | Run a quick health check on one device. |
| mcp_health_checkA | Check connectivity for a topology-synced eNSP device via local MCP console port. |
| multi_health_checkC | Run health checks for multiple devices. |
| discover_topologyA | Parse an eNSP .topo file, or summarize the current uploaded topology.json from the web UI when given that JSON path. |
| find_topo_filesB | Check whether the web UI already uploaded topology.json, and only then search for extra local .topo files if needed. |
| sync_topology_devicesC | Register devices from topology.json into the MCP device registry using their eNSP local console ports. |
| get_topology_contextA | Preferred first step for topology-aware tasks. Read the latest topology uploaded from the web UI so the AI can understand current devices, links, and local ports. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| ensp_ops_playbook | Topology-first guidance for accurate ENSP operations. |
| ensp_senior_network_engineer | Role definition for a senior network engineer working on ENSP with MCP tools. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| current_topology | Latest uploaded topology from the web UI. No topology uploaded yet. |
| registered_devices | Current MCP device registry derived from manual registration, auto-discovery, or topology sync. |
TDQS
Scored across 20 tools
Several tools are near-duplicates with only subtle target differences: execute_cli vs mcp_execute, push_config vs mcp_push_config, and health_check vs mcp_health_check. Topology tools such as discover_topology, find_topo_files, get_topology_context, and sync_topology_devices also overlap enough that an agent could easily choose the wrong one.
Most tools use snake_case verb_noun naming, but the set mixes plain names with mcp_ and multi_ prefixes, and health_check is noun-first rather than verb-first. The pattern is readable but not fully predictable across the whole server.
20 tools is on the heavy side for an eNSP device-management server, especially because several mcp_ variants duplicate their base counterparts. The scope is plausible, but the surface feels somewhat inflated by redundant topology-synced-device versions.
Core workflows are covered: device registration, discovery, CLI execution, configuration push/save, connectivity checks, and topology synchronization/context. Minor gaps remain, such as device metadata updates, broader batch CLI execution, topology editing, and explicit rollback support.