Skip to main content
Glama
io.github.shigechika/junos-mcp

io.github.shigechika/junos-mcp

by shigechika

Related Servers

Alternatives to io.github.shigechika/junos-mcp

No user-submitted related servers found.

    Related Servers

    • A
      license
      Not graded
      quality
      D
      maintenance
      MCP server for network operations that lets AI assistants interact with Cisco/Juniper network devices through safe, well-defined tools like compliance audits and configuration backups.
      MIT
    • A
      license
      Not graded
      quality
      B
      maintenance
      Enables MCP-compatible clients such as Claude Desktop to interact with Juniper Junos network devices, exposing tools for running operational commands, applying and committing configuration changes with guardrails, and managing device connections over stdio or streamable-http transports. Supports password and SSH key authentication, connection pooling, and token-based access control for the HTTP transport.
      Apache 2.0
    • A
      license
      Not graded
      quality
      D
      maintenance
      MCP server that enables AI assistants to manage SSH terminal sessions, execute commands, and automate server operations through natural language, with multi-tab support and session persistence.
      MIT
    • A
      license
      A
      quality
      D
      maintenance
      A comprehensive MCP server for network device management via SSH/Telnet. Supports multiple vendors such as Cisco IOS and BDCOM, enabling AI assistants to execute commands and manage routers, switches, and firewalls.
      4
      MIT
    • A
      license
      Not graded
      quality
      B
      maintenance
      Enables AI assistants to operate Juniper Junos and SRX network devices over NETCONF and SCP, running operational CLI and PFE commands, inspecting and diffing configuration, validating and committing changes with confirmed auto-rollback, and managing SRX security workflows such as signature-package updates, chassis-cluster health, and read-only policy and address-book inspection.
      3
      MIT

    TDQS

    A3.8/5.0

    Scored across 28 tools

    Disambiguation4/5

    Most tools have clearly distinct purposes, and the descriptions carefully explain the sync/async split for push_config, daily_brief, and their _start/_result partners. The main hazard is the run_show_command / run_show_commands / run_show_command_batch trio, where a singular 's' distinguishes 'one command' from 'multiple commands on one host' vs 'one command on many hosts' — easy to misselect without reading descriptions. check_reachability vs health_check is also mildly confusable but documented.

    Naming Consistency4/5

    Almost everything follows a snake_case verb_noun pattern (get_*, run_*, check_*, collect_*, copy/install/rollback_package, push_config_*, *_start/*_result). A few names drop the verb (daily_brief, health_check) and the singular/plural run_show_command(s) deviation is awkward, but conventions are otherwise predictable.

    Tool Count3/5

    28 tools is on the heavy side, though the surface genuinely spans config push, show execution, firmware lifecycle, RSI collection, and fleet monitoring. The async/sync pairs (push_config*, daily_brief*) are justified by real client timeouts, but some consolidation and the near-duplicate show-command variants push this into 'heavy' territory.

    Completeness4/5

    Strong lifecycle coverage: config read/diff/push with commit-confirmed safety, firmware copy/install/rollback, reboot scheduling, RSI collection, and health monitoring with a job model. Gaps are minor — no explicit configuration rollback (only diff against a rollback_id) and no remote file upload/delete beyond package copy, but core workflows are covered.

    Maintenance

    ActivityMaintained
    ResponsivenessNo recent community issues