NetClaw: An OpenClaw-Based Network Engineering Agent with 227 Skills
An AI agent that claws through your network
At a glance
- What is it?
- NetClaw is a Python-installed AI agent for network engineering that runs on top of OpenClaw or Hermes and wires Anthropic Claude to a large catalogue of MCP integrations. The installer's profile system is the interesting part; the README's scope is the part to read carefully before adopting.
- Who is it for?
- Adopt NetClaw if you already run OpenClaw or Hermes and want a curated set of network MCP servers registered for you, and start with the Minimal or Recommended profile rather than Everything. Do not adopt it if you need a stable documented API surface, a released version to pin, or the n2n federation on a Hermes runtime, since the README states that subsystem is not yet ported.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 9 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The Problem NetClaw Targets: Gluing Network Tools to an LLM
Standing up an LLM agent for network work means registering MCP servers, wiring credentials, and keeping a skill library consistent across pyATS, NetBox, ServiceNow, and a dozen vendor APIs. NetClaw's answer is an installer that does that registration for you. The README describes it as a CCIE-level AI network engineering coworker built on OpenClaw with Anthropic Claude, 227 skills, and 173 MCP integrations, and the install script is the actual product surface. If you have already decided to run an agent runtime and now need the network side of it populated, this is the gap it fills. If you have not decided that, NetClaw is not a standalone tool: it assumes a runtime, a Claude key, and a tolerance for a very wide integration list.
How NetClaw Sits on OpenClaw or Hermes
NetClaw is not the agent. OpenClaw is the default runtime and the fully integrated path; Hermes from Nous Research is offered as an alternative. The two differ in concrete ways the README tabulates: OpenClaw installs with npm install -g openclaw@latest, keeps state in ~/.openclaw/, reads openclaw.json, and stores skills in workspace/skills/; Hermes installs from a shell script, keeps state in ~/.hermes/ (overridable with $HERMES_HOME), reads config.yaml under an mcp_servers: key, and stores skills in skills/. The installer translates NetClaw's MCP registrations from config/openclaw.json into Hermes' mcp_servers: block using scripts/openclaw-to-hermes-mcp.py, which makes paths absolute, resolves ${VAR} references from the shared .env, and merges non-destructively. You can check the result with hermes mcp list. The README is explicit that this translation covers install, onboarding, gateway, MCP registration, skills, and credentials, and that the n2n/iN2N federation subsystem is OpenClaw-native and not yet ported. That is a real functional boundary, not a footnote.
Install Profiles and the Interactive Component Checklist
The install path is a git clone followed by ./scripts/install.sh. The script opens a pure bash TUI, with no dependency on dialog or whiptail, where you pick a profile and then optionally fine-tune the MCP server list in an arrow-key checklist (Space toggles, a selects all, n selects none). Only what you select is installed. Profiles include Recommended (pyATS, NetBox, ServiceNow, GAIT audit trail, Chrome DevTools, nmap, diagrams, utilities), Minimal (pyATS, audit trail, core utilities), Cisco, Multivendor, Cloud, Security, Labs, Observability, Custom, and Everything. Scripted installs bypass the TUI: ./scripts/install.sh --profile recommended, ./scripts/install.sh --components "pyats netbox", ./scripts/install.sh --all, and ./scripts/install.sh --list to enumerate components and profiles. The runtime is selected either interactively or with --runtime hermes, or by setting NETCLAW_RUNTIME=hermes in the environment. One operational rule is stated bluntly: run it as your normal user, not with sudo, because under sudo OpenClaw's config, your API keys, and all skills land in /root/.openclaw where your own openclaw cannot see them. The installer refuses to run under sudo and asks before each command that needs root.
The Breadth of the Integration List Is the Main Trade-off
The README enumerates integrations across Cisco (CML, NSO, SD-WAN vManage, Meraki, ThousandEyes, Catalyst Center, ISE, ACI, FMC, Secure Firewall, RADKit), Juniper JunOS, Arista CloudVision, F5 BIG-IP via pyATS iControl REST, Palo Alto Panorama, FortiManager, Check Point, Infoblox DDI, Batfish, ContainerLab, Grafana, Prometheus, Kubeshark, Datadog, Splunk, AWS and Azure, GitHub, GitLab, Jenkins, Slack, WebEx, Microsoft 365, Twilio, and more, plus telemetry paths (gNMI streaming, NetFlow/IPFIX), an offline agentic RAG knowledge base, memory layers, and out-of-band console management. That list is the value proposition and the risk in one. Each entry is a credential surface and a moving dependency. The profile system exists precisely because installing everything is a poor default: the README frames Recommended as a curated starter set and Everything as the classic full install. Nothing in the supplied material describes per-integration test coverage, version pinning, or what happens when a vendor API changes, so treat any specific integration as unverified until you exercise it against your own environment.
A Risk of NetClaws: Splitting One Agent into Many
The README introduces iN2N, described as a risk of NetClaws (a risk being the collective noun for lobsters). Instead of one agent carrying every skill, you run focused member claws, each owning a capability such as CML, pyATS, or Azure, coordinated by a Border Claw. You talk only to the Border, which routes each request to the member that owns it and returns the result. The stated motivations are focus and token economy, since each member carries a handful of skills rather than around 190, and least privilege, since each member holds only its own credentials. The README text is truncated mid-sentence at the least privilege bullet, so the routing protocol, failure handling, and deployment mechanics of iN2N are not described in the material available here. Combined with the note that the federation subsystem is OpenClaw-native and not ported to Hermes, iN2N should be treated as the least documented and least portable part of the project.
Maintenance, Licensing, and What the Repository Does Not Tell You
NetClaw is Apache-2.0, which permits commercial use and modification and includes an explicit patent grant, with the usual requirements around preserving notices and stating changes. That is the licence text, not advice about your situation; if you redistribute a modified NetClaw inside a product, have counsel read the NOTICE and attribution requirements rather than assuming the permissive label settles it. On maintenance, the repository shows a last push of 2026-09-06 and no retrieved releases, so there is no version to pin and no changelog to diff against. Upgrades therefore mean re-running the installer or pulling main, and the installer's non-destructive merge of MCP registrations is the mechanism that decides whether your local edits survive. The README also points to a single external community guide at seanmahoney.ai for an overview, and the homepage field is empty. There is no stated support policy, no compatibility matrix for the 173 integrations, and no migration notes. Budget for reading scripts/install.sh and scripts/openclaw-to-hermes-mcp.py before you run either against a machine you care about.
Where NetClaw Is the Wrong Tool
If your requirement is a deterministic pipeline that runs the same way on every invocation, an agent that selects tools from a 227-skill catalogue is the wrong shape. If your environment is Windows-first, or you cannot install Node for OpenClaw or run a shell installer for Hermes, the documented install paths do not apply. If you need one specific integration and nothing else, cloning a repository of this breadth to reach a single MCP server adds surface area you will then have to audit. And if you want the multi-agent iN2N topology, note that the README's own scope statement excludes it on Hermes, so the runtime choice constrains the architecture. A narrower alternative in the same space is to skip the meta-installer and register the individual MCP servers yourself in openclaw.json or config.yaml: more setup work, but you control exactly which servers, which credentials, and which versions exist on the host, and you never inherit a component you did not choose.
Editorial conclusion
Adopt NetClaw if you already run OpenClaw or Hermes and want a curated set of network MCP servers registered for you, and start with the Minimal or Recommended profile rather than Everything. Do not adopt it if you need a stable documented API surface, a released version to pin, or the n2n federation on a Hermes runtime, since the README states that subsystem is not yet ported. Before trusting it, run ./scripts/install.sh --list to see the full component set, then inspect config/openclaw.json to confirm exactly which MCP servers and credentials the profile you chose writes.
Community notes