I Saw Something in MCP. Then I Spent 18 Months Building It.

This photo isn't a victory lap. It's a timestamp.

On March 17, 2025, I wrote:

“I just setup my first working MCP Server and client!”

A few words later:

“I see it now.”

I really did. Within days I was connecting MCP servers together and talking about an “Internet of AI Agents.” Then I spent the next eighteen months trying to prove the idea through code rather than predictions: pyATS MCP, ISE MCP, ACI MCP, packet analysis, videos, articles, repositories, workshops, and eventually NetClaw.

Today, October 6, 2026, I stood at MCP Dev Summit Toronto presenting NetClaw: An Open Network Engineering Agent. The title on my deck tells you the architectural thread running through the session: NETCLAW — MCP at the Center of Agentic Network Operations.

The question at the heart of it was straightforward: how do we safely let an AI agent reason about and operate real networks?

The answer has taken considerably more work.

What I am proud of

I did not invent MCP. Anthropic created and open-sourced the protocol. I am not claiming that Cisco, OpenAI, GitHub, or anybody else followed me.

What I am proud of is simpler. I saw enormous potential in this architecture, specifically for networking, and invested my time in building, breaking, teaching, publishing, and open-sourcing around the idea. Then I watched independent parts of the industry converge on many of the same ideas.

That is worth stopping for a moment and appreciating. It is also worth documenting with dates and links, because a timeline makes the difference between a memory and a record.

November 25, 2024: the protocol arrives

Anthropic introduced Model Context Protocol on November 25, 2024. The problem was familiar: connecting an AI system to another source of data or another tool meant writing another integration. MCP provided an open interface that clients and servers could implement instead.

For a network engineer, that was an intriguing proposition. Our environments already contain capabilities scattered across device CLIs, controllers, inventories, APIs, telemetry systems, and documentation. The hard part is rarely finding another tool. It is connecting the right tools to the right question and preserving the context between them.

But MCP was new. There was no guarantee it would become broadly adopted, no established conference circuit, and no reason to assume that the first implementation would be the final answer. The opportunity was visible; the outcome wasn't.

March 2025: “I see it now”

My first working server and client changed the way I looked at that integration problem. Almost immediately, I started asking what would happen when these things composed.

On March 18, I connected Packet Copilot MCP to GitHub MCP. An agent could analyze a packet capture through one set of capabilities and create a report in GitHub through another. By March 19, I was describing the direction as an “Internet of AI Agents.” The opening timeline in the Toronto presentation preserves those milestones.

What mattered was the handoff. Packet analysis did not have to live in an isolated application. Reporting did not have to be a separate manual step. The assistant could work across capabilities with a common interface.

Then the experiments multiplied: Sequential Thinking, Slack, Google Maps, dynamic tool discovery, and retrieval-assisted tool selection. My MCP workbench brings those videos, repositories, and articles back together so the progression is easier to follow.

I also changed my mind in public. On March 27, I wrote that MCP was better than I had originally understood. In that original post, I explained the shift from statically mapping tools to discovering capabilities through the protocol.

DHCP and OSPF were useful analogies for a networking audience: protocols help systems learn information instead of making every relationship a hard-coded assumption. MCP tool discovery is not a routing protocol, but that comparison captured why it felt so familiar to me.

Discovery, composition, and abstraction. That was the moment this stopped being a curiosity.

April 5, 2025: pyATS meets MCP

This remains one of the most important technical milestones in my personal timeline. I built pyATS_MCP, putting Cisco pyATS and Genie behind an MCP interface.

I had already spent years working with those technologies, teaching them, writing about them, and co-authoring a book about them. Now an agent could use that foundation to gather device state, run show commands, ping, learn network information, and perform controlled configuration work.

The combination felt natural. Language models reason probabilistically; network operations depend on evidence. pyATS and Genie can collect and parse device observations into structured information. MCP gives the agent a standard interface to those capabilities.

Reasoning on one side. Evidence and controlled action on the other.

There are still engineering responsibilities in between. A parsed response is only as current as the observation. A successful tool call is not proof that the network is healthy. A proposed change still needs a baseline, the right authorization, and a verification step. Putting a tool behind MCP does not erase any of those obligations.

That pattern—make the evidence available, make the method explicit, and constrain the action—has guided my work ever since.

Spring 2025: start teaching it

I wanted network engineers building with MCP, not only watching me demonstrate it. So the work expanded into videos, repositories, workshops, and conversations.

Du'An Lightfoot and I discussed An Internet of AI Agents. At ONUG's Spring 2025 summit, I was teaching and discussing MCP, A2A, and retrieval-augmented generation for network engineers. The event archive preserves the session and workshop links; the MCP collection connects them to the code and demonstrations.

Teaching exposed the assumptions I had stopped noticing. What does the client discover? What does the server actually execute? Where do credentials live? What happens when a tool returns an empty result? Which decisions belong to the engineer?

Those questions improved the implementations. Every workshop was another chance to test whether an idea that made sense on my laptop could make sense to someone else.

May 2025: deeper into the network stack

On May 16, I published ISE_MCP. Instead of stopping with a few hand-written actions, the project exposed Cisco Identity Services Engine API resources as discoverable MCP tools: endpoints, identity groups, network devices, and policy information.

On May 19 came ACI_MCP. My launch description counted 65 tools covering more than 250 ACI API endpoints. Those are historical launch figures, not a promise that the current repository has exactly the same interface.

ACI mattered personally because of my history with the platform. I wanted its operational capabilities to be available in a workflow that could also include inventory, packet analysis, documentation, and other systems. A natural-language interface was useful, but composability was the larger opportunity.

Open source made the experiments available to people beyond my own environment. Someone could inspect the implementation, disagree with it, adapt it, or carry it farther. That is why I publish this work.

May through August 2025: independent convergence

On May 21, OpenAI added remote MCP support to the Responses API. That made it possible to connect those models to tools hosted on remote MCP servers. The announcement also noted OpenAI's participation in the MCP steering committee.

On July 14, GitHub announced generally available MCP support in VS Code, starting with VS Code 1.102. The architectural idea I had been experimenting with in clients and Python projects was becoming part of everyday developer tooling.

Then Cisco put MCP development into its professional automation certification direction. Quinn Snyder's August 6 explanation of the reimagined CCNP Automation track described the importance of building MCP servers and agents capable of network automation. The exam topics had been released at the end of July.

That one hit differently. In April, I had put pyATS behind MCP. A few months later, Cisco was explaining why MCP server development belonged in the skills expected of network automation engineers.

I am not suggesting one caused the other. What mattered was that an independent assessment of the profession's direction landed near the place I had chosen to spend my nights and weekends exploring.

November 2025: labs, pyATS, and a moment at AutoCon

On November 17, Cisco announced its CML MCP server. It connected natural-language interactions to lab creation, node configuration, topology startup, and device commands. Cisco described the CML API and pyATS as the mechanisms underneath that work.

From my perspective, the progression was remarkable. Earlier in the year I had explored a path from an agent, through MCP, into pyATS and the network. Now Cisco was publishing a lab implementation using those same building blocks. Independent convergence can be more meaningful than credit: it tells you an idea is useful outside your own experiments.

At AutoCon 4 in Austin that November, Senad Palislamovic generously—and jokingly—called me the “father of MCP” in this networking community, while acknowledging that I had not invented the protocol. The MCP archive preserves the recording and context.

That is not a title I would give myself. The history of MCP belongs to its creators and maintainers. What meant something to me was the recognition of the sharing: the experiments, code, posts, videos, workshops, and willingness to bring networking into an emerging world before we knew where it would lead.

December 2025: the scale changes

On December 9, MCP joined the Agentic AI Foundation under the Linux Foundation. The project reported more than 97 million monthly SDK downloads, 10,000 active servers, and support across major AI clients and developer tools.

Those are dated ecosystem measurements. Downloads do not count unique developers, organizations, or production deployments. But the direction was unmistakable: this had grown far beyond a small set of experiments.

For me, the useful question was becoming less about whether a client could call a tool and more about how to organize a growing collection of capabilities into dependable engineering work.

February and March 2026: the threads become NetClaw

pyATS, MCP, network APIs, observability, security, documentation, visualization, human approval, and multi-agent systems were beginning to connect in my work. I wanted one open network engineering agent that could bring those ideas together. In February 2026, that became NetClaw. 🦞

The project gave me a place to work on skills, tools, evidence, constraints, and integrations as parts of the same system. It also made the cost of inconsistency much easier to see. A capability added to the code but missing from the installer or documentation is not a finished capability for the person trying to use it.

By March 26, my development record counted 97 skills and 43 MCP integrations. A move toward spec-driven development, applied to SuzieQ, Batfish, gNMI, Azure Networking, and visualization, brought that iteration to 101 skills and 46 integrations. The NetClaw writing collection preserves the engineering stories behind that period.

In March 2025, I was asking whether I could make the connection work. A year later, I was asking how to govern and safely scale what I had connected.

That changed the method. The Toronto deck describes a discipline of one item, one specification, and one branch, with verification and documentation treated as part of the work. Speed is useful only when you can still explain what you built.

June through September 2026: teaching and adoption keep growing

At AutoCon 5 in Munich, the workshop was From RAG to MCP: New Tools for a New Era in Network Operations. MCP was part of the curriculum, with hands-on networking work at its center. The AutoCon 5 event record links to the workshop archive.

In its July 28 specification announcement, the MCP project reported close to half a billion monthly downloads across Tier 1 SDKs. Both the TypeScript and Python SDKs had crossed a billion cumulative downloads. Again, those are SDK download figures, not a count of people. Even with that distinction, the growth was substantial.

On August 10, Cisco announced Meraki and Catalyst Center MCP servers. Its explanation put the distinction in practical terms: a product's own assistant serves work inside that product, while MCP can bring network information into a broader workflow built around it. The announcement covered hosted and open-source options for Meraki and local deployment for Catalyst Center.

That is the opportunity that originally excited me: make capabilities available where the work happens, instead of requiring a person to manually carry context between every product.

By September 25, my own MCP archive documented 49 repositories and labs, 37 related videos, and 30 original articles. Those were the counts at that checkpoint. NetClaw had reached 227 documented skills, enough that I pointed an automated evaluation project at the entire collection.

The numbers accumulated because I kept pulling the thread. They are a record of work, not a substitute for checking whether an individual integration does the job someone needs.

October 6: what I brought to Toronto

The Toronto presentation records another checkpoint: 233 skills and 173 MCP integrations in the NetClaw 1.1.0 catalogue. It places those capabilities inside an engineering method rather than treating a long tool list as the result.

A skill should explain the question it answers, the tools it can use, the order of investigation, the constraints on action, and what the output does or does not establish. A network operator should be able to follow that reasoning back to observations.

One example in the deck is out-of-band management. The console server and the router attached to its serial port are different devices. A useful skill must know which system it is operating, whether a task is asynchronous, and where a command will actually land. Merely discovering that two tools exist does not supply that judgment.

The same care applies when things fail. An empty or unconfirmed response cannot be presented as a healthy result. Missing evidence and a failed check are different outcomes. A stale observation needs to look stale. A dropped connection needs bounded recovery, and a write needs the appropriate human decision. These are design requirements to implement and verify, not properties a protocol automatically guarantees.

The later part of the talk explores federation: focused member agents, a Border Claw, capability discovery, and the NCFED Internet-Draft. It brings me back to the question I asked in March 2025: what happens when these systems compose? Only now the question carries operational responsibilities around identity, scope, recovery, and evidence.

That is what I wanted to share in Toronto. A working connection is the beginning. The engineering around it is what makes it worth using.

Read the complete Toronto presentation →

Video coming soon. The slides and photographs are here now; the session recording will follow.

A few moments from Toronto

Being early isn't the achievement

Some of my early ideas and implementations were wrong. I have publicly changed my mind, rewritten code, modernized transports, found bugs, and abandoned approaches that did not survive contact with reality. That is engineering.

The claim I am comfortable making is narrower and more meaningful to me: I recognized early that MCP could fundamentally change how AI interacted with network infrastructure, and I acted on that belief.

I built. I open-sourced. I made videos, wrote articles, and taught workshops. I connected pyATS, ISE, ACI, packets, diagrams, APIs, and observability systems. I kept going long enough to watch MCP enter mainstream AI platforms, developer tools, Cisco certification objectives, and networking products. I kept going until those threads evolved into NetClaw.

Being early isn't the achievement. Doing something with the time being early gives you is.

Technology has plenty of people who notice trends. The difficult part is committing before the institutional validation arrives: publishing code, teaching while the technology is changing, being willing to look wrong, and continuing to learn when an idea starts working.

In March 2025, I wrote, “I see it now.” In Toronto, I still did. Only now there is a much larger ecosystem around the idea, an Agentic AI Foundation, an MCP Dev Summit, and an open-source lobster helping engineers explore how networks fit into the agentic world.

I'm going to let myself be proud of this one. Then I'm going back to building.

Thank you

Thank you to Angie Jones, her team, and everyone involved in putting on this event and creating such a meaningful opportunity for Canadian innovation.

To my team at Itential—Chris Wade, Kristen H. Rachels, Jessica Newland, and so many more—thank you for the unwavering support. I would not have been able to take this project this far without you.

And a very big thank you to Sebastian Maniak and Eric Pilon for supporting me in Toronto and capturing these moments in time.

The network is becoming part of the agentic world. We're still early. 🦞

---

Keep pulling the thread: The complete MCP workbench · NetClaw code and resources · Talks and workshops · The latest updates