Small team, growing district

My K-12 district is growing 20% year over year. That means new campuses, closets, switches and access points, along with hundreds of new students/staff who need accounts and devices.

Our team is fairly compact, with just two engineers, and in our world additional members don’t always follow the increased enrollment. While I don’t think an AI agent replaces anyone, much of my time goes into gathering context and data. Which AP is that client on? What port is that camera on? Is this one closet or the whole campus? An agent with the right access could surface this data quicker than I can.

Can I build a Network Engineer Agent?

This post covers exactly that. Detailing how I gave Claude access to our network platforms through a self-hosted MCP server, next steps, the security risks, and why I’m weighing a local model.

The problem

Our network isn’t one vendor: Juniper EX in Mist, Aruba AOS-CX in Central, legacy HPE 5400s, a FortiGate firewall, and NAC currently split between PacketFence and ClearPass. A ticket with “Wi-Fi keeps dropping in room 214” means hopping between three or four interfaces. Until recently, Claude was a helpful network assistant, once I had pieced together the data, but it only knew what I gave it, which was almost always stale by delivery.

Using MCP reduces that friction by exposing tools like “list access points at this site” that the model calls against a live API.

I run it locally for a few reasons. A Central or Mist API token can push config, and I don’t want it on someone else’s relay. The server is open source, so I can read what it does with my keys. I already managed local servers and containers, one more costs close to nothing.

Connecting with cloud infra

The core is the community hpe-networking-mcp server. It talks to Aruba Central today, with Juniper Mist support landing. It runs in Docker on our Proxmox cluster. I use it from Claude Code through a dedicated “network engineer” agent and have access via Claude Desktop.

The payoff is a question like “which APs at [campus] went offline in the last 24 hours, and what ports are they on?” This is answered in one step instead of three console visits. It’s usually right within reason, so I treat it like a sharp junior engineer: it does the legwork, I check the conclusion.

Connecting with local infra

Vendor APIs only know what the vendor knows, local resources were missing.

So I started cisd-mcp, a second MCP server for data over tools I’d recently built to solve other problems: DHCPlane for DHCP scopes and leases, Aperture for campus, closet, and switch topology, and Sentry for device status and history. Now “this camera is offline: what port?”, “Do we have any scopes over 80%?”, or “What switch & port is this MAC address on?” all come from live data.

(posts on custom tooling coming soon…)

Next up? ClearPass

The next platform we’re looking to integrate is ClearPass Policy Manager, through the same hpe-networking-mcp server.

That rollout is where the agent may really shine. NAC authentication turns “the interactive panel in room 214 stopped working” into a quick question. Did it try 802.1X or fall back to MAB? Which service and enforcement policy matched? Was it rejected, or put in the wrong role? Today that answer lives in Access Tracker, one session at a time. With ClearPass on the MCP server, the agent can pull the authentication record and line it up with the switch port from Central and physical topology from Aperture:

  • “Why did the device on [switch] port [x] fail authentication this morning?”

ClearPass also raises the stakes. It will eventually hold usernames that map to students and staff, and its API can change endpoints and enforcement. So it gets a dedicated API client with a read-only operator profile and no write tools.

Security risks, mitigated by design

Technically these platforms can reconfigure every switch in the district, so each risk needs a solution in its design.

  • Credentials. A leaked token can push config district-wide. Each platform gets a dedicated service account with the narrowest role available, read-only wherever possible, with keys kept out of version control.
  • Writes (future). A misread question shouldn’t take a campus offline at 10 AM. Any write, like bouncing a port, needs a human to approve that specific action.
  • Exposure. The server is an API gateway into network management. It sits behind NPM with token authentication and an internal-only access list.
  • Audit. Proxy, tool-call, and platform audit logs show what was asked and when, and per-user access goes in before a teammate connects.
  • Privacy. Self-hosting keeps the server and keys in district hands, but tool output still goes to Anthropic as part of the conversation. Tools should return only what the question needs. At the moment, those answers don’t see student information.

A local model?

That last risk is the one self-hosting the server can’t solve, and once ClearPass is connected, tool results will include usernames. Which means I’m evaluating whether some of this should run on a model we host.

MCP makes that possible because the servers don’t care which model calls them. I’m testing local models on an otherwise idle district Mac Studio (M3 Ultra, 96 GB).

The trade-offs:

  • Capability. Frontier models are still better at multi-step troubleshooting, which is the job here.
  • Tool calling. Chaining Central, ClearPass, and Aperture calls needs reliable tool use, where smaller local models may struggle.
  • Cost and ops. Hardware isn’t cheap, and it’s one more service to patch and monitor.

A likely middle ground is a split: a local model for anything touching identity data, Claude for the rest.

Final thoughts

AI isn’t going to resolve K-12 staffing woes. Enrollment will outpace our staffing headcount, and our team may always feel tight… but maybe with a little upfront effort, we can build tools and use AI to reduce context-gathering for issues as they appear.