This server provides MCP tools for network automation, letting AI agents inventory, query, configure, and generate device configs via Nornir.
get_inventory: List hosts and metadata, optionally filtered by attributes like {"site": "tokyo"}.
run_netmiko_command: Execute show/CLI commands (SSH/Telnet) on filtered hosts in parallel, with optional TextFSM parsing.
run_http_request: Send REST API requests (GET/POST/PUT, etc.) to device API endpoints, with optional JSON payloads, in parallel.
run_serial_command: Run commands over direct serial connections, processed sequentially (one device at a time).
generate_config: Render Jinja2 templates per host to generate configuration (dry-run only; no deployment).
run_netmiko_config: Deploy configuration commands to filtered devices in parallel — a destructive write operation that requires user confirmation.
Filtering: Most tools accept filter_criteria to target specific hosts; omitting it may run on all hosts.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@nornir-mcp-server run show version on core routers in tokyo"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
English | 日本語
nornir-mcp-server is an MCP (Model Context Protocol) server that exposes Nornir, a network automation framework, to AI agents.
Rather than the traditional "iterate over every device in a list" approach, it lets an AI agent leverage Nornir's metadata-based filtering (nornir.filter) to autonomously select targets — e.g. "only the core routers in Tokyo" — and run tasks against them in parallel.
Phase 1, 2, 3 complete (full feature set)
SimpleInventory (YAML) and NetBox (nornir_netbox) support
Parallel execution of show commands (SSH/Telnet)
REST API request execution (via httpx)
Direct serial connection support to hosts (netmiko serial mode)
Dynamic config generation with Jinja2
Deploying configuration to real devices (Config Deploy)
Related MCP server: mcp-netmiko-server
Flexible inventory: Uses Nornir's plugin ecosystem as-is — the standard SimpleInventory (hosts.yaml / groups.yaml) rather than a custom format. Dynamic inventory from NetBox is also supported.
Autonomous filtering: The AI narrows down target devices at runtime by supplying metadata such as {"role": "core", "site": "tokyo"}.
Configuration management and deployment: Give (or have the AI write) a template, and it instantly generates per-host configuration and can push it straight to the real devices.
Multi-protocol support: SSH/Telnet, REST APIs, and physical serial console connections are all reachable from a single MCP server.
Fast parallel execution: Nornir's ThreadedRunner dispatches tasks to multiple devices safely and quickly (serial ports are the exception — see below).
This project is managed with the uv package manager.
cd nornir-mcp-server
uv syncYAML files are used by default; edit config.yaml to switch to NetBox, etc.
By default the config file is loaded from config.yaml next to server.py, but you can point it anywhere with the NORNIR_MCP_CONFIG environment variable (independent of the process's working directory).
export NORNIR_MCP_CONFIG=/path/to/config.yamlOnly the config file path is resolved this way. The host_file / group_file paths inside that config are resolved by Nornir against the process's current working directory, so a config stored outside the repository must use absolute inventory paths.
hosts.yaml / groups.yaml / defaults.yaml contain device credentials and are gitignored. Copy them from the templates:
cp hosts.yaml.example hosts.yaml
cp groups.yaml.example groups.yamlEdit groups.yaml and replace every CHANGE_ME with real login credentials — both the top-level username / password (used by run_serial_command) and the ones under connection_options.netmiko.extras (used for SSH/Telnet). These files are never committed.
config.yaml (SimpleInventory example):
---
inventory:
plugin: SimpleInventory
options:
host_file: "hosts.yaml"
group_file: "groups.yaml"
logging:
enabled: Falseconfig.yaml (NetBox integration example):
⚠️ Unlike the inventory files, config.yaml is tracked in git — never write your NetBox API token into it. NetBoxInventory2 reads the token from the NB_TOKEN environment variable (and the URL from NB_URL).
export NB_TOKEN=your-netbox-api-token---
inventory:
plugin: NetBoxInventory2
options:
nb_url: "https://netbox.local"
logging:
enabled: FalseRun it locally with:
uv run mcp run server.pyGitHub Actions automatically builds and publishes a container image to the GitHub Container Registry (GHCR) on every commit to main.
If you have Docker, you can use the server right away without cloning the repository.
docker pull ghcr.io/nagayon-935/nornir-mcp-server:latestExample:
Mount your config files (config.yaml and the inventory files) into /app in the container. (MCP communicates over stdio, so you'll need -i or similar — follow your MCP client's setup instructions.)
docker run -i --rm \
-v $(pwd)/config.yaml:/app/config.yaml \
-v $(pwd)/hosts.yaml:/app/hosts.yaml \
-v $(pwd)/groups.yaml:/app/groups.yaml \
ghcr.io/nagayon-935/nornir-mcp-server:latestThe following tools are currently exposed to AI agents.
get_inventoryReturns the hosts and their metadata from the current inventory, optionally filtered.
Args: filter_criteria (e.g. {"site": "tokyo"})
run_netmiko_commandRuns a show-style command in parallel across the filtered target devices.
Args: command (the CLI command to run), filter_criteria (target filter), use_textfsm (if True, parses output into structured JSON using ntc-templates)
run_http_requestSends an HTTP request to the REST API endpoint of each filtered target device.
Args: method (GET/POST/etc.), path (API path), filter_criteria, json_data
Configure the target host's inventory data (host.data) with base_url (e.g. https://192.168.1.1), http_headers, tls_verify (True/False), and http_timeout (seconds, defaults to 10) as needed.
run_serial_commandRuns a command over a direct serial connection (console cable, etc.). Physical ports can only be held by one process at a time, so even with multiple target hosts, they are always processed one at a time (never in parallel).
Args: command (the CLI command to run), filter_criteria
The target host's inventory data must include serial_settings (port, baudrate, etc.). Netmiko's serial drivers require a device_type ending in _serial, so either set serial_settings.device_type explicitly, or leave it unset and it will be derived by appending _serial to host.platform (e.g. cisco_ios).
The derivation is not validated against Netmiko's driver table, and Netmiko only ships serial drivers for a subset of platforms. A platform with no matching *_serial driver (e.g. arista_eos → arista_eos_serial) fails with Unsupported device_type; set serial_settings.device_type explicitly in that case.
Login uses the top-level username / password fields from hosts.yaml / groups.yaml / defaults.yaml. It does not read connection_options.netmiko.extras (which is used for SSH connections), so if you also use serial connections, set credentials at the top level too — groups.yaml.example ships both. All three files are gitignored.
generate_configRenders a Jinja2 template (in a sandboxed environment) to generate configuration. Does not deploy it — useful for dry runs and auditing.
Args: template_string (a Jinja2 template), filter_criteria
Only {{ host.name }}, {{ host.hostname }}, {{ host.platform }}, {{ host.groups }}, and {{ host.data['key'] }} are available inside the template. Other host attributes (such as credentials) are intentionally not exposed.
run_netmiko_config⚠️ This is a destructive operation that changes device configuration. Deploys the given configuration commands (or a generated config) to the target devices in parallel.
Args: commands (list of configuration commands to deploy), filter_criteria
This is the only write path in the server. The tool description instructs the agent to confirm with you before calling it — keep a human in the loop for this tool.
Unit tests live in tests/.
uv sync
uv run pytest tests/ -vMIT License
Generate configuration from a Jinja2 template string for each target host. Does NOT deploy the configuration; useful for dry-runs and auditing.
Args: template_string: Jinja2 template string. Available variables: {{ host.name }}, {{ host.hostname }}, {{ host.platform }}, {{ host.groups }}, {{ host.data['key'] }}. Other host attributes (e.g. credentials) are not exposed. filter_criteria: Dictionary to filter target hosts.
| Name | Required | Description | Default |
|---|---|---|---|
| filter_criteria | No | ||
| template_string | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses non-destructive nature (no deployment), available host variables, and notably what is not exposed (credentials). Missing details on error handling or throttling, but solid given no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two focused paragraphs, no fluff, key points front-loaded. Effective use of examples for variables.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, parameters, behavior, and output schema exists to explain return values. No obvious gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, description compensates by explaining template_string as Jinja2 template with examples of available variables, and filter_criteria as filter dictionary. Filter_criteria could be more descriptive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states it generates config from a Jinja2 template and does NOT deploy, clearly distinguishing it from siblings like run_netmiko_config.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Indicates use case (dry-runs/auditing) and non-deployment nature, but does not explicitly name alternatives like run_netmiko_config for actual deployment.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get inventory hosts and their metadata, optionally filtered.
Args: filter_criteria: Dictionary of key-value pairs to filter hosts (e.g. {"name": "router1"} or {"role": "core", "site": "tokyo"}). Matches host attributes or data fields.
| Name | Required | Description | Default |
|---|---|---|---|
| filter_criteria | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states the tool gets data with optional filtering, but does not disclose behavioral traits like idempotency, read-only nature, or side effects. The description is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the main action. The parameter explanation is efficient and fits in a single sentence with examples, with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one optional parameter and no annotations, the description adequately covers the parameter usage. The output schema exists, so not describing return values is acceptable. Overall, it is complete enough for an inventory retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates by providing concrete examples (e.g., {'name': 'router1'}) and explaining that keys match host attributes. This adds meaningful context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'inventory hosts and their metadata', and mentions optional filtering. This effectively distinguishes it from sibling tools like run_netmiko_command which run commands.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving inventory data with optional filters, but does not explicitly state when to use this tool versus alternatives, or provide when-not or exclusion cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run an HTTP API request (REST) concurrently on multiple hosts.
Args: method: HTTP method (e.g., 'GET', 'POST', 'PUT'). path: API path to request (e.g., '/api/v1/system'). filter_criteria: Dictionary to filter target hosts. json_data: Optional JSON payload for POST/PUT requests.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| method | Yes | ||
| json_data | No | ||
| filter_criteria | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It reveals that requests run concurrently on multiple hosts, which is a key behavioral trait. However, it does not cover error handling, authentication requirements, rate limits, or what happens on failure. The description is moderately transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded. It uses a standard docstring format with an Args section, making it easy to parse. Every sentence provides useful information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, an output schema (not shown), and no annotations, the description covers the essential purpose and parameter semantics. It omits behavioral details like concurrency mechanics and error responses, but the presence of an output schema reduces the need to describe return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain parameters. It adds meaning by describing each parameter (method, path, filter_criteria, json_data) with context like 'Optional JSON payload for POST/PUT requests.' This goes beyond the schema's bare property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action: 'Run an HTTP API request (REST) concurrently on multiple hosts.' This distinguishes it from sibling tools like run_netmiko_command and generate_config which target network devices and config generation respectively.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions concurrency on multiple hosts but provides no explicit guidance on when to use this tool versus alternatives. An agent must infer that HTTP APIs should use this tool, while Netmiko or serial commands are for other protocols. No when-not-to-use or prerequisite conditions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a show command concurrently on multiple hosts via Netmiko.
Args: command: The CLI command to execute (e.g., 'show version'). filter_criteria: Dictionary of key-value pairs to filter target hosts. If empty, runs on ALL hosts! use_textfsm: If True, attempts to parse output into structured data using ntc-templates.
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes | ||
| use_textfsm | No | ||
| filter_criteria | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses concurrency and filter_criteria behavior (runs on all hosts if empty). However, no annotations exist, and the description does not mention error handling, timeout, or read-only nature. Adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise with three focused lines (Args format). No wasted words. Front-loads purpose and clearly separates parameter descriptions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and output schema, the description covers parameters and key behaviors. Lacks return value details but output schema likely provides them. Reasonably complete for a moderate-complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds significant meaning for all 3 parameters: command (example), filter_criteria (filtering and default behavior), use_textfsm (parsing attempt). Fully compensates for schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Run a show command concurrently on multiple hosts via Netmiko' with specific verb, resource, and method. Distinguishes from siblings like run_netmiko_config and run_serial_command.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies use for show commands, but no explicit when-to-use vs alternatives. The description notes filter_criteria behavior but lacks guidance on choosing this over run_netmiko_config or others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
WRITE OPERATION: modifies device configuration. Deploy configuration commands concurrently to multiple hosts via Netmiko. Confirm with the user before calling this tool.
Args: commands: List of configuration commands to execute. filter_criteria: Dictionary to filter target hosts.
| Name | Required | Description | Default |
|---|---|---|---|
| commands | Yes | ||
| filter_criteria | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It correctly identifies itself as a WRITE OPERATION and mentions concurrent deployment, but lacks details on side effects (e.g., whether changes are saved, rollback options, authentication requirements). This is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (5 lines), front-loads the critical 'WRITE OPERATION' tag, and uses a brief Args section. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists, return values are not required. The description covers purpose, usage guideline, and parameter semantics. However, for a device config modification tool, more context on safety (e.g., backup, confirmation flow) would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates by explaining both parameters: 'commands' as a list of configuration commands and 'filter_criteria' as a dictionary to filter hosts. This adds meaningful guidance beyond the schema's basic type information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool modifies device configuration and deploys commands concurrently via Netmiko. The verb 'modifies' and resource 'device configuration' are specific, and the method 'concurrently to multiple hosts' distinguishes it from siblings like run_netmiko_command and run_serial_command.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises to confirm with the user before calling, which is a useful guideline. However, it does not explicitly compare to sibling tools or state when to use this tool versus run_netmiko_command (which likely executes single commands) or others, leaving usage context partially implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a CLI command on devices via direct Serial connection (using Netmiko).
Note: Physical serial ports generally cannot be used concurrently by multiple threads, so hosts are processed sequentially (one at a time).
Args: command: The CLI command to execute (e.g., 'show version'). filter_criteria: Dictionary to filter target hosts.
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes | ||
| filter_criteria | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds important context: sequential host processing and the physical serial port limitation. However, it omits details like authentication requirements, error handling, or side effects. The provided information is adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is fairly concise: two sentences plus a note and arg list. It front-loads the main action and resource. The arg list repeats schema info but adds examples, which is acceptable. Minor redundancy (e.g., stating 'Use:') could be trimmed, but overall it's well-structured and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (running CLI commands serially), the description covers purpose, a key behavioral trait, and basic parameter semantics. An output schema exists to document return values. However, it lacks details on error handling, prerequisites, or the exact meaning of filter_criteria. It is fairly complete but could be more robust.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning. It explains 'command' with an example and 'filter_criteria' as a dictionary to filter hosts. This adds value beyond the bare schema, but the structure of filter_criteria is not detailed (e.g., expected keys). The description partially compensates but could be more thorough.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Run') and resource ('CLI command on devices via direct Serial connection using Netmiko'). It distinguishes from sibling tools like 'run_netmiko_command' which likely use SSH/Telnet, making the purpose specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a key usage note about sequential processing due to serial port constraints, which is valuable. However, it does not explicitly contrast with sibling tools like 'run_netmiko_command' or 'run_http_request', nor does it state when not to use this tool. The information is helpful but leaves some decision-making to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0generate_configget_inventoryrun_http_requestrun_netmiko_commandrun_netmiko_configrun_serial_commandEach tool has a distinct purpose: inventory retrieval, command execution via Netmiko/Serial/HTTP, config generation, and config deployment. No two tools overlap in function; the transport-specific tools are clearly differentiated.
All tools follow a consistent verb_noun pattern using snake_case (e.g., get_inventory, run_netmiko_command). The naming is predictable and self-explanatory.
With 6 tools, the server is well-scoped for network automation. It covers essential operations without being bloated or insufficient.
The tool set covers inventory, multi-protocol command execution, config generation, and config deployment. Missing a serial config deployment tool and perhaps backup/restore, but core workflows are supported.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Give your AI agents the tools to build, manage, and run automation workflows.
Build, validate, and deploy multi-agent AI solutions from any AI environment.
AI agent infrastructure for discovery, authorization, execution, identity, and signed receipts.
Let AI operate servers without SSH. Choose actions, approve risky changes, and audit every step.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/nagayon-935/nornir-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
