Why MCP matters for networking

What MCP is

The Model Context Protocol, released by Anthropic as an open standard, is a JSON-RPC 2.0 specification for connecting a language model to external tools, data, and prompts in a consistent way. That's a dry sentence for something that solved an annoying problem: before MCP, every integration between an AI application and an external system was custom-built. If you wanted Claude to check a routing table, someone had to write bespoke code for that specific model, that specific vendor's API, and that specific version of both.

MCP standardizes the shape of that connection instead. A device or platform can expose a set of "tools" (things an agent can call, like show_command or get_route_table), "resources" (data an agent can read), and "prompts" (pre-built templates for common tasks). Any MCP-compatible client, whether that's Claude Desktop, an IDE, or a custom orchestration platform, can discover and use them without vendor-specific glue code, which is a big part of why the open source directory of MCP servers has grown as fast as it has.

Why this matters more in networking than most domains

A language model has no innate awareness of your specific network. It knows general facts about BGP and general patterns in Junos syntax, but it has no idea what your topology looks like, what changed last Tuesday, or whether that firewall rule is actually in production. MCP is the piece that closes that gap: a server that exposes live, verified state (routing tables, interface counters, configuration) to a model that would otherwise be reasoning from training data alone.

It also means the model can, in principle, act: not just read state, but push a configuration change, restart an interface, or trigger a packet capture. That's the useful part and the dangerous part at the same time. Several entries in the directory are explicitly about managing that tension: Itential keeps AI reasoning and execution in separate layers, IP Fabric keeps its MCP server read-only against a verified twin rather than a live device. Read the security page before you wire up anything with write access.

Standards work is still early

The IETF and its research arm, the IRTF's Network Management Research Group, are actively looking at how MCP should extend into network equipment specifically. To be precise about what stage this is at: these are individual Internet-Drafts, submitted by their authors for discussion. None of them has IETF consensus, none has been adopted by a working group, and none is a standard you can build a production dependency on today. That will likely change over the next few years, but treat the specifics below as a sketch of where thinking is headed, not a spec to implement against.

Community federation experiments

Standards bodies aren't the only place this is being worked out. The open source project NetClaw takes a different approach to the same underlying problem: how do you avoid building one model that has to understand every vendor's syntax, every protocol, and every tool at once? Its answer is federation: a central agent routes a request to smaller, specialized agents, each scoped to one vendor or domain. It documents its own wire protocol for this, NCFED, as an individual IETF draft rather than an adopted standard, so don't evaluate it for anything beyond a lab yet.

Whether that specific project succeeds or not, the underlying idea shows up repeatedly across this space: specialized agents with narrow tool access, coordinated by something else, instead of one model with hundreds of tools bolted on. It's also closely related to the tool-routing problem ACE-Router is studying academically.

A short glossary

• YANG: a data modeling language used to describe network device configuration and state in a structured, machine-readable way.
• NETCONF: a protocol for retrieving and changing that configuration, often what an MCP server is quietly translating agent tool calls into.
• OpenConfig: a set of vendor-neutral YANG models, useful when an agent needs to talk to multi-vendor gear without vendor-specific translation for every device type.
• JSON-RPC 2.0: the lightweight remote-procedure-call format MCP itself is built on.