eos-mcp
MCP server for Arista EOS device operations via eAPI, enabling show commands, config push, and tech-support collection.
README
<!-- mcp-name: io.github.shigechika/eos-mcp -->
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_CONFIGenvironment 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
| Tool | Description |
|---|---|
health_check |
Report server version and config status (lightweight; does NOT connect to devices) |
get_router_list |
List registered devices (optional tag filter) |
get_device_facts |
Return structured facts for one device (model, serial, EOS version, uptime, memory) |
get_device_facts_batch |
Return device facts for multiple devices in parallel |
get_version |
Return EOS version string (quick connectivity check) |
run_command |
Run a single enable-mode command on one device |
run_commands |
Run multiple enable-mode commands on one device |
run_command_batch |
Run an enable-mode command on multiple devices in parallel |
run_commands_batch |
Run multiple enable-mode commands on multiple devices in parallel |
get_config |
Retrieve running-config |
get_config_diff |
Show config diff vs rollback checkpoint |
list_config_sessions |
List configure sessions and their state |
push_config |
Push config via configure session (dry_run=True by default) |
confirm_config_session |
Confirm a pending commit timer session |
abort_config_session |
Abort a pending session |
collect_tech_support |
Collect show tech-support output |
daily_brief |
Health 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_sessionandabort_config_sessionare skipped by name, and a test enforces that.collect_tech_supportis 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 withshow 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.pyis 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
Recommended Servers
playwright-mcp
A Model Context Protocol server that enables LLMs to interact with web pages through structured accessibility snapshots without requiring vision models or screenshots.
Magic Component Platform (MCP)
An AI-powered tool that generates modern UI components from natural language descriptions, integrating with popular IDEs to streamline UI development workflow.
Audiense Insights MCP Server
Enables interaction with Audiense Insights accounts via the Model Context Protocol, facilitating the extraction and analysis of marketing insights and audience data including demographics, behavior, and influencer engagement.
VeyraX MCP
Single MCP tool to connect all your favorite tools: Gmail, Calendar and 40 more.
graphlit-mcp-server
The Model Context Protocol (MCP) Server enables integration between MCP clients and the Graphlit service. Ingest anything from Slack to Gmail to podcast feeds, in addition to web crawling, into a Graphlit project - and then retrieve relevant contents from the MCP client.
Kagi MCP Server
An MCP server that integrates Kagi search capabilities with Claude AI, enabling Claude to perform real-time web searches when answering questions that require up-to-date information.
Neon Database
MCP server for interacting with Neon Management API and databases
E2B
Using MCP to run code via e2b.
Exa Search
A Model Context Protocol (MCP) server lets AI assistants like Claude use the Exa AI Search API for web searches. This setup allows AI models to get real-time web information in a safe and controlled way.
Qdrant Server
This repository is an example of how to create a MCP server for Qdrant, a vector search engine.