Most AI tooling quietly assumes there is a clean API behind everything. Claude Code, Codex and other AI agents expect and function best when there is an MCP intermediation interface in front of your target backend. That MCP service in turn expects a clean functional API to exist on your target backend. So, effectively, all of it assumes that whatever you want to reach speaks HTTP and returns JSON or other structured response formats.
Network infrastructure is where that assumption does not hold true. Not everything that is deployed and handling your network traffic has that clean API you can depend on. The switch carrying your production traffic most likely does not. Ask a router how it is doing and you get back text formatted for a human staring at a terminal. What all of these do have is a CLI and support for SNMP, a protocol that's been around for 3+ decades. Some newer gear speaks gNMI. Almost none of it has a REST API, and the boxes already racked and forwarding packets are not going to grow one suddenly.
That is the steady state, not legacy debt you will pay down. SNMP and the CLI have outlived a dozen management platforms that were each going to change everything, and they will outlive a few more. If your plan for using an agent in network operations depends on modern APIs, it does not survive contact with the actual network.
So the goal is to find a way to bridge this gap, how do we make these devices friendly to AI agents?
That is what Device Access MCP does. It is a small, read-only MCP server that exposes SNMP, CLI, and gNMI as ordinary MCP tools. An agent such as Claude Code, Codex or Sauble itself can ask a question in plain language; the server runs the SNMP walk, the SSH session, or the gNMI get, and hands back structured data. No protocol changes, no new code or APIs to build. What changes is who can ask and how.
Take the most ordinary incident there is. A link on one floor is flapping and users report intermittent drops. An agent working the ticket asks for the interfaces on that switch and gets back per-interface status and error counters. On one port, the input and CRC errors are climbing. The usual causes are a bad cable, a failing SFP, or a duplex mismatch. The agent never saw an OID. It asked about "interfaces," and the answer came straight off the switch over SNMP, from counters that have been sitting there for decades.
SNMP covers a lot of that ground, because so much of what you need mid-incident is standard MIB data: interface state, errors, uptime, neighbors, the ARP table. Where SNMP runs thin (richer neighbor detail, or anything you would normally read off the CLI), the same server opens a read-only SSH session or a gNMI get instead. One tool surface, three protocols underneath, chosen per device.
A few things it deliberately will not do. It cannot change device state. There are no write or configuration tools in it at all, so there is nothing to misfire. Raw device IPs never cross the boundary; devices are addressed by inventory name, and credentials stay inside the server process. CLI access is allowlisted and deny-by-default, and output is scrubbed for secrets before it leaves. None of that is a bolt-on. It is the reason the thing can sit in front of a production network at all.
There is nothing to install on the devices, no API layer to build, no migration. The protocols were always the source of truth about what the network is doing. Device Access MCP makes them answerable in natural language.