# Reported issues for Junos MCP

Pod holds 17 of 18 problems reported by people outside the maintainer team. Issues filed by the project's own owners, members and collaborators are excluded entirely — a maintainer's release checklist is not a warning to a prospective user.

Back to [Junos MCP](/mcp/junos-mcp).

## Most discussed

### Expose junos-ops --tags filter to MCP tools

## Summary

`junos-ops` supports `--tags TAG,...` to filter target hosts (AND-match across multiple tags). The underlying `common.args.tags` is already wired in `server.py` but hard-coded to `None`, so MCP tools currently always operate on the full router list from `config.ini`.

Exposing a `tags` parameter on the batch/listing tools would let AI agents target a logical subset (e.g. `main` vs `backup` VRRP peers, or per-site tags) without the agent having to re-implement the filter client-side.

[Read the thread](https://github.com/shigechika/junos-mcp/issues/1) · 2026-04-13 · closed · 1 comment

### run_show_* tools accept any operational-mode command (reboot, clear, restart)

## Summary

`run_show_command`, `run_show_commands` and `run_show_command_batch` pass the caller's string
to `Device.cli()` with no validation. Operational mode cannot enter configuration mode, so this
is not as broad as a config-change path -- but it is still not read-only.

```python
# junos_ops/show.py -- run_cli()
raw = _cli_with_retry(dev, command, hostname, retry, output_format)
```

The only validation is on `output_format`. The command string itself is never checked, so these
tools will 

[Read the thread](https://github.com/shigechika/junos-mcp/issues/79) · 2026-08-14 · open · 0 comments

### 調査: Claude Code MCP Tunnels(research preview)による外部公開不要化の検討

## 背景
トレンドMCP調査で Claude Code の MCP Tunnels（research preview、2026-07-28発表）を確認。プライベートネットワーク内の MCP サーバーを、インバウンドファイアウォール設定・パブリックエンドポイント・IPホワイトリストなしで Claude から利用可能にする機能。

参考: https://claude.com/blog/bringing-mcp-2026-07-28-to-claude

## 検討したい点
本サーバーは社内ネットワーク機器の管理用MCPサーバーであり、外部公開の必要性そのものをこの機能で消せる可能性がある。

- [ ] research preview から正式機能への移行時期を注視
- [ ] 現行の運用（本番運用ホスト常駐 + 何らかの公開経路）との比較で、Tunnels移行のメリット・制約を整理

まだ research preview 段階のため実運用切替は時期尚早。トラッキングのみ。

[Read the thread](https://github.com/shigechika/junos-mcp/issues/73) · 2026-08-06 · open · 0 comments

### Add a live smoke test that exercises every registered tool

## Motivation

Unit tests check logic against fixtures. They cannot tell you that a tool users actually call has stopped returning real data — a tool that exists but does not work is worse than no tool.

This happened for real in `jquants-mcp`: the earnings-calendar tools returned well-formed **empty** results for every query while the whole suite stayed green (shigechika/jquants-mcp#523). A live smoke test was built there to close the gap, and on its first production run it found three defects,

[Read the thread](https://github.com/shigechika/junos-mcp/issues/55) · 2026-07-25 · closed · 0 comments

### release.yml: github-release job fails every release (gh release create conflicts with release-please)

The `release.yml` pipeline has failed on every recent release (v0.15.2 – v0.15.5), even though the package publishes to PyPI fine.

### What fails
All jobs pass (`test` → `build` → `testpypi` → `publish` → `mcp-registry`) except the final **`github-release`** job, at:

```
gh release create "$GITHUB_REF_NAME" dist/* --generate-notes
```

### Why
release-please **already creates the GitHub Release** when its release PR is merged (that's what pushes the `v*` tag). So by the time `release.yml` runs

[Read the thread](https://github.com/shigechika/junos-mcp/issues/45) · 2026-07-12 · closed · 0 comments

### Module docstring says "23 tools" (actual 24)

`junos_mcp/server.py:3` still says:

```
Provides 23 tools for Juniper Networks device management: ...
```

The server registers **24** tools (`grep -c '^@mcp.tool' junos_mcp/server.py` = 24; `health_check` was added in PR #22). Minor source-doc drift.

Either bump to "24 tools" or drop the hard count to avoid future drift.

_The same count in `CLAUDE.md` was fixed in doc PR #38; this issue tracks the source docstring._

[Read the thread](https://github.com/shigechika/junos-mcp/issues/39) · 2026-07-12 · closed · 0 comments

### docs: reduce duplicated pipe-filtering explanation; reconsider retroactive CHANGELOG edits

Two minor documentation-hygiene findings from the review of #30 (fixing an inaccurate pipe-filtering claim), not blocking but worth tracking.

## 1. The pipe-filtering explanation is duplicated near-verbatim in 4 places

`CHANGELOG.md` (v0.13.0 entry), `README.md` ("Structured output format" section), and the docstrings of both `run_show_command` and `run_show_commands` in `junos_mcp/server.py` all restate the same ~4-sentence explanation (PyEZ's `Device.cli()` sends over NETCONF RPC, JunOS does

[Read the thread](https://github.com/shigechika/junos-mcp/issues/31) · 2026-07-08 · open · 0 comments

### docs: user documentation site on GitHub Pages (family rollout)

## Summary

Roll out the family documentation-site pattern to this repository: a task-oriented user guide on GitHub Pages, complementing the reference README.

Template (live example): https://github.com/shigechika/mcp-stdio — issue shigechika/mcp-stdio#284, scaffold PR shigechika/mcp-stdio#285, published at https://shigechika.github.io/mcp-stdio/ (Japanese at `/ja/`).

## Steps

1. Copy the three-piece scaffold from mcp-stdio and adapt:
   - `mkdocs.yml` — change `site_name` / `site_url` / `rep

[Read the thread](https://github.com/shigechika/junos-mcp/issues/27) · 2026-07-02 · open · 0 comments

## Most recent

### daily_brief: a 'No alarms' node section suppresses the other node's real alarms (sectioned cluster/VC output)

## Problem

`daily_brief`'s alarm checks (check 1 `show system alarms` / check 2 `show chassis alarms` in `_check_host_health`) gate on a whole-output substring test:

```python
if "No alarms" not in out:
```

On SRX chassis clusters (and any multi-node/VC platform), the CLI output is sectioned per node:

```
node0:
--------------------------------------------------------------------------
No alarms currently active

node1:
------------------------------------------------------------------------

[Read the thread](https://github.com/shigechika/junos-mcp/issues/21) · 2026-06-12 · closed · 0 comments

### daily_brief: report a physical interface as IF_DOWN only if it has a description AND went down within since_hours

## Background
After #13 (exclude loopback / mgmt / internal logical units), `daily_brief` still floods WARNING with **unused physical access ports** that are `up down` (e.g. an access switch with `ge-0/0/0..21` down). These have no description and are simply not patched. They bury real faults.

Observed 2026-06-05 morning run: `brs-sw` produced 22 `[IF_DOWN]` lines, all undescribed unused ports. `med-sw` reported `xe-0/1/1` which has been down for ~50 weeks (chronic, no description).

## Proposa

[Read the thread](https://github.com/shigechika/junos-mcp/issues/15) · 2026-06-05 · closed · 0 comments

### daily_brief: IF_DOWN check is too noisy — exclude management & internal interfaces

## Problem

`daily_brief`'s interface check flags every admin-up / link-down interface as `[IF_DOWN]`, excluding only loopbacks (`lo*`). In practice this buries real anomalies under interfaces that are *expected* to be down:

- **Management / OOB**: `fxp0`, `me0`, `me0.0`, `vme`, `em0` / `em1` (unplugged by design on many chassis)
- **Juniper internal logical units**: `.16386` (internal services), `.32767`, `.32768`
- **Unused physical ports left admin-up**: spare breakout members (e.g. `xe-2/1/

[Read the thread](https://github.com/shigechika/junos-mcp/issues/13) · 2026-06-02 · closed · 0 comments

### feat: daily_brief — morning health check across all tagged routers

## Summary

A new `daily_brief` MCP tool that performs a structured health check
across all routers in a tag group (e.g. `["main"]`) and returns a
compact anomaly-highlighted summary. Designed for daily morning use:
run once, get an at-a-glance view of overnight events, and let Claude
drill into anything flagged.

## Motivation

Current workflow: check each router manually or chain multiple
`run_show_command_batch` calls. There is no single tool that:

1. **Detects NAT pool exhaustion** (SRX fle

[Read the thread](https://github.com/shigechika/junos-mcp/issues/10) · 2026-05-25 · closed · 0 comments

### feat: track junos-ops v0.17–v0.23 API additions (unlink, disk space, no_commit, output_format)

junos-mcp currently requires junos-ops ≥ 0.16.9 (released 2026-04-16).
junos-ops has since shipped v0.17.0 – v0.23.0. Four API additions are
worth surfacing as MCP tool parameters; one (disk space) is a display
update that requires a new RPC call on the MCP side.

## Changes to track

### 1. `install_package`: add `unlink` flag (junos-ops v0.23.0 #89) — **highest priority**

PyEZ `SW.install()` does not expose the `unlink` parameter of
`request system software add`. On low-flash devices (EX2300 

[Read the thread](https://github.com/shigechika/junos-mcp/issues/9) · 2026-05-25 · closed · 0 comments

### run_show_command_batch: add server-side grep_pattern to reduce output size

## Problem

When patrolling 93 campus routers with `run_show_command_batch` and `show route summary`, the output exceeds the MCP inline limit (~100 KB) and is saved to a tool-results file. Claude Code then has to read that file and run Python to extract a single field (`inet.0` destination count) per host.

Example patrol command:
```
run_show_command_batch(tags=["main"], command="show route summary | match 'inet.0:'")
```

Even with `| match` in the JUNOS command, the full structured batch resu

[Read the thread](https://github.com/shigechika/junos-mcp/issues/6) · 2026-05-01 · closed · 0 comments

### feat: per-host SSH/NETCONF connection pool with idle timeout

## Motivation
Each MCP tool call currently opens a fresh NETCONF session (`common.connect()` → work → `dev.close()`). For AI-driven single-host deep-dive / troubleshooting workflows this is wasteful: a typical LLM exploration hits the same device with 5–20 sequential tool calls over a few minutes.

Per-call handshake cost is roughly:
- TCP + SSH handshake: ~1–2 s
- NETCONF `<hello>` capability exchange: ~0.5–1 s
- PyEZ `Device.open()` facts gather (when enabled): ~5–10 RPCs

Upstream [Juniper/ju

[Read the thread](https://github.com/shigechika/junos-mcp/issues/5) · 2026-04-16 · closed · 0 comments

### feat: expose junos-ops check subcommand as MCP tool(s)

## Context
junos-ops 0.15.0 shipped a unified `check` subcommand with three modes (see [junos-ops#41](https://github.com/shigechika/junos-ops/issues/41)):

- `--connect` — per-host NETCONF reachability probe (lightweight, no full facts)
- `--local` — inventory-based local package/hash verification (no device connection)
- `--remote` — per-host device-side checksum of a staged package
- `--all` — both inventory table and per-host table

The reusable APIs are already dict-returning and render-laye

[Read the thread](https://github.com/shigechika/junos-mcp/issues/4) · 2026-04-15 · closed · 0 comments

### docs: document AND/OR tag grammar in README

## Context
v0.9.0 aligned the MCP `tags` parameter with the `junos-ops --tags` CLI grammar:

- Each list element is one tag group (comma-separated tags AND together within a group).
- Multiple list elements OR together across groups.
- Example: `["tokyo,core", "backup"]` ≡ `(tokyo AND core) OR backup`.
- Combined with `hostnames`, the result is the intersection (matches junos-ops 0.16.4+).

The docstrings for `get_router_list`, `run_show_command_batch`, `collect_rsi_batch` are updated, but `READ

[Read the thread](https://github.com/shigechika/junos-mcp/issues/3) · 2026-04-15 · closed · 0 comments

The remaining reports are on [the project's issue tracker](https://github.com/shigechika/junos-mcp/issues).