EVE-NG MCP

What if you could hand Claude a network diagram and get back a fully cabled EVE-NG lab a few minutes later? That's what eveng-mcp does. It's a small open-source MCP server that gives Claude direct access to an EVE-NG server, so you can build topologies, start and stop nodes, and run CLI commands on FortiGates, FortiSwitches, Nexus and anything else with a telnet console, all from a chat.

What is eveng-mcp?

MCP (Model Context Protocol) is the open standard Claude uses to talk to outside tools. eveng-mcp is an MCP server written in Python that wraps the EVE-NG REST API and node consoles. Once it's connected, Claude has 22 tools it can use on its own:

• Server and inventory: server status, list labs and folders, list installed templates and images

• Labs: create, inspect, read the topology, delete (with confirmation)

• Nodes: add nodes from any template, start, stop, wipe, delete

• Networks: bridges, NAT and Cloud (pnet) networks, cable any two interfaces together

• Console: run CLI commands on a node's telnet console and get clean per-command output, with --More-- paging handled automatically

Tested against EVE-NG Pro 7.2 and Claude Desktop on Windows. It also works with EVE-NG Community. Destructive actions such as deleting a lab or wiping a node need an explicit confirm, and a read-only mode lets you hand it out for show commands only.

How it fits together

The server runs on the EVE-NG host itself, and Claude Desktop starts it over SSH. That design keeps things simple and safe:

• The EVE API and every node console are reached on localhost, so no console ports need opening through a firewall.

• Nothing listens on the network; the SSH session is the only way in.

• Your EVE credentials live in a wrapper script on the EVE box, never in the Claude config on your laptop.

Setting it up

The full guide, with a troubleshooting table, is in the GitHub repo. The short version:

1. Install on the EVE host. EVE-NG Pro 7 runs Ubuntu 24.04 with Python 3.12. Install into its own venv so it stays out of EVE's packages.

2. Run the live check. A read-only smoke test that confirms every API call works against your server before you wire anything up.

3. Create a wrapper script that sets the EVE URL and credentials and starts the server.

4. Set up SSH key login from your laptop to the EVE host, since Claude Desktop can't answer a password prompt.

5. Add one entry to claude_desktop_config.json and restart Claude Desktop.

apt install -y python3-venv unzip
cd /opt && unzip ~/eveng-mcp.zip
python3 -m venv /opt/eveng-mcp/.venv
/opt/eveng-mcp/.venv/bin/pip install /opt/eve-ng-mcp

And the Claude Desktop side (Windows):

"mcpServers": {
  "eve-ng": {
    "command": "C:\\Windows\\System32\\OpenSSH\\ssh.exe",
    "args": ["-o", "BatchMode=yes", "root@<eve-ip>", "/opt/eveng-mcp/run.sh"]
  }
}

Tip: add mcpServers inside the existing top-level braces of the config file. Pasting a second JSON block after it is the most common reason Claude Desktop shows "Couldn't load app settings" on restart. The repo includes a PowerShell snippet that fixes it.

From a diagram to a running lab

Here's the real test. I drew a topology for an FGSP lab: an edge FortiGate behind NAT, a north and south FortiSwitch, three FortiGate v8 firewalls in an FGSP cluster with dedicated session-sync and HA links, out-of-band management clouds, and two Ubuntu hosts.

Then I pasted it into Claude with one sentence:

Create me a lab using the following topology. Image names are in the diagram, and use the ports as is when connecting devices.

Claude worked through it on its own:

• Looked at my existing FGSP v1 lab to learn my conventions: which cloud types I use, and which FortiGate port I use for OOB and NAT.

• Created the lab and 8 nodes with the right images (FortiGate v8, FortiSwitch build 3591, Ubuntu 25.10), CPU, RAM and port counts.

• Confirmed how interface indexes map to port names on each device type before cabling anything.

• Added the NAT cloud and four OOB clouds, then cabled 15 point-to-point links port for port.

• Read the topology back from EVE and checked all 21 connections against the diagram.

It also flagged the spots where the diagram was ambiguous instead of guessing silently. My drawing labeled two different links as South port1, which can't both be true, so Claude used port3 to match my v1 lab and told me. It also mapped the FortiGates' "mgmt" label to port12, since FortiGate VMs don't have a port named mgmt.

Along the way it hit a real bug: EVE-NG Pro 7.2 leaves the node type out of its template data, so the API rejected the first node with error 20022. Claude worked around it, finished the lab, then fixed the server code, added a regression test and pushed the fix to the repo.

Testing networking elements fast

Building the lab is only half of it. Because Claude can reach the consoles, the same chat can drive your testing. A few prompts worth trying:

• "Which images do I have for FortiGate and FortiSwitch?" Inventory in seconds, grouped by vendor.

• "Start everything in FGSP Lab v2." Then ask it to watch the consoles until each node reaches a login prompt.

• "On FW-01 through FW-03, run get system ha status and diagnose sys session sync." One prompt, output from every firewall, compared for you.

• "Fail FW-02's HA link and tell me what changes." Change one thing, re-run the checks, get a before and after.

• "Clone this design with FortiGate 7.6.7 instead of v8." Version-to-version regression testing without redrawing anything.

• "Wipe the firewalls and start over." Back to a clean baseline whenever a test goes sideways.

The pattern that works best: describe the outcome you want, let Claude plan the steps, and have it read state back from EVE to verify instead of assuming.

Get the code

Everything is on GitHub: the server, tests, setup guide and troubleshooting notes. Issues and pull requests are welcome.

View eveng-mcp on GitHub