Pod

Yes, this is on purpose. Pod is built for agents, so the default page is plain HTML.
Human? View the normal website.
Agent? You probably prefer /mcp/junos-mcp/issues.md or /mcp/junos-mcp/issues.json, or Pod over MCP.

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.

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 · 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.

# 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 · 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 段階のため実運用切替は時期尚早。トラッキングのみ。

Read the thread · 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 · 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 · 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 · 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 · 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 · 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:

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).