Last Updated: 2025-05-19

Every SuzieQ Enterprise release quietly adds things that end up being genuinely useful in day-to-day network operations. Version 3.3 has had a few updates already.

The GUI has seen a lot of attention. The new workbench makes it even easier to get at your data without jumping around, and you can now manage your inventory directly from the UI instead of stitching things together elsewhere.

Mining your configurations for lines that are there, or absent, or both just got easier. That’s the kind of thing you’d normally end up scripting or grepping your way through, and now it’s just built in.

The piece I really want to dig into, though, is the new SuzieQ MCP (Model Context Protocol) server available in Version 3.3.3!

We now have four ways of interacting with SuzieQ. That is unique.

Method	Used by
CLI	Those on your team who are used to or prefer the CLI
GUI	Those on your team who prefer a GUI (and the CLI folks who want to look at network topologies)
REST	Your Network Automation
MCP	Your AI Agents/Assistants (LLMs)

Four ways to talk to SuzieQ!? Lets see what that looks like... (~10min)

OK, Cut to the Chase

If you already understand where MCP fits into the AI/Automation tool chest and just want to see it in action:

SuzieQ MCP Server Out Take for the Impatient (~8min)

Looking at MCP Servers with Traditional API Clients (~7 min)

Putting it all together... a more realistic workflow with SuzieQ, Infrahub, and Netmiko MCP servers (~7min)

...otherwise read on!

Why MCP?

In November of 2024, Anthropic announced an open standard to connect AI clients/assistants with external data and capabilities. I actually remember this announcement and thinking "this is going to be good!". This was a reponse to the growing realization that your LLM, to be really powerful, needed access to your data and every time you wanted to fold in a new capability or data-set you would have to write a specific connector.

As AI assistants gain mainstream adoption, the industry has invested heavily in model capabilities, achieving rapid advances in reasoning and quality. Yet even the most sophisticated models are constrained by their isolation from data—trapped behind information silos and legacy systems. Every new data source requires its own custom implementation, making truly connected systems difficult to scale. - Anthropic Announcement November 25 2024

The Problem

Your AI Assistant (specifically Large Language Models, or LLMs, like Claude or ChatGPT, etc.) seems all powerful at first.

Think of an LLM as an incredibly well-read, junior engineer who has memorized every textbook, RFC, Reddit post (good and bad), vendor configuration guide and lots of other documentation available to the model during its training. They are great at synthesizing general (though often not current) knowledge. Basically my general use LLM knows everything that was accessible on the Internet (and any other data used) as of <date the model completed its training>.

Impressive, to be sure, but this junior engineer has two fatal flaws:

They are in "solitary confinement": They do not have access to your specific network. They don’t know your hostnames, standards, configurations, topology, IP address scheme, or your current BGP states.
They are all talk and no action: They live in their "knowledge bubble" and cannot log into a switch, run a show command, or modify a configuration "out of the box".

Because of this, if you ask an LLM, "How do I configure a VLAN on an Arista switch?" it gives you a perfect general answer.

If you ask, "Is VLAN 100 currently in use on the aggregate switches in Dallas?" the LLM must tell you, "I don't know."

Try it. Seriously.

This is where MCP comes in.

What if there was a way for your data (say your IPAMs store) and capabilities (say the tool you use to configure network devices like Netmiko) to present their tools, resources, and promtps in a standard and dynamic way to your AI Assistant?

The Model Context Protocol (MCP) is a standardized open protocol that acts as a universal bridge or adapter between the AI model and your specific network tools, data, and infrastructure. It is an intent first, agent-driven, API-like abstraction developed for use by LLMs.

OK..as network engineers you see protocol and start thinking TCP, SSH, BGP, and packet formats. Protocol in the case of MCP is more along the lines of the etiquette you use when meeting someone. A shared set of rules for how two people just introduced behave. Think handshake.*

A tool author (like Stardust Systems, developers of SuzieQ) writes an MCP server for their product, and any AI client that speaks MCP can use it.

I like to think of MCP as APIs for AI but that is a pretty simplistic analogy with some important differences. APIs (REST/GraphQL) are stateless. They expose specific endpoints and you have to figure out which endpoint you need by looking at documentation, Swagger interfaces, etc. MCP estabishes a channel or connection to your resources (data, tools) that is self describing. The MCP server tools are discovered at runtime and can maintain session-level context within your AI Assistant. In many cases the tools offered by an MCP server use APIs but they are wrapped in a less brittle, AI-native interface that can be re-used across LLMs.

When you are the brain

When you work with an API, you need to figure out what data or actions it exposes (who has not spent time digging around the Swagger interface for an API?) and then you develop scripts to use the API endpoints you need. You already have a good idea what you want to do so you have selected a particular API to help you execute your task. You need to keep and manipulate the data you extract and manage one or more API calls in the code you write. You also need to execute the logic and decision making in the code you write.

Its important when evaulating any new tool or methodology against your current workflow to recognize decisions you make organically or decisions made for you by your environment or constraints and why you care about them.

When your AI Assistant is the brain

When you work with an AI Assistant, you connect it to one or more MCP servers and you interact via natural language. Each MCP server exposes the tools, resources, and prompts defined by the author of the MCP server and as you ask your AI Assistant to do something, those capabilities can be used at the discretion of your LLM to accomplish tasks for you.

The brain of your junior engineer with the ability to use the tools made availabe by the MCP servers you've provided it under your supervision.

Why do I keep talking about tools, resources, and prompts? Because it is part of the MCP specification and you need to understand these primitives to make full use of the MCP server (or servers) you've tied to your AI Assistant.

If this is something you are thinking of folding in to your automation and AI Assisted network operations, I strongly recommend reviewing the MCP specification. It is pretty short and clear.

MCP Primitive	Description
Tools	Tools are executable functions the client or model can invoke. They often have side effects, such as calling an API, updating a system, or transforming data. Example: “Create a ticket,” “fetch weather,” or “restart service.”
Resources	Resources are read-only pieces of information exposed by the server. They are used as context and do not directly perform actions or change state. Example: a config file, a document, a user profile, or database record.
Prompts	Prompts are reusable templates or structured message flows that help steer the model. They can take arguments and return a prepared set of instructions or messages for a task. For example: You are a senior engineer. Write a clear, concise commit message for the following changes: {changes}

Tied to one (or more) MCP servers, your AI Assistant can now tap into:

tools to allow it to take action (get me all the vlans at this location or)
resources to provide specific context
prompts to provide responses in a structure pattern offered by the MCP server

In short, MCP transforms your AI Assistant from a passive generalist chatbot into an active network automation assistant that has specific knowledge about your network and can decide to take specific actions on your behalf.

More than that, you don't have to develop the scripts to get the API data you need and manipulate it for what you are trying to do. You ask your AI Assistant to do something in Natural Language, and it will determine if it can use the tools and resources you have given it access to via MCP to complete the task you requested.

What about RAG (Retrieval Augmented Generation)?

If you have been trying to keep track of AI capabilities, you have undoubtedly heard of Retrieval Augmented Generation. RAG is another way to solve the "AI assistant with useful information" problem. To give your LLM data specific to what you are trying to do.

RAG answers: “What relevant information should the model read before responding?”
MCP answers: “What external systems can the model safely query or act on?”

Use RAG to tokenize your governance or architectural documents before asking your LLM "How many uplinks should an access switch have?" RAG lets your LLM "answer" using your specific standards documents rather than relying on the model training data only (and having it make something up.)

Here is where it gets interesting. What if I put all my standards and guidelines into a source of truth like InfraHub and use MCP to query it? For me, right now, I'll focus on using MCP for this type of interaction and only use RAG where I don't have an MCP server or I have a bundle of unstructured data (documents, diagrams, etc.) that I want my AI Assistant to tap into.

Now, back to MCP...

An Example: VLAN Provisioning Workflow

Let's compare the traditional way (All manual and with some API) with the MCP-enabled AI way. In the non AI workflow pay attention to what actions are being take, where decisions are made, and where coding is involved.

The Goal

Provision a new VLAN for Office Occupancy IOT at the "Seattle Campus" site. Lets focus on Layer 2.

	The Traditional Way (You do all the work)	The API Way (You select APIs that can help you get the job done and write code)
Intent	You log into the Infrahub web UI. You check that VLAN 200 is the VLAN ID to be used for Office Occupancy IOT and you navigate to the "Seattle-Campus" site to confirm that the intent is to roll out Office Occupancy IOT at that location (VLAN 200 is planned or in provisioning state).	You learn about the InfraHub API and you create a script that hits the API and gets the VLAN information and its state.
Current State	You log in to the switches at the Seattle Campus and check manually (If you are still doing this we have to talk!)	You query SuzieQ to confirm that VLAN 200 is not actually configured and running on any devices in the real world (in case the Source of Truth is out of sync). Alternatively you write a script to get the current state from your devices or from SuzieQ API.
Correlation/ Orchestration	You mentally compare the data and decide it's safe to proceed and determine the next steps	You write a script that performs the correlation
Execution	You log in and configure the Seattle core switches manually via CLI to add the VLAN. You execute Validation and Tests.	You write a Python script using modules like Netmiko, Nornir, etc. to add the VLAN and excute Validation and Tests.
Completion	You update Infrahub to indicate VLAN 200 at Seattle Campus is provisioned (now active and in production).	You write a script to update Infrahub to indicate VLAN 200 at Seattle Campus is provisioned via GraphQL.

The MCP Way (Your AI Assistant works on your behalf, you supervise)

You are using an AI-powered interface (like Claude) that is connected via MCP to your infrastructure.
You tell your Assistant what you want to accomplish in Natural Language and your AI Assistant reviews all the specific capabilities you have given it via one or more MCP server connections and works to "get it done". This includes actions and decisions.

Note: The AI automatically breaks your request into a "Chain of Thought" (CoT) workflow and executes necessary tool calls.

Your Input to the AI:

I want to provision the Office Occupancy IOT VLAN at the Seattle Campus site, Layer 2 only. Check Infrahub for the standard VLAN ID to use, verify that the vlan is in a provisioning state, verify with SuzieQ that it's not active on the network, and if safe, show me the configuration needed for the campus switches for my review, and if I approve, configure the Office Occupancy IOT Vlan and test by checking spanning tree for the new vlan.

Here's what happens behind the scenes:

I (your AI Assistant) understand your intent — you want to check the source of truth (Infrahub), validate against the live network (SuzieQ), and then act (configure the switch).
I call the Infrahub MCP server — I invoke a tool like get nodes(vlan_id=200, site="seattle"). The MCP server translates that into a GraphQL query against Infrahub's API and returns structured data: "VLAN 200 is allocated to Seattle and in the provisioning state."
I call the SuzieQ MCP server — I invoke query_vlans(vlan_id=200, namespace="seattle"). SuzieQ checks its collected state from all switches at that site and returns: "VLAN 200 not present in any MAC table or configuration."
I reason about the results — Infrahub says it's allocated but unused. SuzieQ confirms it's not on the wire. I now know it's safe to configure.
I call the Netmiko Network Config MCP server — I invoke send_config(configuration lines for configuring vlan 200 "Office_Occupancy_IOT"). This server uses Netmiko under the hood to push the config and returns success/failure.
I call the SuzieQ MCP server - I invoke query_spanning_tree(vlan_id=200, namespace="seattle"). SuzieQ checks its collected state from all switches at that site and returns a pass/fail STP determination.
I report back to you in plain English with the results

The key insight: I never talked directly to Infrahub's or SuzieQ's API, wrote code, or SSH'd into a switch. Each MCP server handled its own tool's specifics. I just called standardized tool functions and reasoned about the results.

Why This Matters to You

Without MCP, you'd need to write a custom Python script that imports the Infrahub SDK, the SuzieQ client library, and Netmiko, wiring them together with error handling, sequencing logic, and decision-making. That script typically works for exactly one workflow and breaks when APIs change.

With MCP, each tool team (or you) writes a small MCP server once OR you use the MCP server provided by your vendor if available. Then any AI that speaks MCP can use all of them, and you describe what you want in English. The AI handles the orchestration, the "if this, then check that, then do the other thing" logic that you'd normally code by hand.

The really powerful part: the AI can reason across tools. It doesn't just call them sequentially — it can say "Infrahub says VLAN 200 is allocated but SuzieQ shows it's not on the wire, so there may be a config drift issue. Want me to fix it or flag it for review?" That cross-tool reasoning is something you need to add to your code along with all the basic functionality. Of course, with your AI Assistant you need to be ready to handle over-reach or be very explicit in your instructions (prompts).

MCP in Action

With so much that is unfamiliar about AI, lets start with something familiar. Lets look at an MCP server with familiar tools. Many popular API clients like Postman and Insomnia now support MCP (And an AI Client too!). What does that tell you?

Looking at MCP Servers with Traditional API Clients (~7 min)

SuzieQ MCP Interactions..You didn't realize your network was funny? (~8min)

Putting it all together... a more realistic workflow with SuzieQ MCP server

Conclusion

It’s hard not to be impressed by the power of LLMs, especially when they’re grounded with the right context and the right data, which is exactly what MCP was designed to do. And yet, at the same time, AI feels like an extinction-level event (ELE), not of life (at least not yet), but of how we work, how decisions are made, who or what takes action, and where we spend our time.

The pendulum has swung yet again. What used to be the holy grail, determinism, accuracy, reproducibility, has given way to systems that feel intelligent but come with inherent variability and, at times, questionable accuracy. Trying to impose consistency on top of that is now a discipline in itself. Managing that variability isn’t a side task; it’s becoming the work. We've gone from default deny to default allow.

Somewhere in that shift, I find myself missing the fundamentals. I miss coding. I miss learning in a way that felt grounded and organic. I learned by doing but guess what. I am not the one "doing" any more.

I miss the weight and precision of a well-crafted sentence and the satisfaction of authoring a technically excellent document.

The most important thing I've learned is that expertise still has value, potentially even more value than before because it will be that expertise that will help solve the "default allow" problem and at least for the present, the this is a hallucination, problem. My concern is how that expertise is going to develop, if it has to. The eningeering rigor is still as important today, and maybe more so. Its not what we are doing (yet) but how and what is doing it.

Is speed and volume worth this price?
What happens if I allow my expertise to become stale and AI has not replaced it? Without expertise my roles as "supervisor" and reviewer" have little value.
Will I be part of the knowledge lifecycle?

For now, more than ever, the real skill is understanding where these capabilities actually fit, when to trust them, when to constrain them, when to fall back on first principles, and what to question. I do believe the system will eventually stabilize, that one way or another equilibrium will be restored to a new normal (again).

Otherwise, I’d better get a lot better at rearranging deck chairs.

Resources & Links

Used for this Demo

No MCP Servers were harmed in the writing of this article.

Infrahub MCP Server
MCP server that connects AI assistants and IDE agents to Infrahub, allowing schema-aware querying and branch-isolated writes against your infrastructure source of truth.
https://github.com/opsmill/infrahub-mcp
Netmiko MCP Server
MCP server that enables LLMs to interact with network devices over SSH via Netmiko, supporting multi-vendor environments (e.g., Cisco, Juniper, Arista) for automation and troubleshooting.
https://github.com/ntunes/netmiko-mcp-server
SuzieQ Enterprise Version 3.3.3

SuzieQ MCP Server
Third party MCP server from Luis Poveda that exposes SuzieQ’s network observability commands (like “show” and “summarize”) as MCP tools, letting clients query network state tables directly from SuzieQ.
https://github.com/PovedaAqui/suzieq-mcp

This was the first SuzieQ MCP server I became aware of, and it set an important early example of how MCP could be used to give AI agents deep, structured visibility into real network state and the power that provides.

Honorable Mention

I've been using voice to text alot this year, and so finally decided invest in a tool. When you see me actually talking to Claude Code, Im using WisprFlow.

https://wisprflow.ai/

MCP Registries & Specifications

MCP Specification & Transport Details

MCP Transports Specification
Official spec section describing supported transports (such as HTTP and SSE) for MCP clients and servers.
https://modelcontextprotocol.io/specification/2025-11-25/basic/transports

Vendor-Neutral / Official Registries

Browse the many MCP servers that are out there just waiting for you to try.

MCP Registry (Vendor Neutral)
Community-driven, vendor-neutral registry for discovering and listing MCP servers and tools.
https://registry.modelcontextprotocol.io/
ProtoMCP MCP Registry
Alternative MCP-focused registry with curated MCP servers and integrations, often oriented around ProtoMCP’s ecosystem.
https://protomcp.io/mcpregistry
MCP Servers Directory
Community directory that indexes MCP servers across multiple providers, making it easier to discover capabilities and endpoints.
https://mcpservers.org/
GitHub MCP Servers Repository
Official GitHub organization/repository aggregating open-source MCP server implementations and references.
https://github.com/modelcontextprotocol/servers
LobeHub MCP Marketplace
Marketplace and UI for discovering, configuring, and running MCP servers inside the LobeHub environment.
https://lobehub.com/mcp

MCP Inspectors

MCP-Specific

ProtoMCP

Browser-based “Postman for MCP” that lets you connect to MCP servers, discover tools/prompts/resources, and interactively test them with real-time JSON-RPC traces.
https://protomcp.io/

General API Clients (Useful for MCP Backends)

Postman

Industry-standard API client and platform for designing, testing, and documenting REST, GraphQL, gRPC, and other APIs—useful for exercising MCP backends and related services.
https://www.postman.com/
Insomnia
Open-source, cross-platform API client for REST, GraphQL, WebSockets, gRPC, and more, with strong environment and testing support; a solid alternative to Postman.
https://insomnia.rest/

Sam Kinison First Appearance on Letterman

https://www.youtube.com/watch?v=m_VURr6jnWQ

Sam Kinison on British TV

https://www.youtube.com/watch?v=DZUQM0ib2CI