rustjunosmcp

<p align="center">
  <picture>
    <source media="(prefers-color-scheme: dark)" srcset="docs/assets/mechub-mark.svg">
    <img src="docs/assets/mechub-mark-light.svg" width="72" alt="mechub mark">
  </picture>
</p>

<h1 align="center">rust-junosmcp</h1>

<p align="center"><strong>One MCP server for Juniper Junos and SRX devices, in Rust</strong><br>
<em>a mechub project — sovereign network-security automation</em></p>

> **Unofficial / community project.** This repository is an independent, community-driven project. It is not affiliated with, endorsed by, sponsored by, or supported by Hewlett Packard Enterprise or Juniper Networks. "HPE", "Juniper", "SRX", "JUNOS", "Security Director" and "Juniper Mist" are trademarks of their respective owners and are used here only to describe what this software interoperates with. Please direct support and licensing questions about those products to the respective vendors.

A [Model Context Protocol](https://modelcontextprotocol.io/) server for Juniper Junos
and SRX devices, written in Rust. The single `rust-junosmcp` process exposes
the core Junos tools and, by default, the SRX security workflows through one
tool registry and endpoint. It is drop-in compatible with
[Juniper/junos-mcp-server](https://github.com/Juniper/junos-mcp-server) on the
inventory format and core tool surface, but built on async Rust
([rustEZ](https://github.com/mechubsec/rustez) +
[rustnetconf](https://github.com/mechubsec/rustnetconf)) instead of PyEZ.

## Beyond Juniper/junos-mcp-server

Drop-in on `devices.json` and the core tools — plus a lot the Python/PyEZ server doesn't have:

- **Safer config** — `commit_check_config` (validate, never commit), confirmed commits with auto-rollback, and `discard_candidate` to unstick a dirty candidate.
- **Device lifecycle** — staged `upgrade_junos` (image → install → reboot → verify), SCP `transfer_file`/`fetch_file`, PFE commands.
- **Scale & UX** — parallel session-pooled batch (~1.7× faster), `| last N`/`| count` + `max_lines`/`max_bytes` output caps, `router`/`router_name` aliases, Jinja2 templates.
- **Transport & auth** — streamable-HTTP with per-token router/tool scopes, TLS, and a `Host` allowlist; upstream is stdio-only.
- **SRX tools** (enabled by the default `srx` feature) — IDP & Application-ID **signature-package updates** (check/download/install/rollback), chassis-cluster health, license & security-services status, JTAC bundle with secret redaction, and read-only security-policy / address-book / application / NAT-rule inspection.

## Performance

Benchmarked on 2026-10-05 against [Juniper/junos-mcp-server](https://github.com/Juniper/junos-mcp-server)
1.1.1 and [shigechika/junos-mcp](https://github.com/shigechika/junos-mcp) 0.18.0 / 0.22.0
with the same read-only workload on a vSRX lab device (Junos 26.2R1.7), 3 runs × 30 calls per operation, 0 failed calls.
Medians across runs:

| | rust-junosmcp 0.27.2 | Juniper 1.1.1 | shigechika 0.22.0 |
|---|---|---|---|
| Cold start | 6 ms | 264 ms | 392 ms |
| Peak memory (RSS) | 20 MiB | 129 MiB | 98 MiB |
| SSH connections per run | 1 | 121 | 1 |
| `show version`, p50 | 216 ms | 878 ms | 228 ms |
| config RPC (access-denied reply¹), p50 | 11 ms | 776 ms | 21 ms |

¹ the read-only bench login has no configuration view, so this measures a
round trip with a ~400-byte reply, not a full config fetch. See
[docs/BENCHMARKS.md](docs/BENCHMARKS.md).

Full results, the mock-target overhead numbers, method and reproduction steps:
[docs/BENCHMARKS.md](docs/BENCHMARKS.md).

> ## v0.10.0 released — read before upgrading
>
> Two **breaking** authorization changes, both requiring operator action:
> a wildcard tool scope (`"tools": ["*"]`) no longer confers the 15 **write-capable**
> tools, and `tokens.json` must be mode `0600` or the server refuses to start.
> The new **`token set-scope`** command changes a token's scopes without
> reissuing its secret, so you can narrow scopes on the running 0.9.x server
> before swapping the binary. See
> [Upgrading to v0.10](#upgrading-to-v010) for the procedure.
>
> Security: the auth stack is now `unsafe`-free — `rust-junosmcp-auth` consumes
> the shared [`mecmcp-auth`](https://github.com/mechubsec/mecmcp) crate,
> which replaces hand-rolled secret zeroing with `zeroize` and `libc::getuid`
> with `rustix`. A malformed token entry also no longer takes the whole store
> offline at load.
>
> Current tool surface: 44 tools by default (28 Junos-only with
> `--no-default-features`). See the
> [v0.10.0 release notes](https://github.com/mechubsec/rustjunosmcp/releases/tag/v0.10.0)
> for the authorization changes above.

## Feature scope

### v0.1 (released)

- 6 tools: `get_router_list`, `gather_device_facts`, `execute_junos_command`,
  `get_junos_config`, `junos_config_diff`, `load_and_commit_config`.
- stdio transport only.
- `devices.json` drop-in compatible (`auth.type` ∈ {`password`, `ssh_key`}).
- Docker image (distroless) and LXC release tarball with systemd unit.

### v0.2 (released)

- streamable-http transport (with optional rustls TLS).
- bearer-token auth with per-token router/tool scopes.
- SIGHUP hot-reload of the token store.

### v0.2 follow-up: PFE + batch (released)

- `execute_junos_pfe_command` — single PFE-shell call against an explicit FPC target.
- `execute_junos_command_batch` — N routers x M operational CLI commands, parallel across routers, per-command and optional whole-batch timeouts. Pre-flight blocklist + unknown-router checks; continue-on-error after pre-flight.
- New `pfe_commands` rule list under `_blocklist_defaults` and per-device `blocklist`. Independent from `commands`.

### v0.2 follow-up: Templates (released)

- `render_and_apply_j2_template` — render a Jinja2 template (inline `template_content`) with a JSON `vars_content` object. Supports single (`router_name`) or multiple routers (`router_names`), dry-run, and full commit. Reuses the same blocklist + format gating as `load_and_commit_config`.
- Vars must be a top-level JSON object. **YAML is no longer accepted** as of v0.5.2 (RJMCP-SEC-002): the `serde_yml` / `libyml` advisory chain (RUSTSEC-2025-0067/-0068) was reachable from MCP input, so the YAML branch was removed.
- Size caps: `template_content` and `vars_content` are each bounded at 64 KiB.
- Strict-undefined: missing variables fail with the variable name rather than rendering empty.
- Auto-format detection: leading `<` → `xml`, any `set ` / `delete ` line → `set`, otherwise `text`. Override via `config_format`.
- Result shape: one row per router with `rendered_template`, `config_format`, and either `diff` (dry-run), `commit_comment` (apply-mode echo of the supplied comment — rustez does not return a server-issued commit id), or `error`.

### v0.2 follow-up: Inventory mutation (released)

- `add_device` — add a Junos device to the in-memory inventory and persist to `devices.json`. Atomic write (tempfile + rename), preserves `_blocklist_defaults`, per-device `blocklist`, and other top-level fields. SHA-256-based TOCTOU guard rejects calls that race with external edits.
- `reload_devices` — re-read the current `--device-mapping` (no args) or swap to a new inventory file (`file_name`). Reports added / removed / changed device names.
- New CLI flags: `--inventory-readonly` (rejects both tools unconditionally), `--allow-password-auth-add` (permits `auth.type=password` in `add_device`; mutually exclusive with `--inventory-readonly`).
- SIGHUP now also re-reads the inventory in addition to the token store.

**Documented sharp edge:** `add_device` does not modify the token store. If a token has `--routers 'edge-*'` and you `add_device` for `core-3`, the existing token will not see the new router. Mint a new token or rotate scopes after `add_device`.

### v0.3 (released)

- **NETCONF session pooling** — `PooledDevice` RAII guard with per-router single-slot pool (300s idle timeout, 30s SSH keepalive, background reaper). Eliminates SSH handshake overhead on sequential commands.
- **Tool reliability fixes** — XML wrapper stripping for `get_junos_config` and `junos_config_diff`, corrected `show configuration | compare rollback N` command, timeout now covers SSH connect + NETCONF handshake (not just CLI execution).
- **Batch partial results** — `execute_junos_command_batch` returns inline error rows for unknown or unreachable routers instead of aborting the entire batch. Blocklist violations remain strict.
- **Batch scope violations are not partial** — if any router in the request is outside the token's scope, the call is refused with HTTP 403 `insufficient_scope` and *no* router executes. This differs from the unreachable case above on purpose: a device being down is a runtime failure, whereas naming a device the caller may not touch is an authorization failure, and no part of an unauthorized request is honoured. Split the request or widen the token.
- **Confirmed commits** — `load_and_commit_config` gains `confirm_timeout_mins` parameter for `commit confirmed N` with auto-rollback safety net.
- **crates.io dependency** — `rustez` switched from path dep to crates.io 0.10.1; CI no longer requires sibling repo checkout.

### v0.4 (released)

- **`transfer_file`** — idempotent SCP push (`scp -O`, since Junos disables OpenSSH SFTP) of a host-staged file to `/var/tmp/<basename>` on a Junos device. Pre-flight free-space check on `/var` (`local_size + 32 MiB` headroom), SHA-256 verify, post-transfer checksum re-validation with delete-on-mismatch. SSH-key auth only — password-auth devices rejected with `[code=unsupported_auth]`.
- **`list_staged_files`** — lists host staging dir always, plus device `/var/tmp/` listing when `router_name` is supplied.
- **Stable error codes** — every transfer failure carries an LLM-readable `[code=...]` Display tag (`bad_source_path`, `insufficient_disk`, `unsupported_auth`, `dest_exists_differs`, `scp_failed`, `connect_timeout`, `host_key_mismatch`, `host_key_revoked`, `verify_mismatch`, `outer_timeout`, `device_probe_failed`).
- *