Skip to main content
Glama
io.github.shigechika/junos-mcp

io.github.shigechika/junos-mcp

by shigechika

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_device_facts

Get basic device information (model, hostname, serial, version)

Yes

get_version

Get JUNOS version with upgrade status

Yes

get_router_list

List routers from config.ini (optionally filtered by tags)

No

health_check

Report server version + config status (router count, distinct tags). Lightweight; does NOT connect to any device

No

CLI Command Execution

Tool

Description

Connection

run_show_command

Run a single CLI show command (output_format: text/json/xml)

Yes

run_show_commands

Run multiple CLI commands in a single session (output_format: text/json/xml)

Yes

run_show_command_batch

Run a command on multiple devices in parallel (supports tag filter and grep_pattern)

Yes

Configuration Management

Tool

Description

Connection

get_config

Get device configuration (text/set/xml format)

Yes

get_config_diff

Show config diff against a rollback version

Yes

push_config

Push config with commit confirmed + health check

Yes

push_config_start / push_config_result

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): push_config_start returns the diff and a job_id without waiting for the commit, which runs on the same locked session; poll push_config_result until it is no longer running

Yes

Upgrade Operations

Tool

Description

Connection

check_upgrade_readiness

Check if device is ready for upgrade

Yes

compare_version

Compare two JUNOS version strings

No

get_package_info

Get model-specific package file and hash

No

list_remote_files

List files on remote device path

Yes

copy_package

Copy firmware package via SCP with checksum

Yes

install_package

Install firmware with pre-flight checks (unlink flag for EX2300/EX3400)

Yes

rollback_package

Rollback to previous package version

Yes

schedule_reboot

Schedule device reboot at specified time

Yes

Diagnostics

Tool

Description

Connection

collect_rsi

Collect RSI/SCF with model-specific timeouts

Yes

collect_rsi_batch

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

check_reachability

Probe NETCONF reachability + available disk space per host (fast: no facts, 5s TCP probe)

Yes

check_local_inventory

Verify local firmware checksums against config.ini inventory

No

check_remote_packages

Verify staged firmware checksum + available disk space on devices (post-SCP verification)

Yes

Daily Operations

Tool

Description

Connection

daily_brief

Morning health check across multiple devices in parallel — alarms, interface up/down, syslog alert patterns within a look-back window (since_hours, default 18 h), dual-RE faults ([RE_FAULT]; skipped on SRX chassis clusters, whose facts misreport RE status — a failed cluster node surfaces via chassis alarms instead), and an optional inet.0 route-count baseline (route_baseline, e.g. tags=["main"], route_baseline=152). Returns a CRITICAL/WARNING/OK Markdown summary.

Yes

daily_brief_start / daily_brief_result

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): daily_brief_start returns a job_id at once, poll daily_brief_result until done. The synchronous daily_brief now stops after JUNOS_DEADLINE seconds (default 45; 0 disables) and lists unfinished hosts under NOT CHECKED.

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 — issues commit confirmed but intentionally skips the final commit. JUNOS auto-rolls back after confirm_timeout minutes. Useful for restarting services that lack a request ...restart command (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

Installation

pip install junos-mcp

Or 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 --help

Option

Description

-V, --version

Print version and exit

--check

Load config.ini, list routers, and exit (exit code 1 on error)

--check-host HOSTNAME

With --check, also open a NETCONF session to verify reachability/auth

--transport {stdio,streamable-http}

Transport protocol (default: stdio)

--host HOST / --port PORT

streamable-http only: address and port to listen on (default: 127.0.0.1 / 8000). Use these rather than FASTMCP_HOST / FASTMCP_PORT, which MCP Python SDK 2.x no longer reads

--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 hostnames on 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

"text"

Default. Plain-text CLI output (same as typing the command)

"json"

NETCONF JSON output — device returns a structured dict

"xml"

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

JUNOS_MCP_POOL

1 (enabled)

Set to 0 to disable the pool and open a fresh connection per call

JUNOS_MCP_POOL_IDLE

60

Idle timeout in seconds. Connections unused longer than this are closed on the next call. Set to 0 to disable eviction

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:

  1. Environment variable JUNOS_OPS_CONFIG

  2. ./config.ini

  3. ~/.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

push_config (and its background form push_config_start)

jnpr.junos.utils.config.Config: lock → load(format="set") → diff → commit_check → commit(confirm=confirm_timeout) → health check → final commit → unlock

The config.ini account for the target host needs a JUNOS login class permitting configuration mode and commit — not a read-only/operator class. The exact class name is whatever was provisioned per device in config.ini.

copy_package

junos_ops.upgrade.copy() — SCPs the firmware package to the device with checksum verification and pre-copy storage cleanup

Same account needs file-copy / storage-write access (SCP to device flash).

install_package

junos_ops.upgrade.install() — version check, pending-rollback check, copy + checksum, clear reboot schedule, rescue-config save, then PyEZ SW.install() (or request system software add via the unlink CLI path on low-flash EX2300/EX3400)

Requires software-installation privilege — JUNOS maintenance-class or superuser login class.

rollback_package

junos_ops.upgrade.rollback() — equivalent of request system software rollback, only after confirming a pending version exists

Same elevated software-maintenance privilege as install_package.

schedule_reboot

Schedules request system reboot at <time>

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-mcp

The 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_mcp

The --scope (-s) option controls where the configuration is stored:

Scope

Description

Config location

local (default)

Current project, current user only

~/.claude.json

project

Current project, shared with team

.mcp.json in project root

user

All projects, current user only

~/.claude.json

Claude Desktop

Add to Claude Desktop config file:

OS

Config file

macOS

~/Library/Application Support/Claude/claude_desktop_config.json

Windows

%APPDATA%\Claude\claude_desktop_config.json

Linux

~/.config/Claude/claude_desktop_config.json

{
  "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_mcp

Any 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-http

The 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/mcp

mcp-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 with mcp<2.

MCP Inspector (development)

mcp dev junos_mcp/server.py

Testing

pytest tests/ -v

133 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 --traceback
  • Read-only. push_config, push_config_start, copy_package, install_package, rollback_package and schedule_reboot are skipped by name, and a test enforces that. collect_rsi / collect_rsi_batch are 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 with show 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_info needs 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.py is 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 tools
check_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 alarms

  • show interfaces descriptions — a physical interface is flagged [IF_DOWN] only when it has a description (Admin=up, Link=down) and its Last flapped time is within since_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 within since_hours

  • dual-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 whose inet.0 destination count differs from this value is flagged [ROUTE_BASELINE]. Scope with tags (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

    A3.8/5.0

    Scored across 28 tools

    Disambiguation4/5

    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.

    Naming Consistency4/5

    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.

    Tool Count3/5

    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.

    Completeness4/5

    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

    ActivityNo data
    ResponsivenessOutdated data

    Related MCP Connectors

    Related MCP Servers

    • A
      license
      Not graded
      quality
      D
      maintenance
      MCP 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
    • A
      license
      A
      quality
      D
      maintenance
      A 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.
      4
      MIT
    • A
      license
      Not graded
      quality
      D
      maintenance
      MCP 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