The MCP Integration Layer: 113 Servers and Transports

NetClaw's automation reach is defined by a single number in its README: 113 MCP integrations. Every device NetClaw configures, every cloud API it queries, every alert it correlates, and every diagram it draws flows through the Model Context Protocol (MCP), Anthropic's open standard for connecting AI hosts to external tools. Rather than hard-coding hundreds of vendor SDKs into one monolithic agent, NetClaw treats each capability as a discrete MCP server — a self-contained process exposing typed tools over JSON-RPC 2.0. This section explains what MCP is, how NetClaw's stdio-first transport strategy enables kernel-level sandboxing, how tool calls are actually framed on the wire, which operational domains the 113 servers cover, and why an ephemeral, polyglot process model is the right fit for network automation.

flowchart LR
    HOST["NetClaw host (OpenClaw + Claude)"] --> CLIENTS["MCP clients (one per server)"]
    CLIENTS --> STDIO["stdio: pyATS, NSO, NetBox"]
    CLIENTS --> HTTP["HTTP: Cisco FMC, GCP (OAuth 2.0)"]
    CLIENTS --> UVX["uvx: Grafana, AWS, Prometheus"]
    CLIENTS --> NPX["npx: Microsoft Graph, RFC Lookup"]
    CLIENTS --> DOCKER["Docker: GitHub"]
    CLIENTS --> FAST["FastMCP (streamable HTTP): nmap, SuzieQ, GNS3"]

What MCP Is

MCP is an open standard, introduced by Anthropic, that standardizes how AI applications integrate with external systems — often described as "USB-C for AI tools." It replaces bespoke, one-off integrations with a single protocol so a host can plug into any conforming server. The architecture has three roles. The host is the AI-enabled application (here, NetClaw built on OpenClaw with Claude) that manages the user session and agent logic. The MCP client is a component inside the host that speaks the MCP spec; the host creates one client instance per server, each maintaining a dedicated connection. The MCP server is a separate process that exposes capabilities — tools (callable operations with typed parameters), resources (readable data endpoints), and prompts (reusable templates) — and does the hard work of talking to an external system such as F5 BIG-IP, AWS, or Grafana.

Critically, MCP splits into two decoupled layers. The data layer defines the JSON-RPC 2.0 protocol: lifecycle, capability discovery, and the tool/resource/prompt/notification primitives. The transport layer defines how those messages travel — STDIO for local processes, or HTTP/SSE for networked services. Because the layers are independent, identical server logic can run over either transport, and the LLM itself never needs to be MCP-aware.

Transports: Why NetClaw Is stdio-First

NetClaw is emphatically stdio-first. Per the README, all MCP servers communicate via stdio (JSON-RPC 2.0) through scripts/mcp-call.py. In STDIO transport the host spawns the server as a child process and exchanges JSON-RPC messages over the process's stdin and stdout. That design choice is deliberate and load-bearing: stdio has no listening socket, so it avoids port conflicts across 113 servers; it is stateless with no persistent connections; and it simplifies sandboxing. Because each server is just a spawned command rather than a network service, NetClaw can wrap invocations in kernel-level systemd confinement without container overhead — a lighter isolation model than running dozens of daemons behind a reverse proxy.

Not every integration can be local, so NetClaw layers additional transports where the upstream demands it:

• HTTP / Remote HTTP — Cisco FMC runs as an HTTP server on port 8000; GCP services use remote HTTP endpoints hosted by Google with OAuth 2.0; ThousandEyes' official endpoint is Cisco-hosted; Kubeshark requires a remote HTTP endpoint inside a Kubernetes cluster.
• uvx — the uv package manager's one-off runner provides reproducible Python environments for Grafana, AWS services, AAP, Prometheus, PagerDuty, and Splunk.
• npx — Node's package runner launches Node-based servers such as Microsoft Graph, RFC Lookup, and Chrome DevTools.
• Docker — GitHub runs as a containerized server.
• FastMCP (streamable HTTP) — HumanRail, nmap, SuzieQ, GNS3, CML, and fwrule stream MCP messages over a single chunked/SSE HTTP response for efficient handling of large or long-running results. (General FastMCP HTTP specifics here are illustrative of the framework's streaming model.)

JSON-RPC 2.0 Tool Invocation

Every MCP message — regardless of transport — is a JSON-RPC 2.0 object carrying "jsonrpc": "2.0". A request names a method, supplies params, and includes an id to correlate the response. Tool discovery uses tools/list; invocation uses tools/call, naming the tool and passing arguments as a named-object params (preferred over positional arrays because it is self-describing and robust to schema evolution). A NetClaw call to run a pyATS learn operation on a device looks like this:

{
  "jsonrpc": "2.0",
  "id": 42,
  "method": "tools/call",
  "params": {
    "name": "pyats_run_show_command",
    "arguments": {
      "device": "core-rtr-01",
      "command": "show ip route",
      "os": "iosxe"
    }
  }
}

The server replies with a matching id and a result, or an error object with a numeric code — standard codes include -32600 (invalid request) and -32601 (method not found). Notifications (a message with no id) travel one-way for progress and logging and receive no reply. In client configuration, each server is declared as a command to spawn. A representative openclaw.json stdio entry:

{
  "mcpServers": {
    "pyats": {
      "command": "python",
      "args": ["mcp-servers/pyats/server.py"],
      "transport": "stdio",
      "env": {
        "PYATS_TESTBED": "/home/user/.openclaw/testbed.yaml"
      }
    }
  }
}

sequenceDiagram
    participant Host as "Host (MCP client)"
    participant Server as "MCP server process"
    Host->>Server: "tools/list (discover tools)"
    Server-->>Host: "result: available tools"
    Host->>Server: "tools/call id=42 (pyats_run_show_command)"
    Server-->>Host: "notification: progress (no id)"
    Server-->>Host: "result id=42 or error code"

Domain Coverage

The 113 servers span the full operational surface of a modern network. The counts below are per the README; because several categories bundle multiple sub-servers (Check Point alone contributes 15, AWS 6, Cloudflare 5, GCP 4), the per-row figures overlap and nest rather than summing cleanly — 113 is the authoritative total.

Ephemeral Processes and Polyglot Implementations

Because stdio servers are spawned per invocation, NetClaw follows an ephemeral process model: each tool call spins up a fresh process that exits when the work is done — no long-lived daemons, no accumulated state, and a clean isolation boundary for every operation. Figure 5.3 — Ephemeral process lifecycle: spawn per tool call, exchange over stdio, exit clean.

stateDiagram-v2
    [*] --> Spawned: "tool call received"
    Spawned --> Serving: "stdio JSON-RPC exchange"
    Serving --> Exited: "work done, process exits"
    Exited --> [*]: "no residual state"

This dovetails with production hardening (feature 057), which enforces N2N_RISK_MODE=production and applies host-level kernel confinement through a hardened systemd unit and transient systemd-run instances for on-demand federation members. It is also why the README insists NetClaw run as a normal user, not under sudo — otherwise config, API keys, and skills land in /root/.openclaw where the user's own agent cannot see them.

MCP's language-agnostic design lets NetClaw be genuinely polyglot. Most domain servers — pyATS, NSO, ServiceNow, gNMI — are Python, frequently built with FastMCP's decorator API (@mcp.tool, @mcp.resource) where mcp.run() starts a stdio loop and schemas are auto-generated from type hints. GitHub and Grafana are Go binaries; Microsoft Graph, Chrome DevTools, the Check Point suite, and Twilio are Node.js. The host does not care which language a server is written in — it only sees JSON-RPC over a transport — so each integration can be implemented in whatever ecosystem its upstream SDK lives in. That freedom, more than any single feature, is what makes 113 heterogeneous integrations tractable under one roof.

References