🎩 You're Invited:Meet the Socket team at Black Hat in Las Vegas, August 3-6.RSVP
Sign In

eos-mcp

Package Overview
Dependencies
Maintainers
1
Versions
14
Alerts
File Explorer

Advanced tools

Socket logo

Install Socket

Detect and block malicious and high-risk dependencies

Install

eos-mcp

MCP server for Arista EOS device operations via eAPI

pipPyPI
Version
1.1.3
Weekly downloads
462
492.31%
Maintainers
1
Weekly downloads
 

eos-mcp

MCP server for Arista EOS device operations via eAPI.

Exposes EOS show commands, running-config retrieval, configuration push (via configure session with commit timer), and tech-support collection to MCP-compatible AI assistants.

Installation

pip install eos-mcp

Configuration

Copy config.ini.example to ~/.config/eos-mcp/config.ini and fill in credentials:

[DEFAULT]
username = admin
password = yourpassword
transport = https
verify = false

[switch1.example.com]
tags = main,dc1

[switch2.example.com]
tags = main,dc1

Config file discovery order:

  • EOS_MCP_CONFIG environment variable
  • ./config.ini (current directory)
  • ~/.config/eos-mcp/config.ini

(Individual MCP tool calls may also override the path via a config_path parameter.)

Usage

# Verify config and list devices
eos-mcp --check

# Test connectivity to a specific host
eos-mcp --check --check-host switch1.example.com

# Start MCP server (stdio transport)
eos-mcp

Tools

ToolDescription
health_checkReport server version and config status (lightweight; does NOT connect to devices)
get_router_listList registered devices (optional tag filter)
get_device_factsReturn structured facts for one device (model, serial, EOS version, uptime, memory)
get_device_facts_batchReturn device facts for multiple devices in parallel
get_versionReturn EOS version string (quick connectivity check)
run_commandRun a single enable-mode command on one device
run_commandsRun multiple enable-mode commands on one device
run_command_batchRun an enable-mode command on multiple devices in parallel
run_commands_batchRun multiple enable-mode commands on multiple devices in parallel
get_configRetrieve running-config
get_config_diffShow config diff vs rollback checkpoint
list_config_sessionsList configure sessions and their state
push_configPush config via configure session (dry_run=True by default)
confirm_config_sessionConfirm a pending commit timer session
abort_config_sessionAbort a pending session
collect_tech_supportCollect show tech-support output
daily_briefHealth check (environment, errdisabled, uptime, MLAG, recent syslog alerts) across multiple devices

Development

Live smoke test

Unit tests check logic against fixtures; they cannot tell you that a tool has stopped returning real data. scripts/smoke_test.py runs every registered tool against the configured devices and fails on empty, malformed or error answers:

# uses the same inventory file as the server (EOS_MCP_CONFIG)
uv run python scripts/smoke_test.py
uv run python scripts/smoke_test.py --only facts --traceback
  • Read-only. push_config, confirm_config_session and abort_config_session are skipped by name, and a test enforces that. collect_tech_support is skipped too — it changes nothing, but it is minutes of device CPU for an answer no assertion would read. The command-running tools are exercised with show version: they accept enable-mode commands in general, and a smoke test must not be the thing that types one that matters.
  • No payloads in the report. Tool names and statuses only; error text is redacted too, since every error here is prefixed with the device it came from and the payloads are configuration.
  • Nothing estate-specific in the specs. The device the per-host tools need is discovered at run time from the configured inventory, and skipped when it is empty. Two tests keep it that way: one refuses those parameters as literals, the other bans anything address-shaped anywhere in the file, because this repository is public.
  • Every probe refuses the Error (<host>): ... line these tools return in place of raising — otherwise an unreachable device would read as a successful call.
  • CI enforces the cheap half: a tool registered without a probe spec fails the build (tests/test_smoke_probes.py), so adding a tool forces the question "how would we know it works?".
  • scripts/smoke_harness.py is the engine and holds no EOS knowledge: it is kept identical across the servers that share it, so fix engine bugs once and sync the file rather than patching this copy.

Requirements

  • Python >= 3.10
  • Arista EOS with eAPI enabled (management api http-commands)
  • Network access to port 443 (HTTPS) on target devices

License

Apache-2.0

Keywords

arista

FAQs

Did you know?

Socket

Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.

Install

Related posts