The question changed this year. It used to be "which network automation tool should my team standardize on?" In 2026 it is "which tools let the AI agent my team already runs do the work?" That is a different comparison, and the usual listicles do not answer it. This one does.
Here is that workflow in one prompt, the way a team's own agent would send it:
Using the NetPilot tools, build a lab from my NetBox site DC-East, apply the candidate BGP change on the two core routers, run the platform-appropriate BGP summary before and after, and return the diff so I can sign off before the change window.
Which of the tools below can take that request end to end, which can answer part of it, and which give your agent the records it needs to write it in the first place? That is the comparison.
Seven tools, five dimensions that decide whether your agent can use them: where the tool gets its picture of the network, whether you get a lab you can run, whether your own agent can connect over MCP, whether custom integrations are part of the product, and which direction the integration runs.
| Tool | Source-of-truth input | A lab you can run | Connect your own agent (MCP) | Custom integrations | Direction |
|---|---|---|---|---|---|
| NetBox MCP server (NetBox Labs) | It is the source of truth | ❌ | ✅ open-source, read-only; governed writes in the commercial platform | Plugins, REST and GraphQL APIs | Tool → agent |
| Nautobot MCP server (Network to Code) | It is the source of truth | ❌ | ✅ official server, read-only queries | Jobs, SSoT apps, GraphQL | Tool → agent |
| IP Fabric | Discovered from the live network; syncs with NetBox and Nautobot | ❌ (a model, not runnable) | ✅ MCP server deployed from the appliance (April 2026) | API-first integrations: ServiceNow, NetBox, Nautobot, Itential, Ansible, Nornir | Agent → model |
| Forward Networks | Collected configs and state; NetBox plugin | ❌ (mathematical model) | ✅ Forward AI with MCP support for third-party developers | REST, NQE queries, ServiceNow tickets | Agent → model |
| Itential | Via NetBox and IP Fabric integrations | ❌ | ✅ Itential MCP server, 65+ governed tools | Automation Gateway, workflows exposed as REST | Agent → governed workflow (production) |
| Cisco Modeling Labs 2.10 | Indirect: export from NetBox with nrx, then deploy | ✅ Cisco images, self-hosted | ✅ first-party MCP server | REST API | Agent → lab (single vendor) |
| NetPilot | NetBox and Nautobot integrations, custom-built | ✅ real multi-vendor NOS, SSH access | ✅ your agent drives NetPilot's MCP server | Custom-built for your workflow; anything with an API or an MCP server | Both ways |
Bottom line: if your agent needs answers about records, use the source-of-truth servers. If it needs answers about production, use a model-based platform. If it needs a network it can build, break and validate before production, it needs a lab it can drive. NetPilot is the one platform in this table where your own agent drives the MCP server and NetPilot's agent connects back to your stack: a runnable multi-vendor lab on 12+ network operating systems, deployed in about 2 minutes, verifiable over SSH.
Tiers: how much of the agent workflow each tool covers
Tier means coverage of the build-and-validate workflow in the prompt above, not quality. In its own lane every A and B tool is the winner, and most teams pair a B tool with an S or A tool.
- S tier, end to end: NetPilot. The only tool here that takes the prompt as written: reads the records, builds a runnable multi-vendor lab, applies the change, validates, returns the evidence, and lets NetPilot's agent reach back into your stack.
- A tier, a large part of the workflow: Cisco CML 2.10 (a lab your agent can drive, Cisco images only, source-of-truth input only indirectly through an nrx export); Forward Networks and IP Fabric (the "will this be reachable?" half, answered against a model of production at a scale no lab matches); Itential (the "execute it with approvals" half, in production, which is the Day-2 lane NetPilot stays out of).
- B tier, the records the workflow starts from: NetBox MCP server and Nautobot MCP server. They do one thing and do it as the source of truth should: answer your agent's questions about what is deployed. The NetBox-driven workflow in the prompt above starts from them; the discovery-based platforms build their own picture of the network.
How to read the five dimensions
Source-of-truth input is where the tool's picture of your network comes from: your records (NetBox, Nautobot), live discovery (IP Fabric, Forward), or an integration that reads those records (NetPilot).
A lab you can run means real network operating systems you can SSH into, not a model you query. Models answer "can this ever happen?" Labs answer "what happens when I run this change?" Both are useful; only one lets your agent execute a rehearsal.
Connect your own agent (MCP) means the vendor publishes a Model Context Protocol server your Claude, Cursor or in-house agent can call. By late 2026 that is table stakes; the interesting differences are what the server lets the agent do and whether writes are governed.
Custom integrations means the product, or its vendor's team, connects to systems outside its own box: ticketing, Git, CI/CD, inventory. Some vendors ship a catalog. Some build per customer.
Direction is the dimension nobody else compares on, and it decides the architecture. Tool → agent: the tool exposes data. Agent → platform: the platform takes instructions and does work. Both ways: your agent can drive the platform and the platform's agent can reach into your stack.
NetBox MCP server (NetBox Labs)
NetBox Labs publishes the most agent-forward source of truth in networking. The official open-source NetBox MCP server is read-only by design: it exposes query tools against DCIM and IPAM data and deliberately nothing that mutates records. The commercial platform layers a Platform MCP server on top with write access routed through branching and approval workflows.
Where it wins: it is the source of truth. If your agent's job is "find a free /28 in the datacenter prefix" or "what changed at site DC-East this week", nothing beats asking the system that holds the answer. The read-only default is the right one.
Where it stops: a NetBox server answers questions; it does not build anything. Turning a site's records into a running network is someone else's job (historically the netreplica/nrx exporter, today an agent-driven lab).
Direction: tool → agent.
Nautobot MCP server (Network to Code)
Network to Code publishes an official Nautobot MCP server that translates plain-English questions into Nautobot queries, with streamable HTTP and SSE transports and documented setups for Claude Code and other clients. It is designed for querying and reading network data, and the server sends no data to Network to Code.
Where it wins: Nautobot is a platform as much as a source of truth. Jobs, Golden Config and the SSoT app framework mean an agent that can read Nautobot can also read what your automation is doing, not only what the records say.
Where it stops: same as NetBox. The server exposes data. The community servers around it vary in what they allow, so audit the tool list before you point anything at production records.
Direction: tool → agent.
IP Fabric
IP Fabric discovers the live network and builds a model from it, then launched an MCP server in April 2026 that is deployed from the appliance, opt-in by default, with a built-in prompt library for operations tasks. The documentation describes tools, prompts and resources an AI assistant can use to answer network questions.
Where it wins: assurance and source-of-truth validation at scale. Its integration catalog is API-first and long: ServiceNow, NetBox, Nautobot, Infoblox, Itential, Ansible, Nornir. If your question is "does what NetBox says match what the network does?", IP Fabric is built for it.
Where it stops: the model is not runnable. Your agent can query paths and state; it cannot apply a change and watch OSPF reconverge. IP Fabric says so itself: it is discovery, visibility and assurance, not emulation.
Direction: agent → model.
Forward Networks
Forward Networks builds a mathematically accurate digital twin from collected configuration and state. Forward AI, announced in January 2026 and generally available in April, lets teams and AI agents ask complex questions of that twin, and its press release says MCP support makes that verification foundation available to enterprises and third-party developers. A Forward MCP server implementation exposing 55+ tools is listed on a community directory; treat it as a community listing rather than a vendor product page. On the integration side, the forward-netbox plugin syncs Forward's discovered inventory into NetBox, and ServiceNow tickets can be opened from verification failures.
Where it wins: verification of an existing production network at very large scale, with no device risk. For "is this policy reachable from anywhere?", a formal model beats any lab.
Where it stops: the twin is a model of production, not a network you can execute against. Rehearsing a change means predicting it, not running it.
Direction: agent → model.
Itential
Itential launched its MCP server at AutoCon 3 in May 2025, and the open-source server now exposes 65+ governed tools with basic, OAuth 2.0 and JWT authentication and role-based access. Itential's NetBox integration and IP Fabric partnership make it the orchestration layer many of the tools above plug into.
Where it wins: governance. If an AI agent is going to trigger workflows that change production, you want approvals, audit and role-based control around it, and that is exactly what Itential sells.
Where it stops: it operates the network. There is no lab in the box, so the rehearsal step happens somewhere else, or not at all.
Direction: agent → governed workflow, in production. This is the Day-2 lane; NetPilot does not compete in it.
Cisco Modeling Labs 2.10
Cisco Modeling Labs is the reference lab for Cisco images, and version 2.10 added a first-party MCP server, so your agent can build and drive a CML lab. Source-of-truth input is indirect: the nrx exporter turns a NetBox site into a CML topology file you deploy yourself.
Where it wins: official Cisco image fidelity and exam-grade single-vendor accuracy. If the lab has to be Cisco to the byte, CML is the honest pick.
Where it stops: single vendor, self-hosted, and one direction: your agent drives CML; CML does not reach into your stack.
Direction: agent → lab.
NetPilot
NetPilot is agentic AI built for network engineering: an agent that designs, builds and validates multi-vendor networks from a prompt, on real network operating systems, before production. It is MCP-connectable both ways. Bring your own agent to NetPilot's MCP server, or let NetPilot's agent connect to your systems over API or MCP. Every integration is a custom build for your workflow; NetBox, Nautobot and Nornir are just a few examples.
Where it wins: it is the only row in the table with a runnable multi-vendor lab and both directions. Your agent asks for "a three-node lab, Arista spine, Cisco leaf, FRR router, eBGP between them, validate and report", and gets a deployed lab and the BGP summaries back in its own context. In the other direction, NetPilot's agent reads your NetBox or Nautobot over MCP and builds a pre-change validation lab from what your records say.
Where it stops: it never changes production. The only live access is read-only show commands through the Nornir integration, with credentials brokered from your Nautobot at call time and never stored; Day-2 operations, monitoring and remediation stay with the tools above. The MCP server is private to NetPilot and its customers, so this is not a server you clone from GitHub; NetPilot's team sets the integration up for your workflow, read-only by construction. And the lab is a scoped replica of a site or a change, not a 5,000-device model.
Direction: both ways.
Detailed matrix
| NetBox MCP | Nautobot MCP | IP Fabric | Forward | Itential | Cisco CML | NetPilot | |
|---|---|---|---|---|---|---|---|
| Agent access to your data | ✅ read | ✅ read | ✅ read | ✅ read | ✅ read + run workflows | ❌ | ✅ read (custom-built, read-only) |
| Governed writes | commercial platform | ❌ | ❌ | ❌ | ✅ RBAC + approvals | ❌ | ❌ by design |
| Real network OS you can SSH into | ❌ | ❌ | ❌ | ❌ | ❌ | ✅ Cisco | ✅ 12+ and growing |
| Multi-vendor lab | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✅ |
| Your agent can drive it over MCP | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| Its agent connects to your stack | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✅ over API or MCP |
| MCP server license | open source | official (private package) | in-platform | vendor MCP support; community servers listed | open source | first-party | private to customers |
| Hosting | self-host | self-host | appliance | SaaS or on-prem | SaaS or self-host | self-host | cloud or on-prem |
| Best for | records questions | records + automation state | assurance at scale | verification at scale | governed production changes | Cisco-only labs | build and validate before production |
Which should you choose?
- Your agent needs to answer questions about records → the NetBox or Nautobot MCP server, read-only. Start there whatever else you add.
- Your agent needs to verify a production policy or path → Forward Networks or IP Fabric. Pick by your existing platform; both have MCP servers now.
- Your agent will trigger production changes → Itential, for the governance around the trigger.
- Your lab has to be Cisco to the byte → Cisco CML with its MCP server.
- Your agent needs a network it can build and validate before production, from your real records, and you want NetPilot's agent reaching into your stack too → NetPilot. Talk to us about your stack; NetBox, Nautobot and Nornir are a few examples, and anything with an API or an MCP server connects.
Most teams end up with two of these: a source-of-truth server for answers and a lab platform for rehearsal, with a model-based twin if the estate is large enough to need one.
FAQ
Which network automation tools have an MCP server in 2026?
Most of the ones a network team already runs. NetBox Labs publishes an official open-source, read-only NetBox MCP server, with governed write access in its commercial platform. Network to Code publishes an official Nautobot MCP server. IP Fabric launched an MCP server in April 2026 that is deployed from its appliance. Forward Networks added MCP support with Forward AI in 2026 so third-party developers can build agents on its verification data; MCP server implementations for Forward are listed on community directories. Itential launched its MCP server in May 2025 with 65+ governed tools. Cisco Modeling Labs 2.10 added a first-party MCP server. NetPilot's MCP server is private to NetPilot and its customers and lets your own agent build and validate labs.
Can my own AI agent build and test a lab of my network before production?
Yes, if the platform behind the MCP server can run a lab. Source-of-truth servers (NetBox, Nautobot) answer questions about records; model-based platforms (IP Fabric, Forward Networks) answer questions about a model of production. Cisco CML runs a lab, single vendor. NetPilot runs a multi-vendor lab on real network operating systems: your agent connects to NetPilot's MCP server, asks for the lab, gets it deployed and validated, and can hand the result to you for verification over SSH.
What is the difference between an MCP server that reads a tool and a platform your agent can drive?
Direction. A NetBox or Nautobot MCP server exposes that tool's data to your agent (tool to agent). A platform your agent can drive takes instructions and does work on your behalf (agent to platform), for example building and validating a lab. NetPilot does both: your agent drives NetPilot's MCP server, and NetPilot's own agent connects to your stack over API or MCP to build pre-change validation labs from your real configs.
Do I need a custom integration if my tool already has an MCP server?
Often yes. An MCP server gives your agent tools; it does not decide which of them are safe, how credentials are stored, or how the result flows into your change process. NetPilot's team builds each integration as a custom AI agent for your workflow, read-only by construction, with the token handling and handshake tested before it goes live. NetBox, Nautobot and Nornir are a few examples; anything with an API or an MCP server works.
Is NetPilot's MCP server open source?
No. It is private to NetPilot and its customers, set up for your workflow by NetPilot's team. What is public is the pattern: your own agent (Claude, Cursor, or in-house) connects to it and can design, deploy and validate multi-vendor labs on demand, and the example prompt in the netpilot-labs repository shows what that conversation looks like.
Related reading
- Hub: NetPilot Integrations: AI agent integration with your network stack, custom-built for your workflow
- Workflow: Network Change Validation: the pre-change lab the integrations feed
- Primer: What Is MCP for Network Engineers?: the protocol, the server catalog, and where a productized agent fits
- Comparison: Nautobot vs NetBox 2026: choosing the source of truth your agent will read
- Tutorial: From NetBox to a Running Lab: the NetBox MCP server, two honest paths to a lab
Copy-paste ready: Bring Your Own Agent: Drive NetPilot over MCP, the prompt your Claude, Cursor or in-house agent sends once it is connected to NetPilot's MCP server.
Ready to give your agent a lab it can run? Get started with NetPilot, or talk to us about your stack and we build the integration for your workflow.