# Reported issues for EOS MCP

Pod holds 7 of 7 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 [EOS MCP](/mcp/eos-mcp).

## Most discussed

### release-please skips release for a lone squash commit after a release PR (path-split → commits: 0)

## Symptom

After #14 (`feat: add lightweight health_check MCP tool`) was squash-merged, release-please did **not** open a `release 0.4.0` PR. The run log shows:

```
✔ Building pull requests
❯ Found release for path ., v0.3.0, sha: d3470a56
✔ Collecting commits since all latest releases
❯ Fetching merge commits on branch main with cursor: undefined
✔ Splitting 1 commits by path
❯ commits: 0
✔ Considering: 0 commits
✔ No commits for path: ., skipping
```

It **fetched** the 1 commit but its path

[Read the thread](https://github.com/shigechika/eos-mcp/issues/17) · 2026-06-18 · closed · 1 comment

### run_command family executes arbitrary enable-mode commands without validation

## Summary

`run_command`, `run_commands`, `run_command_batch` and `run_commands_batch` pass the caller's
string straight to `Node.execute()` with no validation, so they are not read-only despite what
the naming and the surrounding API imply.

```python
# eos_mcp/eapi.py
def run_show(node, command: str) -> str:
    result = node.execute([command], encoding="text")
    return result["result"][0].get("output", "")
```

eAPI's `runCmds` accepts config-mode entry in the command list, so a caller can

[Read the thread](https://github.com/shigechika/eos-mcp/issues/83) · 2026-08-14 · 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/eos-mcp/issues/56) · 2026-07-25 · closed · 0 comments

### Drop streamable-http transport, go stdio-only

## Problem

`eos_mcp/__main__.py` exposes `--transport {stdio,streamable-http}`, but the
`streamable-http` option is half-baked:

- No authentication/authorization layer for the HTTP listener.
- No bind-address/port configuration exposed (whatever `mcp.run()`'s
  defaults are).
- Not documented in README.md/README.ja.md (only the stdio invocation is
  shown).
- No test coverage for the HTTP transport path.

Given this server can push config and run arbitrary EOS commands, growing an
under-specif

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

### daily_brief: parse all EOS logging timestamp formats (RFC3339 + traditional year/timezone + default)

## Why

We will set `logging format timestamp high-resolution` (RFC3339) on the EOS fleet for unambiguous logs. But `_window_syslog` (added in #20) only understands the year-less RFC3164 form, so RFC3339 lines would fail to parse, be treated as untimestamped, and all be kept — silently disabling the window filter (regression). eos-mcp must understand every format EOS can emit.

## Formats to support (all `logging format timestamp` variants + default)

- `high-resolution` -> `2026-06-26T09:22:56.

[Read the thread](https://github.com/shigechika/eos-mcp/issues/22) · 2026-06-26 · closed · 0 comments

### daily_brief: year-less EOS syslog timestamps cause stale (prior-year) flap false-positives

## Problem

`daily_brief` (`check_health` in `eos_mcp/eapi.py`) decides whether a syslog alert is recent by relying on EOS's `show logging last <N> hours` and does **no client-side, year-aware timestamp filtering** (`_get_syslog_text`, eapi.py:224-236; the regex scan at eapi.py:350-364 does not time-filter at all).

EOS syslog timestamps have **no year** (`Jun 26 09:22:56`). When `show logging last N hours` is rejected by the running EOS version, `_get_syslog_text` falls back to the **entire** b

[Read the thread](https://github.com/shigechika/eos-mcp/issues/19) · 2026-06-26 · closed · 0 comments

### daily_brief syslog scan: BGP/OSPF ADJCHANGE matches both up and down

Follow-up nit from #11 (syslog scan in `daily_brief`).

## Problem

`_SYSLOG_ALERT_RE` matches `%BGP-\d+-ADJCHANGE` and `%OSPF-\d+-ADJCHANGE` in **both directions** (up and down). The junos-mcp equivalent filters BGP to the `Established->` (down) transition only. The EOS `%LINEPROTO` pattern is already direction-filtered (`to\s+down`), so BGP/OSPF are inconsistent with it.

Impact today is nil (the current EOS fleet is L2 — no BGP/OSPF), but on an L3 EOS device a reboot would surface every neigh

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

## Most recent

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