io.github.shigechika/junos-mcp
This MCP server gives AI assistants a safe, tag-aware interface to Juniper Junos devices for inspection, configuration, upgrades, diagnostics, and daily health checks.
Query device facts, JUNOS versions, router inventory/tags, package info, version comparisons, and server/config health without connecting to devices.
Run show commands on one or many devices (text/JSON/XML), including parallel batches and server-side-style
grep_patternfiltering.Read device configs (text/set/xml), show rollback diffs, and push configs with dry-run default, commit confirmed, health checks, auto-rollback, and background job polling.
Check upgrade readiness and manage firmware: list remote files, SCP copy with checksum, install/rollback packages, and schedule reboots.
Collect RSI/SCF from single or multiple devices.
Run pre-flight checks: NETCONF reachability/disk, local firmware checksums, and remote staged-package verification.
Run
daily_briefhealth sweeps (alarms, interface down, syslog alerts, RE faults, route baseline), synchronously or as a background job.Apply tag-based host filtering across batch operations, with destructive operations defaulting to dry-run.
Provides tools for managing Juniper Networks devices via NETCONF, including device information retrieval, CLI command execution, configuration management, firmware upgrades, diagnostics, and daily operations.
Click on "Deploy 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., "@io.github.shigechika/junos-mcp run show version on router-1"
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.
junos-mcp
English | 日本語
MCP (Model Context Protocol) server for junos-ops.
Exposes Juniper Networks device operations to MCP-compatible AI assistants (Claude Desktop, Claude Code, OpenAI Codex, etc.) via STDIO transport. While junos-ops is the CLI tool for humans, junos-mcp is the AI-facing interface to the same powerful engine.
Features
Device Information
Tool | Description | Connection |
| Get basic device information (model, hostname, serial, version) | Yes |
| Get JUNOS version with upgrade status | Yes |
| List routers from config.ini (optionally filtered by tags) | No |
| Report server version + config status (router count, distinct tags). Lightweight; does NOT connect to any device | No |
CLI Command Execution
Tool | Description | Connection |
| Run a single CLI show command ( | Yes |
| Run multiple CLI commands in a single session ( | Yes |
| Run a command on multiple devices in parallel (supports tag filter and | Yes |
Configuration Management
Tool | Description | Connection |
| Get device configuration (text/set/xml format) | Yes |
| Show config diff against a rollback version | Yes |
| Push config with commit confirmed + health check | Yes |
| The same push as a background job, for hosted clients that cut a call at about 60 s and for slow-committing models (SRX branch): | Yes |
Upgrade Operations
Tool | Description | Connection |
| Check if device is ready for upgrade | Yes |
| Compare two JUNOS version strings | No |
| Get model-specific package file and hash | No |
| List files on remote device path | Yes |
| Copy firmware package via SCP with checksum | Yes |
| Install firmware with pre-flight checks ( | Yes |
| Rollback to previous package version | Yes |
| Schedule device reboot at specified time | Yes |
Diagnostics
Tool | Description | Connection |
| Collect RSI/SCF with model-specific timeouts | Yes |
| Collect RSI/SCF from multiple devices in parallel (supports tag filter) | Yes |
Pre-flight Checks
Equivalent to the junos-ops check subcommand modes. All three reuse the
junos-ops display layer for table rendering.
Tool | Description | Connection |
| Probe NETCONF reachability + available disk space per host (fast: no facts, 5s TCP probe) | Yes |
| Verify local firmware checksums against config.ini inventory | No |
| Verify staged firmware checksum + available disk space on devices (post-SCP verification) | Yes |
Daily Operations
Tool | Description | Connection |
| Morning health check across multiple devices in parallel — alarms, interface up/down, syslog alert patterns within a look-back window ( | Yes |
| Run the same sweep as a background job for fleets too large for one call (a hosted client's per-call limit is about 60 s): | Yes |
Safety by Design
All destructive operations (push_config, copy_package, install_package,
rollback_package, schedule_reboot) default to dry-run mode (dry_run=True).
The AI assistant must explicitly set dry_run=False to make changes.
push_config provides additional safety features not found in other Junos MCP servers:
commit confirmed with configurable timeout (auto-rollback if not confirmed)
Fallback health check after commit (ping, NETCONF uptime probe, or any CLI command)
Automatic rollback if health check fails (commit is not confirmed, timer expires)
no_commit=True— issuescommit confirmedbut intentionally skips the final commit. JUNOS auto-rolls back afterconfirm_timeoutminutes. Useful for restarting services that lack arequest ...restartcommand (e.g. syslog daemon on EX3400 post-upgrade).
RPC timeout and the per-call deadline. Every load/commit RPC uses
timeout from the host's config.ini section, else the junos-ops model
default: 180 s on SRX branch models (SRX300/320/340/345 and the like, whose
commits can exceed 30 s), 120 s otherwise. It is never shortened. With
JUNOS_DEADLINE set (default 45 s; 0 disables), push_config runs the push
as a background job and waits for it until shortly before the deadline: if it
finishes, the answer is the same as without a deadline; if not, the answer
says Still running with a job_id to poll with push_config_result.
push_config_start returns the diff and the job_id without waiting for the
commit; the job loads and diffs the change and then commits on the same locked
session, so what is committed is exactly the diff returned. A failure after
commit confirmed has been sent is reported as a possibly pending commit that
rolls back on the device after confirm_timeout minutes. Only one push per
host runs at a time; a second one is refused, and other tools on that host
wait at most until the deadline and then answer host busy.
Related MCP server: juniper-mist-mcp
Requirements
Python 3.12+
junos-ops with a valid
config.iniMCP Python SDK >= 1.0
Installation
pip install junos-mcpOr for development:
git clone https://github.com/shigechika/junos-mcp.git
cd junos-mcp
python3 -m venv .venv
. .venv/bin/activate
pip install -e ".[test]"CLI options
python -m junos_mcp --helpOption | Description |
| Print version and exit |
| Load config.ini, list routers, and exit (exit code 1 on error) |
| With |
| Transport protocol (default: |
| streamable-http only: address and port to listen on (default: |
--check is handy to verify JUNOS_OPS_CONFIG and config.ini are reachable before registering the server with an AI assistant. Combine with --check-host rt1 to also confirm that credentials actually authenticate against a real device.
Tag-based host filtering
run_show_command_batch, collect_rsi_batch, and get_router_list accept an optional tags argument. The grammar matches the junos-ops --tags CLI flag (since junos-mcp 0.9.0 / junos-ops 0.16.6):
Each list element is one tag group. Comma-separated tags inside a group AND together.
Multiple list elements OR together across groups.
When combined with
hostnameson batch tools, the result is the intersection (tags filter further narrowed by names). An empty intersection returns an error.
# 1 group, 1 tag — hosts tagged "main"
run_show_command_batch(command="show route summary", tags=["main"])
# 1 group, 2 tags — AND within the group: tokyo AND edge
collect_rsi_batch(tags=["tokyo,edge"])
# 2 groups — OR across groups: main OR backup
get_router_list(tags=["main", "backup"])
# Mixed: (tokyo AND core) OR backup
run_show_command_batch(command="show version", tags=["tokyo,core", "backup"])
# Intersection: among backup-tagged hosts, only rt1/rt2
run_show_command_batch(
command="show version",
hostnames=["rt1.example.jp", "rt2.example.jp"],
tags=["backup"],
)See the junos-ops tag documentation for how to tag sections in config.ini and for the matching CLI grammar.
Structured output format
run_show_command and run_show_commands accept an optional output_format parameter:
Value | Description |
| Default. Plain-text CLI output (same as typing the command) |
| NETCONF JSON output — device returns a structured dict |
| NETCONF XML output — device returns pretty-printed XML |
Note: CLI pipe stages (| match, | last, | count, etc.) are silently dropped
regardless of output_format. PyEZ's Device.cli() sends the command over NETCONF
RPC, which JunOS does not pipe-process. Run the command without pipes and filter
client-side instead. For a single command, run_show_command_batch's grep_pattern
argument (see below) offers server-side-style filtering — even against a single
host, by passing a one-element hostnames list — but it always fetches plain-text
output internally (it cannot be combined with output_format="json"/"xml"), and
it only accepts one command at a time, so it isn't a drop-in workaround for
run_show_commands' multi-command case.
# Get structured BGP summary data
run_show_command("router-a", "show bgp summary", output_format="json")Server-side output filtering
run_show_command_batch accepts an optional grep_pattern argument (Python re pattern). When set, only lines matching the pattern are kept from each host's output. Header lines (starting with #) are always preserved. Hosts with no matching lines show (no match).
This reduces large batch results — for example, 93 routers × show route summary — from hundreds of KB to a few hundred bytes by extracting just the relevant lines:
# Extract only the inet.0 destination count from 93 routers
run_show_command_batch(
command="show route summary",
tags=["main"],
grep_pattern=r"inet\.0:\s+\d+ destinations",
)Connection pool
junos-mcp maintains a per-host NETCONF connection pool. Reusing an idle
Device avoids the TCP/NETCONF handshake on every tool call; the pool
serialises concurrent operations on the same host through a per-host lock.
Environment variable | Default | Description |
|
| Set to |
|
| Idle timeout in seconds. Connections unused longer than this are closed on the next call. Set to |
Security note: pooled connections are long-lived SSH sessions. In
environments where session duration is restricted by policy, set
JUNOS_MCP_POOL_IDLE to a value shorter than the inactivity limit, or set
JUNOS_MCP_POOL=0 to disable the pool entirely.
Configuration
This server uses the same config.ini as junos-ops. See junos-ops README for details.
Each tool accepts an optional config_path parameter. If omitted, the default search order is used:
Environment variable
JUNOS_OPS_CONFIG./config.ini~/.config/junos-ops/config.ini
config.ini is not optional in practice: every tool — including get_router_list and health_check, which never open a device connection — reads from it at startup, and there is no degrade-gracefully path if it can't be found. Put a working config.ini in one of the three locations above before registering the server with any MCP client.
Write operations
Five tools change device state. Everything else only reads. These are the same five that default to dry_run=True — see Safety by Design for the dry-run and commit-confirmed mechanics; this table is about what each one calls and the device-side privilege that gates it.
Tool | API call | Permission gate |
|
| The |
|
| Same account needs file-copy / storage-write access (SCP to device flash). |
|
| Requires software-installation privilege — JUNOS |
|
| Same elevated software-maintenance privilege as |
| Schedules | Requires reboot/maintenance privilege on the device. |
Provision the config.ini account for a host with a read-only/operator login class and these five tools fail against that host with a permission error; every other tool — show commands, config reads, diagnostics, daily_brief — keeps working. There is no separate plugin-level switch for this: the privilege boundary is entirely in the JUNOS login class assigned to the account in config.ini.
Usage
Claude Code (plugin)
This repository doubles as a single-plugin marketplace, so Claude Code can install the server for you:
/plugin marketplace add shigechika/junos-mcp
/plugin install junos-mcp@junos-mcpThe plugin launches uvx junos-mcp and reads the same environment variables described in Configuration; export JUNOS_OPS_CONFIG (or drop config.ini at ./config.ini or ~/.config/junos-ops/config.ini) before starting Claude Code.
uvx must be on the PATH of the process that runs Claude Code — a login
shell usually has it, but a GUI-launched app may not; install
uv system-wide if the plugin fails to start.
Claude Code (manual)
Register the MCP server with claude mcp add:
claude mcp add junos-mcp \
-e JUNOS_OPS_CONFIG=~/.config/junos-ops/config.ini \
-- python -m junos_mcpThe --scope (-s) option controls where the configuration is stored:
Scope | Description | Config location |
| Current project, current user only |
|
| Current project, shared with team |
|
| All projects, current user only |
|
Claude Desktop
Add to Claude Desktop config file:
OS | Config file |
macOS |
|
Windows |
|
Linux |
|
{
"mcpServers": {
"junos-mcp": {
"command": "python",
"args": ["-m", "junos_mcp"],
"env": {
"JUNOS_OPS_CONFIG": "/path/to/config.ini"
}
}
}
}Restart Claude Desktop after editing.
Codex
Register the MCP server with codex mcp add:
codex mcp add junos-mcp \
--env JUNOS_OPS_CONFIG=~/.config/junos-ops/config.ini \
-- python -m junos_mcpAny other MCP client that launches stdio servers works the same way: give it python -m junos_mcp as the command and set JUNOS_OPS_CONFIG in its environment.
Remote Access with OAuth (via mcp-stdio)
junos-mcp supports Streamable HTTP transport, enabling remote access from any MCP client (Claude Desktop, Claude Code, Codex, …) through mcp-stdio as an OAuth proxy.
graph TB
A[junos-mcp<br/>remote server] <-- "OAuth 2.1 + HTTPS" --> B[mcp-stdio<br/>proxy]
B <-- "STDIO" --> C[MCP client<br/>Claude / Codex / …]Step 1: Start junos-mcp with Streamable HTTP on the remote server
JUNOS_OPS_CONFIG=~/.config/junos-ops/config.ini \
python -m junos_mcp --transport streamable-httpThe server listens on http://localhost:8000/mcp by default.
Step 2: Register mcp-stdio as the MCP server on your local machine
# Claude Code
claude mcp add junos-mcp -- mcp-stdio https://your-server:8000/mcp
# Codex
codex mcp add junos-mcp -- mcp-stdio https://your-server:8000/mcpmcp-stdio handles OAuth 2.1 authentication (RFC 8414 discovery, RFC 7591 dynamic client registration, PKCE) and relays STDIO ↔ Streamable HTTP.
See mcp-stdio README for detailed configuration including OAuth provider setup.
When junos-mcp is launched by
mcp-stdio serve(the gateway mode) and runs on MCP SDK 2.x, use mcp-stdio 0.43.7 or later. Older gateways forward a request envelope that a 2.x server rejects; on those, install withmcp<2.
MCP Inspector (development)
mcp dev junos_mcp/server.pyTesting
pytest tests/ -v133 tests covering all 23 tools, the connection pool, helper functions, and edge cases.
Live smoke test
Those tests mock PyEZ, which is what makes them fast — and also what makes them
blind to a tool that has stopped returning real data.
scripts/smoke_test.py runs every registered tool against the configured
devices and fails on empty, malformed or error answers:
# uses the same inventory file as the server (JUNOS_OPS_CONFIG)
uv run python scripts/smoke_test.py
uv run python scripts/smoke_test.py --only facts --tracebackRead-only.
push_config,push_config_start,copy_package,install_package,rollback_packageandschedule_rebootare skipped by name, and a test enforces that.collect_rsi/collect_rsi_batchare skipped too — they change nothing, but they are minutes of RE CPU and a file per device for an answer no assertion would read. The command-running tools are exercised withshow system uptime: they accept operational commands in general, and a smoke test must not be the thing that types one that matters.No payloads in the report. Tool names and statuses only; error text is redacted too, since these tools quote the device they were asked about and the payloads are configuration.
Nothing estate-specific in the specs. The device the per-host tools need is discovered at run time from the configured inventory, and the hardware model
get_package_infoneeds comes from that device's own facts. Two tests keep it that way: one refuses those parameters as literals, the other bans anything address-shaped anywhere in the file, because this repository is public.Every probe refuses the
Error: .../Connection error: ...lines these tools return in place of raising — otherwise an unreachable device would read as a successful call.CI enforces the cheap half: a tool registered without a probe spec fails the build (
tests/test_smoke_probes.py), so adding a tool forces the question "how would we know it works?".scripts/smoke_harness.pyis the engine and holds no JUNOS knowledge: it is kept identical across the servers that share it, so fix engine bugs once and sync the file rather than patching this copy.
Architecture
Stdout-safe by construction
Since junos-ops 0.14.1, core functions return structured dict values and never print to stdout; MCP tools render output via junos_ops.display.format_*(). No contextlib.redirect_stdout is needed, so the MCP STDIO JSON-RPC channel stays clean.
Global State Initialization
junos-ops uses common.args and common.config as global variables. The MCP server initializes these using the same pattern as the test fixtures in junos-ops (conftest.py).
Parallel Execution
Batch tools (run_show_command_batch, collect_rsi_batch) use ThreadPoolExecutor via junos-ops common.run_parallel() with configurable max_workers.
License
Apache License 2.0
Available Tools
28 toolscheck_local_inventoryA
Verify local firmware checksums against the config.ini inventory.
Equivalent to junos-ops check --local. Iterates every
<model>.file / <model>.hash pair in the DEFAULT section of
config.ini and verifies the file on the staging server. No
device connection required.
Args: model: Restrict to a single model (empty = all configured models) config_path: Path to config.ini (empty string uses default search)
Inputs: model, config_path. Returns: result
check_reachabilityA
Probe NETCONF reachability for one or more devices.
Equivalent to junos-ops check --connect. Opens a fast NETCONF
handshake (no full PyEZ facts gathering, 5-second TCP probe) and
reports per-host status as a table.
Args:
hostnames: List of target device hostnames (must exist in config.ini)
tags: Tag filter. Each list element is one tag group (comma-separated
tags AND together within a group); multiple list elements OR
together across groups. Combined with hostnames the result is
the intersection.
max_workers: Maximum parallel threads (default 20, matches junos-ops)
config_path: Path to config.ini (empty string uses default search)
Inputs: tags, hostnames, config_path, max_workers. Returns: result
check_remote_packagesA
Verify the staged firmware checksum on one or more devices.
Equivalent to junos-ops check --remote. Connects to each device
via NETCONF and verifies the package file (<model>.file) sitting
on the device against <model>.hash. Doubles as post-SCP copy
verification. Per-host model resolution: model arg > config.ini
[host].model > device facts.
Args:
hostnames: List of target device hostnames (must exist in config.ini)
tags: Tag filter. Each list element is one tag group (comma-separated
tags AND together within a group); multiple list elements OR
together across groups. Combined with hostnames the result is
the intersection.
model: Override model resolution for all hosts (empty = per-host resolution)
max_workers: Maximum parallel threads (default 20)
config_path: Path to config.ini (empty string uses default search)
Inputs: tags, model, hostnames, config_path, +1 more. Returns: result
check_upgrade_readinessB
Check if a device is ready for upgrade.
Verifies whether the device is already running the target version, and performs a dry-run to check local/remote package availability.
Args: hostname: Target device hostname (must exist in config.ini) config_path: Path to config.ini (empty string uses default search)
Inputs: hostname (required), config_path. Returns: result
collect_rsiA
Collect RSI (Request Support Information) and SCF (Show Configuration) from a device.
Saves two files: {hostname}.SCF (show configuration) and {hostname}.RSI (request support information). Model-specific timeouts are applied automatically (e.g., SRX Branch: 1200s, Virtual Chassis: 1800s).
Args: hostname: Target device hostname (must exist in config.ini) output_dir: Directory to save output files (empty uses config RSI_DIR or current dir) config_path: Path to config.ini (empty string uses default search)
Inputs: hostname (required), output_dir, config_path. Returns: result
collect_rsi_batchA
Collect RSI/SCF from multiple devices in parallel.
Uses ThreadPoolExecutor for concurrent collection. Default 20 workers
matches junos-ops CLI default for RSI collection. Either hostnames
or tags selects the targets; if both are omitted, every router in
config.ini is targeted. When both are given, the intersection is used.
Args:
hostnames: List of target device hostnames
tags: Tag filter. Each list element is one tag group (comma-separated
tags AND together within a group); multiple list elements OR
together across groups. Combined with hostnames the result is
the intersection.
output_dir: Directory to save output files (empty uses config RSI_DIR or current dir)
max_workers: Maximum parallel threads (default 20)
config_path: Path to config.ini (empty string uses default search)
Inputs: tags, hostnames, output_dir, config_path, +1 more. Returns: result
compare_versionA
Compare two JUNOS version strings.
Returns whether left is greater than, equal to, or less than right. No device connection required.
Args: left: First JUNOS version string (e.g., "22.4R3-S6.5") right: Second JUNOS version string (e.g., "23.2R1.0")
Inputs: left (required), right (required). Returns: result
copy_packageA
Copy firmware package to remote device via SCP with checksum verification.
Checks if copy is needed (already running target version, or package already present on device). Cleans up storage before copying.
Args: hostname: Target device hostname (must exist in config.ini) dry_run: If True (default), show what would be done without copying force: If True, skip version checks and force copy config_path: Path to config.ini (empty string uses default search)
Inputs: hostname (required), force, dry_run, config_path. Returns: result
daily_briefA
Run a morning health check across multiple devices in parallel.
Checks per host (Phase 1):
show system alarms/show chassis alarmsshow interfaces descriptions— a physical interface is flagged[IF_DOWN]only when it has a description (Admin=up,Link=down) and itsLast flappedtime is withinsince_hours. Undescribed unused ports and chronically-down ports are suppressed (loopback / mgmt / internal logical units are also excluded).show log messages | last 200— alert patterns withinsince_hoursdual-RE redundancy — an explicit routing-engine fault is flagged
[RE_FAULT](skipped on SRX chassis clusters, whose facts misreport RE status; a failed cluster node raises chassis alarms instead)route_baseline(optional) — when > 0, a device whoseinet.0destination count differs from this value is flagged[ROUTE_BASELINE]. Scope withtags(e.g.tags=["main"], route_baseline=152), since full-table routers carry far more routes than access routers.
Syslog patterns watched: BGP state change away from Established, STP port role change, OSPF neighbor down, ARP address conflict, IF_DOWN.
since_hours defaults to 18 (≈ previous 15:00 for a 09:00 morning run).
Tags default to none (all routers); pass tags=["main"] to limit scope.
Output tiers:
CRITICAL — connection failure
WARNING — at least one anomaly found
OK — clean
Returns a Markdown summary with anomaly details for CRITICAL/WARNING hosts and a collapsed OK list.
The call stops after JUNOS_DEADLINE seconds (default 45; 0 disables) so a
large fleet does not run into a client's per-call timeout: hosts that have not
finished are listed under NOT CHECKED and the summary is marked partial.
For a full sweep of a large fleet use daily_brief_start / daily_brief_result.
Inputs: tags, hostnames, config_path, max_workers, +2 more. Returns: result
daily_brief_resultA
Fetch a daily_brief_start job by id.
status is running (keep polling), done (result holds the brief), error
(error holds the exception type name only) or unknown (bad or expired id).
Inputs: job_id (required).
daily_brief_startA
Start a daily_brief in the background; returns immediately with a job_id.
Use this for a fleet too large for one synchronous daily_brief (a client's per-call
timeout is about 60 s). Arguments mirror daily_brief. Poll daily_brief_result(job_id)
every few seconds until status is done (the full brief is under result, with no
deadline) or error. If too many jobs are retained, returns {"status": "rejected", ...}.
While a job is running, a call that would switch to a different config file is
refused (the config is process-global); use the same config_path or none.
Args:
hostnames: Only these hosts (must exist in config.ini). Default: all hosts.
tags: Tag filter. Each element is one group: a comma inside an element means
the host must have ALL of those tags ("main,core"); several elements
are ORed (["main", "core"] = hosts tagged main OR core). Case-insensitive.
With hostnames too, the result is the intersection of the two.
since_hours: Look-back window for syslog/interface events (default 18).
route_baseline: When > 0, flag a device whose inet.0 route count differs.
max_workers: Devices checked in parallel (default 10).
config_path: Path to config.ini (empty uses the default search).
Inputs: tags, hostnames, config_path, max_workers, +2 more.
get_configB
Get device configuration.
Args: hostname: Target device hostname (must exist in config.ini) output_format: Output format - "text" (default), "set", or "xml" config_path: Path to config.ini (empty string uses default search)
Inputs: hostname (required), config_path, output_format. Returns: result
get_config_diffA
Show configuration difference compared to a rollback version.
Args: hostname: Target device hostname (must exist in config.ini) rollback_id: Rollback version to compare against (0-49, default 1) config_path: Path to config.ini (empty string uses default search)
Inputs: hostname (required), config_path, rollback_id. Returns: result
get_device_factsA
Get basic device information (model, hostname, serial, version, etc.).
Args: hostname: Target device hostname (must exist in config.ini) config_path: Path to config.ini (empty string uses default search)
Inputs: hostname (required), config_path. Returns: result
get_package_infoA
Get package file name and expected hash for a specific device model.
Retrieves model-specific package information from config.ini. No device connection required.
Args: hostname: Target device hostname (must exist in config.ini) model: Device model name (e.g., "EX2300-24T") config_path: Path to config.ini (empty string uses default search)
Inputs: model (required), hostname (required), config_path. Returns: result
get_router_listA
List routers defined in config.ini, optionally filtered by tags.
Returns section names from config.ini, which represent the hostnames that can be used with other tools. No device connection required.
Args:
tags: Tag filter. Each list element is one tag group (comma-separated
tags AND together within a group); multiple list elements OR
together across groups. E.g. ["tokyo,core", "backup"] means
(tokyo AND core) OR backup. None/empty returns all.
config_path: Path to config.ini (empty string uses default search)
Inputs: tags, config_path. Returns: result
get_versionA
Get JUNOS version information with upgrade status.
Shows running version, planning version, pending version, local/remote package status, and reboot schedule.
Args: hostname: Target device hostname (must exist in config.ini) config_path: Path to config.ini (empty string uses default search)
Inputs: hostname (required), config_path. Returns: result
health_checkA
Report server version and config status — without connecting to any device.
Call this at session start (or after a tool-call timeout) to confirm the MCP is up, see which version is running, and verify that config.ini loads and how many routers it defines. Lightweight by design: junos-mcp fans out to many Juniper devices, so this check ONLY loads config.ini and counts hosts — it opens NO NETCONF/SSH connection to any device.
Always returns the same keys: status (healthy / error),
service, version, config_path (the resolved config.ini path it
would use), router_count (number of host sections in config.ini),
tags (sorted list of distinct tags across configured hosts), and
config (ok / error / missing). On an error result, detail carries
the reason. There is no degraded state: this check either loads config.ini
or it does not.
Args: config_path: Path to config.ini (empty string uses default search).
Inputs: config_path.
install_packageA
Install firmware package on device with pre-flight checks.
Full upgrade flow: version check -> rollback pending if needed -> copy (with checksum) -> clear reboot schedule -> rescue config save -> request system software add (with validation).
Args:
hostname: Target device hostname (must exist in config.ini)
dry_run: If True (default), show what would be done without installing
force: If True, skip version checks and force install
unlink: If True, run request system software add <pkg> unlink
via CLI instead of PyEZ SW.install(). Use for low-flash devices
(EX2300 / EX3400, ~1.3 GB /dev/gpt/junos) where major version
upgrades fail with "ERROR: insufficient space" because PyEZ does
not expose the unlink parameter. The CLI path frees ~330 MB by
unlinking the source tgz during extraction.
config_path: Path to config.ini (empty string uses default search)
Inputs: hostname (required), force, unlink, dry_run, +1 more. Returns: result
list_remote_filesA
List files on the remote device path (/var/tmp by default).
Args: hostname: Target device hostname (must exist in config.ini) config_path: Path to config.ini (empty string uses default search)
Inputs: hostname (required), config_path. Returns: result
push_configA
Push configuration to a device with commit confirmed and health check.
Supports two input methods (exactly one required):
config_file: Path to a .set or .j2 file containing set commands
set_commands: List of set command strings (inline)
Safety features (not available in Juniper's official MCP server):
dry_run mode (default True): shows diff without committing
commit confirmed: auto-rollback if not confirmed within timeout
health check: auto-rollback on connectivity failure after commit
Commit flow (normal): lock -> load -> diff -> commit_check -> commit confirmed -> health check -> confirm -> unlock
Commit flow (no_commit=True — intentional auto-rollback): lock -> load -> diff -> commit_check -> commit confirmed -> unlock (health check and final confirm are skipped; JUNOS rolls back automatically after confirm_timeout minutes)
RPC timeout: every step uses timeout from config.ini for the host, else
the model default from junos-ops (180 s on SRX branch models such as
SRX300/320/340/345, whose commits can exceed 30 s; 120 s otherwise). It is
never shortened.
Per-call deadline: with JUNOS_DEADLINE set (default 45 s; 0 disables)
the push runs as a background job and this call waits for it until shortly
before the deadline. If it finishes, the answer is the same as without a
deadline. If not, the answer says "Still running" with a job_id: poll
push_config_result(job_id) for the outcome (the device-side commit
confirmed protects a push whose caller went away). For hosted clients that
cut a tool call at about 60 s and for slow-committing models,
push_config_start returns the diff and the job id without waiting.
Only one push per host runs at a time; a second one is refused. While a push holds a host, other tools on that host wait at most until the deadline and then answer "host busy".
Args:
hostname: Target device hostname (must exist in config.ini)
config_file: Path to .set or .j2 file (mutually exclusive with set_commands)
set_commands: List of set commands (mutually exclusive with config_file)
dry_run: If True (default), show diff only without committing
confirm_timeout: Minutes before auto-rollback (default 1, used with commit confirmed)
no_commit: If True, issue commit confirmed but intentionally skip the final
commit so JUNOS auto-rolls back after confirm_timeout minutes. Useful
for triggering service restarts (e.g. syslog on EX3400) where no
request ...restart command exists. dry_run=True takes precedence
over no_commit (diff is shown but nothing is committed).
health_check: Fallback health check commands tried in order after commit.
Passes if ANY command succeeds. Supports "ping ..." (checks packets received),
"uptime" (NETCONF RPC probe), or any CLI command (success if no exception).
Default: ["uptime"] — uses the existing NETCONF session and does not
depend on ICMP reachability. (Changed from broadcast ping in junos-mcp
0.11.0 to match junos-ops 0.16.8+.)
Ignored when no_commit=True.
config_path: Path to config.ini (empty string uses default search)
Inputs: hostname (required), dry_run, no_commit, config_file, +4 more. Returns: result
push_config_resultA
Fetch a push_config_start (or deadline-bound push_config) job by id.
status is running (keep polling; diff is present once computed),
done (result holds the same text push_config returns: committed
and permanent, no changes, or the intentional no_commit rollback),
dry_run (result holds the diff; nothing committed), failed
(result says why: lock/load error, failed health check, or a commit
confirmed that is or may be pending and rolls back after confirm_timeout
minutes), error (error holds the exception type name only; any
unconfirmed commit rolls back after confirm_timeout minutes) or unknown
(bad or expired id; finished jobs are kept for 10 minutes).
Inputs: job_id (required).
push_config_startA
Start push_config as a background job and return its diff and job_id without waiting for the commit.
Use this instead of push_config when the client cuts a tool call at about
60 s (hosted connectors) or the device commits slowly (SRX branch models such
as SRX300/320/340/345), or when push_config answered "Still running". The
job uses the host's full RPC timeout (timeout in config.ini, else 180 s on
SRX branch models and 120 s otherwise) and no per-call deadline. Arguments
and the commit flow are the same as push_config.
The job locks the candidate configuration, loads the change and computes the
diff, and this call returns that diff (diff). The same locked session then
goes on to commit_check -> commit confirmed -> health check -> confirm ->
unlock, so the committed change is exactly the diff returned. Poll
push_config_result(job_id) every ~10 s until status is not
running. If the server dies mid-way, an unconfirmed commit confirmed
rolls back on the device after confirm_timeout minutes.
With dry_run=True (default) nothing is committed: the answer has
status dry_run and the diff under result once the job finishes.
Returns {"job_id", "status", "hostname", "diff"?, "result"?, "poll_with": "push_config_result", "poll_after_seconds"}. status may
already be final (done with "No changes to apply", failed for a lock
or load error). A refusal returns {"status": "rejected", "error"} (a push
to this host is already in progress, too many retained jobs, or a config
switch while a job runs).
Args: hostname: Target device hostname (must exist in config.ini) config_file: Path to .set or .j2 file (mutually exclusive with set_commands) set_commands: List of set commands (mutually exclusive with config_file) dry_run: If True (default), return the diff only; nothing is committed confirm_timeout: Minutes before auto-rollback (default 1) no_commit: Commit confirmed only, then let JUNOS roll back (see push_config) health_check: Health check commands after commit (see push_config; default ["uptime"]) config_path: Path to config.ini (empty string uses default search)
Inputs: hostname (required), dry_run, no_commit, config_file, +4 more.
rollback_packageA
Rollback to previously installed package version.
Checks pending version first. If no pending version exists, rollback is skipped.
Args: hostname: Target device hostname (must exist in config.ini) dry_run: If True (default), show what would be done without rolling back config_path: Path to config.ini (empty string uses default search)
Inputs: hostname (required), dry_run, config_path. Returns: result
run_show_commandA
Run a CLI show command on the device and return output.
Args: hostname: Target device hostname (must exist in config.ini) command: CLI command to execute (e.g., "show bgp summary") output_format: Output format — "text" (default), "json", or "xml". Note: pipe stages (| match, | last, | count, etc.) are silently dropped regardless of output_format — PyEZ's Device.cli() sends the command over NETCONF RPC, which JunOS does not pipe-process. Run the command without pipes; for line filtering, use run_show_command_batch's grep_pattern argument instead (works for a single host too — pass a one-element hostnames list). That workaround always fetches text output internally, so it cannot be combined with output_format="json"/"xml" — for structured output you must filter the result client-side instead. config_path: Path to config.ini (empty string uses default search)
Inputs: command (required), hostname (required), config_path, output_format. Returns: result
run_show_command_batchA
Run a CLI show command on multiple devices in parallel.
Uses ThreadPoolExecutor for concurrent execution. Either hostnames
or tags selects the targets; if both are omitted, every router in
config.ini is targeted. When both are given, the intersection is used.
Args:
command: CLI command to execute on all devices
hostnames: List of target device hostnames (must exist in config.ini)
tags: Tag filter. Each list element is one tag group (comma-separated
tags AND together within a group). Multiple list elements OR
together across groups. E.g. ["tokyo,core", "backup"] means
(tokyo AND core) OR backup. Combined with hostnames the
result is the intersection.
grep_pattern: Optional Python re pattern. When set, only lines
matching the pattern (via re.search) are kept from each
host's output. Header lines (starting with #) are always
preserved. Hosts with no matching lines show (no match).
Reduces large batch outputs to the essential lines. This tool
always fetches text output internally (there is no
output_format parameter here) — grep_pattern filters
plain-text lines and cannot be combined with structured
JSON/XML output.
max_workers: Maximum parallel threads (default 5)
config_path: Path to config.ini (empty string uses default search)
Inputs: command (required), tags, hostnames, config_path, +2 more. Returns: result
run_show_commandsA
Run multiple CLI show commands on the device in a single session.
Commands are executed in sequence and stop on the first failure. To run all commands regardless of individual errors, call run_show_command once per command instead.
Args: hostname: Target device hostname (must exist in config.ini) commands: List of CLI commands to execute output_format: Output format — "text" (default), "json", or "xml". Note: pipe stages (| match, | last, | count, etc.) are silently dropped regardless of output_format — PyEZ's Device.cli() sends the command over NETCONF RPC, which JunOS does not pipe-process. Run commands without pipes and filter client-side. run_show_command_batch's grep_pattern argument offers server-side-style filtering, but it only accepts one command at a time — it does not cover this tool's multi-command case, so it is not a drop-in workaround here. config_path: Path to config.ini (empty string uses default search)
Inputs: commands (required), hostname (required), config_path, output_format. Returns: result
schedule_rebootA
Schedule device reboot at a specified time.
Checks for existing reboot schedules. If one exists and force is False, the existing schedule is preserved.
Args: hostname: Target device hostname (must exist in config.ini) reboot_at: Reboot time in YYMMDDHHMM format (e.g., "2601020304" = 2026-01-02 03:04) dry_run: If True (default), show what would be done without scheduling force: If True, clear existing reboot schedule and set new one config_path: Path to config.ini (empty string uses default search)
Inputs: hostname (required), reboot_at (required), force, dry_run, +1 more. Returns: result
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
TDQS
Scored across 28 tools
Most tools have clearly distinct purposes, and the descriptions carefully explain the sync/async split for push_config, daily_brief, and their _start/_result partners. The main hazard is the run_show_command / run_show_commands / run_show_command_batch trio, where a singular 's' distinguishes 'one command' from 'multiple commands on one host' vs 'one command on many hosts' — easy to misselect without reading descriptions. check_reachability vs health_check is also mildly confusable but documented.
Almost everything follows a snake_case verb_noun pattern (get_*, run_*, check_*, collect_*, copy/install/rollback_package, push_config_*, *_start/*_result). A few names drop the verb (daily_brief, health_check) and the singular/plural run_show_command(s) deviation is awkward, but conventions are otherwise predictable.
28 tools is on the heavy side, though the surface genuinely spans config push, show execution, firmware lifecycle, RSI collection, and fleet monitoring. The async/sync pairs (push_config*, daily_brief*) are justified by real client timeouts, but some consolidation and the near-duplicate show-command variants push this into 'heavy' territory.
Strong lifecycle coverage: config read/diff/push with commit-confirmed safety, firmware copy/install/rollback, reboot scheduling, RSI collection, and health monitoring with a job model. Gaps are minor — no explicit configuration rollback (only diff against a rollback_id) and no remote file upload/delete beyond package copy, but core workflows are covered.
Maintenance
Related MCP Connectors
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
Cloud-hosted MCP server for secure AI access to enterprise data sources via CData Connect AI.
Hosted MCP server connecting AI assistants to 9,000+ apps and 40,000+ actions via Zapier.
An MCP server that provides an API to LLMs to manage their JumpCloud resources.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceMCP server for network operations that lets AI assistants interact with Cisco/Juniper network devices through safe, well-defined tools like compliance audits and configuration backups.MIT
- AlicenseAqualityDmaintenanceMCP server for managing Juniper Mist networks with AI assistants. Monitor, troubleshoot, and configure customer networks through natural language.1058 PyPIApache 2.0
- AlicenseAqualityDmaintenanceA comprehensive MCP server for network device management via SSH/Telnet. Supports multiple vendors such as Cisco IOS and BDCOM, enabling AI assistants to execute commands and manage routers, switches, and firewalls.4MIT
- AlicenseNot gradedqualityDmaintenanceMCP server that enables AI assistants to manage SSH terminal sessions, execute commands, and automate server operations through natural language, with multi-tab support and session persistence.MIT