I saw something in MCP. Then I spent 18 months building it.

TL;DR: In March 2025, my first working MCP connection made me see a different future for network operations. Eighteen months of open-source experiments became NetClaw and a talk at MCP Dev Summit Toronto. The engineering now goes well beyond connecting tools: it is about evidence, scoped authority, useful interfaces and honest failure handling. Since returning home, I have already brought NetClaw into Visual Studio Code. There is more to build.

On October 6, 2026, I stood at MCP Dev Summit Toronto presenting NetClaw, an open-source network engineering agent. The room was packed. People were watching closely. I was nervous and super excited. It was on.

Looking at the photo from that talk, I found myself thinking about a post I had written eighteen months earlier, after getting my first MCP server and client working: “I see it now.” There were repositories, workshops, late nights, bugs, rewrites and more experiments than I probably needed to start between those two moments. The journey was the reward.

Figure 1. NetClaw on stage in Toronto, October 6, 2026. From my event photo gallery.

I did not invent MCP. Anthropic did. Nor am I suggesting that Cisco, OpenAI or anyone else adopted it because of my work. But I recognized something early, specifically for networking, and spent the next eighteen months building around it. Watching other engineers independently arrive at similar conclusions has been deeply satisfying.

The question that kept me at the keyboard became the question at the center of my Toronto talk: how can an AI agent reason about and operate real networks in a way an engineer can inspect, authorize and trust?

I see it now

When Anthropic open-sourced Model Context Protocol in November 2024, it addressed a familiar integration problem. Connecting an AI system to another tool or data source usually meant writing another custom integration. MCP offered a common interface. Whether enough people would adopt it was still an open question.

My first working connection in March was exciting, but combining servers was what hooked me. I connected Packet Copilot MCP to GitHub MCP so an agent could analyze a packet capture, use network tooling and put the resulting report in GitHub. Capabilities that normally lived in separate places could participate in one workflow.

At the time, I called it “The Internet of AI Agents.” Sequential Thinking, Slack, Google Maps, dynamic tool discovery and retrieval-assisted tool selection followed. Within days, I publicly admitted: “I was wrong about MCPs… they are better than I thought!”

As a network engineer, I kept reaching for comparisons to DHCP and OSPF. The analogy was imperfect, but the appeal was familiar: use a protocol to learn what is available instead of hardcoding every relationship. MCP discovery does not supply routing, trust or permission by itself. It gives a client a way to discover capabilities exposed by the servers it connects to. That was enough to start experimenting.

Bringing it into the network

On April 5, 2025, I built pyATS_MCP. Looking back, that was probably the most important technical milestone in this journey.

I had already spent years working with Cisco pyATS and Genie, teaching them, writing about them and eventually co-authoring “the official” Cisco Press book. Putting pyATS behind an MCP interface felt natural. An agent could run show commands, gather structured state, ping devices, learn about the network and access configuration tools through a foundation I understood.

Language models are probabilistic. Operating a network requires evidence about what is actually happening. pyATS and Genie could supply structured observations; MCP could give an agent a standard way to request them. A parsed response still needed a timestamp, a source and an interpretation. A successful command still needed verification. Those responsibilities became part of the design.

I wanted other engineers to try it themselves. Du’An Lightfoot and I recorded a discussion about MCP and the “Internet of AI Agents.” At ONUG, I taught and talked about MCP, A2A and RAG. Videos became workshops, experiments became repositories, and questions from other engineers gave me more things to build.

In May, I published MCP servers for Cisco ISE and ACI. The ISE server exposed API resources as discoverable tools. At launch, I described ACI MCP as providing 65 tools covering more than 250 API endpoints. The opportunity was to bring those systems into investigations that could also use packet analysis, inventory and documentation.

The first domino

Another May milestone changed my own direction. On May 28, 2025, Itential publicly launched its MCP Server at AutoCon 3 in Prague. Its open-source release preceded the event.

That was the first domino in me joining the company. I'd been spending my nights and weekends exploring MCP for networking, while Itential was connecting AI requests to workflows, validation and approvals. That matched the question I cared about: how do we make this useful on real infrastructure?

The work mattered more to me than the announcement. The support I've had since joining has helped me keep developing NetClaw in the open, teaching and sharing what I learn. There is a direct personal line from that AutoCon 3 launch to my standing on stage in Toronto with NetClaw.

Watching the idea take hold

Meanwhile, MCP was entering the tools people used every day. OpenAI added remote MCP support to the Responses API in May 2025. In July, MCP support became generally available in VS Code with GitHub Copilot.

Cisco’s professional automation certification direction included building MCP servers and agents for network automation. In November, Cisco introduced an MCP server for Cisco Modeling Labs, using the CML API and pyATS underneath. Seeing those familiar building blocks appear in an independently developed architecture meant a lot.

At AutoCon 4, Senad Palislamovic jokingly called me the “father of MCP” in the networking community, while making clear that I had not invented the protocol. It is a title I would never give myself. What I appreciated was recognition of the work: the code, videos, posts and workshops, and the effort to bring network engineers into the conversation.

In December 2025, MCP joined the Linux Foundation’s Agentic AI Foundation. By the following summer, Cisco was announcing Meraki and Catalyst Center MCP servers. The idea was becoming useful well beyond my own experiments.

How those experiments became NetClaw

By early 2026, I wanted to bring the pieces together: pyATS, MCP, network APIs, observability, security, documentation and visualization. In February, that became NetClaw, an open network engineering agent organized around skills, tools, evidence and constraints.

By March 26, the project had 97 skills and 43 MCP integrations. A development cycle involving SuzieQ, Batfish, gNMI, Azure Networking and visualization brought it to 101 skills and 46 integrations. By September, there were 227 documented skills, enough that I pointed an automated evaluation project at the collection. Those are historical checkpoints, not measures of production readiness.

The more consequential change was my engineering method. I moved toward spec-driven development: describe the behavior, define the acceptance evidence, implement it, and bring the tests, installer and documentation along. At AutoCon 5 in Munich, my workshop, “From RAG to MCP: New Tools for a New Era in Network Operations,” put those ideas into engineers’ hands.

Several design decisions now shape NetClaw.

Give tools a method

A tool exposes an operation. A skill supplies the method around it: what question to investigate, which observations to collect, what constraints apply, and what would establish a useful result. That distinction matters when a catalog grows. Finding a configuration tool does not tell an agent whether it should use it.

Consider a BGP incident as an example of the method I want. Gather current neighbor state, compare it with the intended design and relevant observations, and explain the evidence behind a suspected cause. If a change is justified, make its target, expected effect, approval requirement and verification steps explicit. After execution, collect new observations. A returned tool result is one piece of that process; it cannot stand in for the whole investigation.

Keep runtime choice separate from network expertise

NetClaw can run on OpenClaw or Hermes. The harness provides the runtime around the model: conversations, execution and state. NetClaw brings the networking skills and integrations into that environment. MCP gives those integrations a shared interface. The architecture and runtime documentation explain the supported paths.

This separation lets engineers choose an environment that fits their work while keeping the networking knowledge reusable. It also creates a compatibility obligation. Installing the same catalog on two harnesses does not prove that every execution path behaves identically, and a native harness feature is not automatically available inside a protected NetClaw profile.

Let agents cooperate within explicit boundaries

I call a group of NetClaws a Risk (the real collective noun for a group of lobsters). A Border coordinates members with narrower responsibilities. NCFED, the NetClaw-to-NetClaw Federation protocol, distinguishes internal Border-to-member cooperation, iN2N, from external peer cooperation, eN2N.

The aim is to give a task to a member with the relevant tools and scope, while keeping its authority understandable. The Hermes federation implementation makes a useful distinction: installed capabilities, advertised capabilities and capabilities qualified to execute are different things. A capability card describes a peer. It does not grant permission or choose a local execution runtime.

Figure 2. Runtime choice and the shared NetClaw foundation. This diagram describes the broader harness ecosystems; native Hermes memory and tools are not automatically enabled in its protected federation profile. Diagram source.

Figure 3. The federation design supports different Border and member runtimes. Roles in the diagram are illustrative; each exposed capability needs its own authorization and qualification. Diagram source.

Treat uncertain outcomes as engineering work

One of the most useful questions in this project has been: what happens if the connection disappears after dispatch?

A lost response does not tell us whether an operation happened. In the recent Hermes and mobile work, the client records a request identifier before sending. Recovery looks up the original admission and owned result. It does not blindly submit the work again. A requested cancellation is also distinct from a confirmed cancellation.

That behavior came from testing failure, not just the successful demonstration. The verification record describes a process-loss test that exposed a queued receipt surviving after its worker had died. The correction made the uncertainty visible. An honest unknown gives an operator something to investigate; a misleading spinner hides the decision they need to make.

Figure 4. The acceptance model follows authorized work through execution and evidence. Permission denial prevents dispatch; a lost response requires investigation rather than automatic replay. Diagram source.

Your mileage will vary

There is a lot of enthusiasm in this story. There are also boundaries I want engineers to understand before they try it.

Start with a specific question and a small lab. Model choice, device software, parsers, credentials, network access and installed components all affect the result. A skill count says little about whether one integration can answer your question. Establish read-only behavior and inspect the evidence before expanding scope.

Keep safety controls outside the model’s promises. MCP standardizes interaction; a successful connection does not establish that an action is authorized or safe. Skills describe behavior, but permissions, tool restrictions, approval gates and execution controls need implementation and verification. For changes, preserve a baseline, understand the rollback procedure and verify the resulting network state.

Read the scope of the tests. The Hermes federation work exercised all four internal OpenClaw/Hermes runtime pairings using real runtimes and a real subnet MCP tool against a controlled local provider. Its initial protected tool profile is read-only IPv4 subnet calculation from /24 through /30. That evidence does not qualify every advertised integration, production configuration changes or every physical mobile device. Production Hermes model-guard and confinement qualification remains pending and fails closed. The published acceptance record states those limits.

Treat observations as observations. A document may describe intended design; it does not establish current device state. A topology view represents its source data. An empty response may mean missing evidence. I want NetClaw to make those distinctions visible because engineers need them to decide what to do next.

These caveats are part of making the project useful. Every limitation we can name precisely gives us something concrete to improve.

Back from Toronto and already building

In the short time I have been back from the event, I have already released a Visual Studio Code extension for NetClaw. Version 0.1.1 brings operations into a familiar IDE, alongside the scripts, inventories and notes engineers already work with.

It connects to an existing NetClaw through its HUD API. Chat, Canvas investigations, RAG search, Testbed management, per-MCP setup and reviewed security controls are available in the workbench. The selected NetClaw keeps its runtime, model and operational rules. The extension guide explains setup and supported environments.

Figure 5. NetClaw in Visual Studio Code. This acceptance screenshot uses synthetic inventory and isolated test policies. Release story and screenshots.

Some of the most important work is easy to overlook in a screenshot. Review the installation identity before connecting. Preview an inventory change before saving. Keep existing secrets private. Show which host and runtime a control affects. Saving a Testbed does not connect to a device; saving a security policy does not prove that traffic enforcement works. Those distinctions make an operations interface understandable.

The release also taught me to be precise about evidence. Its qualification record separates installed Mac interface testing from actual vendor security enforcement tested on WSL. Bringing operations into an IDE should make those boundaries easier to inspect.

Figure 6. The Toronto community is part of the story. From my event photo gallery.

What I want to build next

The extension is a step toward the next version of this idea: a network engineering coworker that fits into daily work and can show why its results deserve confidence.

I want to deepen qualification as deliberately as I once expanded the tool catalog. That means more reproducible investigations, more checks of evidence quality, and more failure cases involving stale data, interrupted execution and recovery. I want an engineer to see what a capability has actually demonstrated before deciding to rely on it.

I also want to keep developing federation with focused members and explicit ownership. A Border per customer or operational domain is an interesting direction for managed services. The proposed MSP architecture helps frame that discussion. It is a proposal: separate credentials, storage, grants, approvals and recovery would need their own isolation and acceptance evidence. Connecting peers is only the beginning of that work.

And I want to keep bringing NetClaw to the places engineers already use. VS Code gives an investigation a home beside its code and inventory. Mobile and other interfaces raise further questions about continuity: can someone leave, reconnect and understand what happened without repeating uncertain work? That is a practical problem worth solving carefully.

I want to build those answers in the open. Try a bounded use case. Inspect the sources. Tell me where the method fails. Contribute a skill, a test or an improvement to the documentation. The next useful contribution may be a better explanation of a limitation rather than another integration.

On September 25, I took inventory: 49 repositories and labs, 37 MCP-related videos and 30 original articles. I had not set out to reach those numbers. One experiment kept leading to another, and I kept publishing what I learned.

I am proud that I stayed with it. I rewrote code, modernized transports, found bugs and abandoned ideas that did not survive contact with reality. I taught things while they were changing underneath me and learned from the people who tried them.

Thank you to Angie Jones and the event team for the opportunity in Toronto. To Chris Wade, Kristen H. Rachels, Jessica Newland and everyone at Itential supporting NetClaw: you have helped make this work possible. And thank you to Sebastian Maniak and Eric Pilon for being there and capturing the moment.

Back in March 2025, I wrote, “I see it now.” I still do. Today there is more code behind that feeling, a much bigger community around it, and an open-source lobster helping engineers work with networks.

I am going to let myself be proud of this one. Then I am going back to building—with a clearer idea of what the next eighteen months need to prove.

Explore NetClaw, install the VS Code extension, or read the Toronto presentation.

More MCP in San Jose

John's Toronto talk was one example of what people are building with MCP. There'll be plenty more to hear about at AGNTCon + MCPCon North America in San Jose, October 22–23.

• When Agents Spawn Agents: Securing Recursive Delegation in Multi-Agent Systems with Anishma Mavuram
• Governing AI Agent Actions: MCP and Beyond Workshop with Shannon Williams and Bill Maxwell
• Why the Heck Aren't Any Agents Supporting MCP Tasks? with Cornelia Davis

Register and use OUTREACH25 to save 25%.