Network Lab MCP
OfficialServer 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": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_active_topologyA | Return the currently active lab topology: where the work is performed and which devices and links exist. Settings and the topology YAML are reloaded from disk on every call, so editing lab/settings.yaml takes effect immediately without restarting this server. |
| get_execution_instructionsA | Return the operating principles, the active scenario, and the active
reference knowledge for the current task: how to behave, what to
accomplish, and what reusable knowledge is available. Also returns
metadata-only catalogs (name + description) of every stored scenario
and reference, so existing knowledge can be discovered and reused.
Optional |
| terminal_openA | Open (or reuse) a terminal session for a device in the active topology, launching ssh or telnet inside a dedicated tmux environment. The active topology is reloaded from disk before opening the session. An interactive login prompt from the device itself is answered automatically using the active access-info definition's own private credentials, once it can be safely confirmed to belong to the target device (never a jump host) -- credentials are never returned by this tool or any other. This works for SSH (the client's own password prompt) and for Telnet (a classic-IOS-style Username:/Password: sequence); which one applies depends on the device's own configured transport. A host-key confirmation prompt, or any other situation this cannot safely resolve on its own, is still left for terminal_read()/terminal_send() to handle interactively. |
| terminal_sendA | Send input to a device's open terminal session. The device must still be present in the active topology, reloaded from disk on every call -- an already-open session does not stay usable if the active topology changes to no longer include this device. Execution order is fixed and deterministic: if |
| terminal_readA | Capture recent terminal output for a device, so the caller can inspect
the current prompt, command output, a password/interactive prompt, paging
state, or unexpected errors. |
| terminal_listA | List every currently managed production terminal session, regardless of whether each device is still present in the active topology -- including a stale session left over from before the active topology changed, so it remains visible and closeable via terminal_close() even though terminal_send()/terminal_read() will refuse to use it. Local validation sessions are never included, regardless of whether a device happens to be named similarly to a validation identifier. |
| terminal_closeA | Close a device's managed production terminal session. Only ever targets the production session namespace; cannot affect validation sessions. Deliberately does not require the device to still be present in the active topology, so a stale session left over from before the active topology changed can always be closed. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 7 tools
The five terminal_* tools have crisp, non-overlapping roles (open/send/read/list/close), and the list-vs-send/read distinction around stale sessions is explicitly documented. The main soft spot is the pair get_active_topology vs get_execution_instructions, which both 'return current context' and could be conflated at a glance, though the descriptions do draw a clear line between topology/settings and operating principles/scenarios.
All names are snake_case verb_noun with predictable prefix grouping: get_* for context reads and terminal_* for the session lifecycle. No mixing of conventions or vague verbs.
Seven tools is well-scoped for a lab-interaction server: two context readers plus a complete five-verb terminal session surface. Every tool earns its place with no filler.
The terminal lifecycle is fully covered (open, send, read, list, close), including stale-session visibility and cleanup, and topology/instruction reads cover the context side. Gaps are minor and intentional: definitions/scenarios are read-only by design and there are no terminal resize or validation-session management tools, but core agent workflows are not blocked.