Table of Contents
It’s getting real out here.
Ever since I shared how autonomous AI Agents can monitor and heal the network on their own—yes, that one—I’ve gotten the same follow-up question in different forms:
“Okay, Kareem, this all sounds great… but how do I actually build one of these Model Context Protocol (MCP) servers for my product?”
Good news! If your product—like almost every product out there—has APIs, then chances are that you already have what you need.
Enter: OpenAPI spec
OpenAPI is a friendly contract for your APIs. You might’ve used it for Swagger docs, SDKs, Postman collections, or that one dusty codegen project from 2021. But here’s the twist: What if you passed that same OpenAPI spec to your AI agent?
That’s it. That’s the key.
One OpenAPI spec → one MCP Server → one AI-powered, access-controlled gateway to your product.
And no, this isn’t a “12 steps and a DevRel miracle” situation. It’s just a few lines of Python and a FastMCP wrapper around your OpenAPI file. The magic? Your APIs get transformed into safe, role-based AI tools—without writing a single custom tool definition.
Consider the following example:
You’re wrapping your existing OpenAPI spec with FastMCP, wiring in your authenticated client, and passing in your route-based ACLs. That’s how simple it is to go from “API docs” to “AI-ready, access-controlled MCP server.”
Build fast, govern smart
In this new AI-powered world, speed is the easy part. Governance—that’s the harder lift.
We don’t want to give the agent the keys to the kingdom. We want to provide it with a badge with just the proper access.
That’s where RouteMap comes in—our ACLs for AI. With a simple list of patterns (regex for those who love pain and suffering) and HTTP verbs, you can declare what endpoints are accessible for different personas (NOC, Sysadmin, full access, and so on).
Yes, it’s literally that easy. You’re building endpoint ACLs as code. You don’t need to create a whole new auth system or train a model to “learn” permissions. You just declare what roles get access to what endpoints—and the MCP Server enforces it.
From chaos to order
Let’s walk through a real-world use case.
Say you’re a NOC team managing a multi-site Meraki deployment. You’re responsible for keeping network devices patched and secure—but you can’t just schedule firmware upgrades at any time. Some sites are 24/7. Some spike at noon. Some run night shifts. The ideal upgrade window is a moving target.
That’s where the agent steps in.
You want to give the agent just enough access to help:
- Pull the current firmware status
- Monitor network usage patterns
- Schedule upgrades when it makes sense
Meanwhile, your Sysadmin team needs the agent to generate compliance reports. They need to know which devices are running outdated firmware—but they’re not scheduling upgrades or touching live traffic.
Two personas. Two very different scopes. One MCP server.
Here’s the beauty of it all. We didn’t write any custom tools. We didn’t build workflows or hardcode business logic. We just fed the MCP server the full Meraki OpenAPI spec—and let RouteMap handle the rest:
The NOC agent can schedule upgrades, because it needs that control. The Sysadmin agent? It gets a read-only view, tailored for visibility and compliance.
And again—we didn’t tell the agent how to do anything. The magic is in the MCP server. The tools become available based on the role, and the AI figures out the rest.
That’s the kind of governed autonomy that turns AI from a risk into a capability.
View it in action
As usual, you’ll find everything I’m showing here—the MCP server code, config, and prompt—in my GitHub Repo.
Now let’s fire this thing up. (And, yes, Network Pharaoh is a thing now.)
With the MCP server running and our route maps defined, I launch Claude Desktop (my MCP client of choice) and type the following prompt:
Your name is Network Pharaoh. You are acting with complete administrative visibility and data access privileges. You are a senior network administrator overseeing multiple Cisco Meraki organizations across the enterprise. Your role is to ensure that all network devices are running the latest compliant firmware. You are authorized to recommend firmware upgrades, but you must wait for explicit human approval before initiating any updates.
Target Organizations: Cisco U.
Task Instructions – For each organization:
-
- List all networks
- For each network, list all associated devices (including model, serial, and current firmware version)
- Retrieve the available firmware upgrade recommendations for the organization
- Identify any device that is not running the recommended version
- Recommend firmware upgrades as appropriate
- Do not perform any upgrade unless the human explicitly confirms with a statement like: “Yes, please upgrade [device/network].”
A few things are worth calling out:
The human-in-the-loop is built in. The agent knows it can’t act on its own—it must wait for approval. That’s governance baked into the prompt.
We didn’t tell the agent how to check compliance or suggest upgrades. It uses the tools available through the MCP Server and acts within the boundaries defined by its role.
The agent is doing intelligent work inside safe boundaries—using only what it’s been given access to. No guesswork. No scraping. No uncontrolled API calls. Just clean, policy-driven interaction through a structured, secure interface.
Here’s what the MCP server config looks like behind the scenes:
Pay attention to the importance of the MCP_ROLE. This one environment variable controls which routes the agent has access to. Set it to “NOC” and the agent can recommend firmware upgrades. Set it to “sysadmin” and the same agent, with the same prompt, will only be able to generate compliance reports—no upgrades, no PUTs.
That’s the advantage of separating the intelligence (LLM) from the control plane (MCP). You stay in charge of what the agent can do.
And here’s what the MCP server makes happen:
- Network Pharaoh traverses our Cisco U. organization, pulling a list of managed devices and spitting out a report.
- As Network Pharaoh is waiting for a human in the loop to execute the upgrade, it also auto-corrects the version based on web search and schedules it for us based on usage.
- Et, voila!
The skills behind the scenes
Let’s zoom in for a second. What did it take to build this?
Here are the skills a network engineer needs to put this together:
- Understanding of API fundamentals: OpenAPI specs, endpoints, HTTP methods
- Python scripting: Spinning up a basic server and configuring the MCP wrapper
- Access control thinking: Defining roles, access boundaries, and enforcing least privilege
- Agent design mindset: Prompting with context, purpose, and clear human oversight
- Curiosity and experimentation: Trying things out and tweaking as you go
And maybe most importantly:
- A shift in thinking—from building automation for the network, to building automation that understands the network.
Let’s keep pushing this frontier. Because the more we build intelligent boundaries, the more we unlock safe autonomy.
And that’s how we go from the Wild West… to a well-governed AI-powered enterprise.
Sign up for Cisco U. | Join the Cisco Learning Network today for free.
Learn with Cisco
X | Threads | Facebook | LinkedIn | Instagram | YouTube
Use #CiscoU and #CiscoCert to join the conversation.
Read more from the AI Break series:
Share:
