pod
Other formats agents might prefer:
markdownjsonllms.txt

Agent? You probably want markdown or json, or Pod over MCP.

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.

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

# 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 · 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 · 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 · 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 · 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 · 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 · 2026-06-18 · closed · 0 comments

Most recent

The remaining reports are on the project's issue tracker.