Control netplex. from Claude with MCP

netplex. includes a Model Context Protocol (MCP) server. MCP is the way Claude Desktop, Claude Code and claude.ai use tools. Point an AI agent that supports MCP at it, and it can build a lab and check its own work. It can read the topology, connect devices, power them on and run commands. Then it can pull real numbers from the links and ports to prove traffic is really moving.

Every tool below is real and shipped in tools/netplex-mcp/server.py - not illustrative pseudocode. Here is the full list, grouped by what the tools do:

78 tools as of the current release, generated straight from the server's own tool list.

Build & wire a lab:

Power & control:

Configure & run:

Look & feel:

Images & your own code:

Diagnose & prove it works:

Fault-finding, no AI required:

Read-only operator tools:

Approvals:

Hardware tools:

Configure Claude Desktop - add to claude_desktop_config.json:

{
  "mcpServers": {
    "netplex": {
      "command": "python3",
      "args": ["/path/to/netplex/tools/netplex-mcp/server.py"],
      "env": {
        "NETPLEX_URL": "http://localhost:8088",
        "NETPLEX_USER": "admin",
        "NETPLEX_PASS": "netplex"
      }
    }
  }
}

Restart Claude Desktop and the tools above become available to the model automatically - ask it to "list my labs" or "create a lab called staging with two Alpine hosts" and it calls the real REST API underneath, exactly like the Studio UI does.

Run it standalone (stdio transport, the MCP default):

NETPLEX_URL=http://localhost:8088 NETPLEX_USER=admin NETPLEX_PASS=netplex \
  python3 tools/netplex-mcp/server.py

Or over SSE for a web-facing client: python3 server.py --transport sse --port 9999.

Because every tool call is just the REST API underneath, anything the MCP server can do, the CLI or SDK can also do directly - see "CLI quickstart" and "The Python SDK" for the non-AI equivalents of the same operations.

Build and debug a lab with your own AI agent

Building a topology is the easy half. The harder, more useful thing an agent can do is tell you why a link isn't passing traffic - not "the API call succeeded" but "port A is transmitting and port B is receiving nothing." That's what the diagnose tools are for, and they read the numbers straight from Linux (the counters it keeps for every network port), not from a config file that could be wrong.

A typical debug turn looks like this:

$ agent "why can't leaf01 reach leaf02?"

→ diagnose_link(lab_id="l-9f2", link_id="lnk-14")
{
  "link_id": "lnk-14",
  "stats": {
    "interface_a": { "name": "eth1", "operstate": "up", "carrier": 1, "tx_bytes": 48210, "rx_bytes": 0 },
    "interface_b": { "name": "eth1", "operstate": "up", "carrier": 1, "tx_bytes": 0, "rx_bytes": 0 }
  },
  "asymmetries": [
    "A→B: A transmitting but B not receiving"
  ]
}

That's a real response shape from diagnose_link - it composites the link's raw sysfs counters from both ends into one call and flags the asymmetry itself, so the agent doesn't have to hand-roll the comparison. Under the hood it's calling the same GET /labs/{lab_id}/links/{link_id}/stats route get_link_stats exposes directly, plus each node's live interface list via get_interface_counters - both are also callable on their own when you want raw numbers instead of a diagnosis.

If the counters alone aren't enough, the agent can go one level deeper and look at the actual frames: start_capture(lab_id, link_id), reproduce the issue, stop_capture(lab_id, link_id), then get_capture_summary(lab_id, link_id) for a protocol/source/destination breakdown of what actually crossed the wire - the same capture pipeline the Studio UI's Captures tab uses, just callable from the agent's own loop. All six diagnose/capture tools are read-only-annotated, so they work even when the MCP server is locked down with NETPLEX_MCP_READONLY=1 for an operator who should be able to look but not touch.

Since September 2026, wait_for_node_ready waits until a node's console shows its real vendor prompt (or the container reports healthy) instead of an agent hand-rolling a poll loop - and ping/assert_protocol_state answer "can node A reach node B" directly. The full, current tool list is larger than the categories above show; a complete refresh of this page's tool catalogue is tracked as a follow-up.