Meet Jim. Your entire network lives in Jim’s head. If you have questions about changes that are happening in the network, Jim’s your go-to. And if Jim leaves, you could be stuck trying to figure everything out from scratch.

This sort of approach is common, but also completely unsustainable at the enterprise scale. With dozens or even hundreds of changes pushed out each day, it’s impossible for any human engineer to maintain an accurate mental model of the network. Plus, if every team has to go to the same engineer for help, it usually leads to data bottlenecks that slow the business down.

Naturally, enterprises are turning to AIOps to take all this work off of Jim’s plate. Gartner estimates that by 2029, 70% of enterprises will deploy agentic AI in network operations, compared to less than 5% in 2025. After all, wouldn’t it be great to have an AI coworker check your network every day, and ensure it matches up with your intended design?

With IP Fabric’s new MCP server, that future is already here. But before we get too far into it, there are a few challenges that enterprises have to address before they’re able to deploy AIOps in a safe, scalable way.

What Are the Most Common Challenges When Deploying Enterprise AIOps?

As enterprises step up their AI initiatives, most will have issues with some, if not all, of the following:

• Data: AI is only as good as the data you use to train it. For positive outcomes, AI needs data that’s fresh, accurate, structured, and contextualized by network behavior.
• Tooling: There’s no standardized way to share network insights with AI tools. Most network teams build custom integrations or rely on manual exports that are already out of date by the time they’re ready to be used.
• Skills: AIOps demand a rare combination of AI expertise and deep network knowledge, which is a pairing that’s hard to find.
• Governance: Most network teams don’t have a reliable way to verify that an AI agent’s output is in line with business intent, such as security and regulatory controls.

If you’re lacking even one of these four elements, it’ll be impossible to trust the output from your AI agent. For example, if you train your AI agent on unstructured or incomplete data, then that agent will be operating off of limited context about the network state, which makes it prone to hallucinations and other errors. And if your AI agent is prone to errors, that means you can’t verify network paths accurately, which opens your network up to risk. It’s a slippery slope—but it’s one that can be smoothed out with accurate, accessible network data.

How Does IP Fabric’s MCP Server Solve Those Challenges?

The four challenges we outlined above don't disappear on their own. IP Fabric’s MCP server helps to address them in a few key ways:

• Data: IP Fabric discovers your network from core to edge to cloud, delivering a complete and accurate view of your actual network state and behavior at a given point in time. All insights are normalized and contextualized by end-to-end network behavior, so they’re always AI ready.
• Tooling: Our MCP server builds on the IP Fabric platform by exposing that network discovery data directly to the AI tools your team is already using (e.g. Claude, Copilot), with no custom integrations required.
• Skills: Anyone on your team can query your network directly, rather than relying on mental models. All prompts can be written in natural language, and don’t require any advanced coding or tool-specific knowledge.
• Governance: The MCP server ships inside your local Virtual Machine (VM), rather than a third-party hosted service. You must also explicitly opt in to using it, which ensures that your team is always in complete control of your network data.

Now, let’s dive in to a few of the most common use cases for our MCP server.

Check out our dedicated demo playlist to learn more about IP Fabric’s MCP server.

4 Prompts to Unlock Enterprise AIOps with IP Fabric’s MCP Server

Each of the following prompts start with the same foundation: a verified snapshot of your actual network state. Once you have this snapshot, you can use the MCP server to ask your network virtually anything. In this blog, we’re covering the four most common scenarios that a network team might encounter, ranging from compliance to troubleshooting and beyond.

Detect Compliance Drift

Most enterprises are juggling six or more security and regulatory frameworks at once. A single audit can take a month or more to complete, and by the time you’re done collecting the necessary network data, it’s already out of date. As a result, it can feel impossible to get an accurate picture of your compliance health.

But if you have a fast, easy way to audit your network, all of that changes. For example, with the following prompt, you can ask IP Fabric’s MCP server to analyze your latest network snapshot and summarize your compliance status with CIS benchmarks. This prompt will also highlight any gaps (e.g. improper segmentation policies, firewall rules, or device configurations), sort the gaps into priority order, and offer recommendations for ways to address them. Then, when you’re ready to share the report, you can tailor it to your intended audience, whether that’s your security team or an external auditor.

## Variable
HOSTNAME = d1xfw01
---
You are a network security report generator with access to IP Fabric MCP tools.
Use HOSTNAME defined above as the target device throughout all steps.
## Step 1 — Data Collection via IP Fabric MCP
Use the IP Fabric MCP tools to collect all required data for HOSTNAME:
1. Resolve the active (or most recent) snapshot ID
2. Query device inventory to get: serial number, management IP, vendor, platform, software version
3. Query CIS Benchmark results filtered to HOSTNAME — retrieve all checks with: benchmark ID, title, status (PASS/FAIL/WARNING/INFO), severity (CRITICAL/HIGH/MEDIUM/LOW/INFO), finding detail, and recommendation text
4. Compute summary statistics: total checks, passed, failed, warnings, compliance score (%), severity breakdown
If HOSTNAME is not found in inventory, list available devices and ask which one to report on.
## Step 2 — Generate PDF Report
Using ReportLab (Python, Platypus), generate a self-contained script and execute it to produce the PDF.
### Structure
- **Cover page**: "CIS Benchmark Report" title, device HOSTNAME, snapshot name + date, report generation timestamp
- **Page 2 — Executive Summary**: compliance score as large % with horizontal progress bar, summary table (Total / Passed / Failed / Warnings), severity breakdown table (Critical / High / Medium / Low / Info)
- **Page 3+ — Detailed Findings**: all checks ordered by FAIL (CRITICAL→HIGH→MEDIUM→LOW first), then WARNING, then PASS, then INFO
### Visual Design
- A4 page, 2 cm margins
- Color scheme: FAIL → #dc3545 | WARNING → #ffc107 | PASS → #28a745 | INFO → #6c757d
- Severity badges: CRITICAL=dark red, HIGH=red, MEDIUM=orange, LOW=teal, INFO=grey
- Compliance score bar: red if <60%, amber if 60–79%, green if ≥80%
- Alternating row shading in tables
### ReportLab Constraints
- All coloured backgrounds MUST use TableStyle BACKGROUND commands on Table cells,
  never ParagraphStyle(backColor=...) — it renders as transparent
- ROUNDEDCORNERS is not a valid TableStyle command — use canvas-drawn Flowables instead
- For score pills, progress bars, and badges: subclass Flowable and draw via self.canv
  (roundRect, drawCentredString, setFillColor) — this is the only reliable approach
- Badges in finding rows: single-cell Table with BACKGROUND + white Paragraph text## Finding Block Format (per check)
- Header: [STATUS badge] [SEVERITY badge] [Benchmark ID] — [Title]
- Finding text as normal paragraph
- For FAIL/WARNING only: "Recommendation:" in italic, indented, with left border in status color
### Technical Requirements
- ReportLab Platypus: SimpleDocTemplate, Table, Paragraph, Spacer, HRFlowable
- Helvetica font family only (no Unicode subscript/superscript characters)
- Footer on every page: HOSTNAME | {snapshot_name} | Page X of Y
- Output filename: CIS_Benchmark_Report_HOSTNAME.pdf
- Write output to /mnt/user-data/outputs/
- Execute the script and confirm the PDF was created successfully

The output should look something like this:

Get more compliance MCP server prompts in our prompt library.

Accelerate Troubleshooting & Slash MTTR

Let’s say your network is down. A BGP session dropped off, traffic is taking a weird path, and the one engineer who knows this part of the network is on vacation. Normally you’d spend an hour pulling CLI outputs from dozens of devices to piece together what happened. But with IP Fabric’s MCP server, you can simply ask: “What’s the state of every BGP neighbor across all my sites?”

Use the following prompt to automatically pull BGP-advertised routes, neighbor relationships, and routing policies between network sites. You’ll get the results in a report that tells you exactly where to start your triage.

## Variable
SNAPSHOT = last

---

You are a network report generator with access to IP Fabric MCP tools.
Use SNAPSHOT defined above throughout all steps.

## Step 1 — Data Collection via IP Fabric MCP

1. Resolve snapshot ID matching SNAPSHOT
2. Query BGP neighbors — for each entry: local device, local AS, neighbor IP,
   neighbor AS, state, VRF, site, address family, prefixes received/sent
3. Query BGP advertised/received routes — source device, neighbor, prefix,
   next-hop, AS path, origin, MED, local preference, communities
4. Query routing policies (route-maps / prefix-lists / filter-lists) applied
   to BGP neighbors where available

## Step 2 — Generate PDF Report

Structure: Cover page → Executive Summary → BGP Neighbor State Table →
Per-Site Neighbor & Policy Analysis → Advertised/Received Route Summary →
Anomalies & Recommendations

Key content per section:
- Summary: total neighbors, established/down counts, total prefixes, AS count
- Neighbor table: Device | Site | Neighbor IP | Peer AS | State | AFI/SAFI |
  Prefixes Rcvd | Prefixes Sent — highlight non-Established rows in red
- Per-site: neighbor details, applied policies, notable AS paths, communities
- Anomalies: missing peers, asymmetric prefix counts, missing route policies,
  duplicate prefixes across sites

Design: A4, 2cm margins, Helvetica only, red=#dc3545/green=#28a745/amber=#ffc107,
alternating table rows, monospace for prefixes and AS paths.
Footer: BGP Report | SNAPSHOT | Page X of Y.
Output: /mnt/user-data/outputs/BGP_Report_{snapshot_name}.pdf — execute and confirm.

The output should look something like this:

Get more troubleshooting MCP server prompts in our dedicated prompt library.

Simulate “What-If” Scenarios

Whether you’re tweaking a single firewall rule or embarking on a large-scale network refresh, it’s important to pause and consider the impact of a change before you make it. You’re most likely relying on your mental model of the network to imagine any possible downstream effect. Then, once that change has been pushed to production, you can finally validate it to make sure it had the intended result.

IP Fabric’s MCP server offers a more reliable and scalable version of this process. Pulling from IP Fabric’s network data, you can simulate the most likely effect a change will have before you push it to production. For example, the below prompt will run a “what-if” analysis for a first-hop gateway failure on a specified traffic path. In addition to simulating the effect of the change, it’ll also generate a report detailing redundancies, failovers, and possible recovery timelines—all before your team even touches a config.

## Variables
SNAPSHOT = active
SOURCE_IP = 172.16.12.61
DESTINATION_IP = 172.16.23.21

---

You are a network predictive analysis report generator with access to IP Fabric MCP tools.
Use SNAPSHOT, SOURCE_IP, and DESTINATION_IP defined above throughout all steps.

## Step 1 — Data Collection via IP Fabric MCP

1. Resolve snapshot ID matching SNAPSHOT
2. Run path lookup SOURCE_IP → DESTINATION_IP — collect full hop list, sites, ECMP branches
3. Identify first-hop L3 gateway — site, interface, subnet
4. Query FHRP (VRRP/HSRP/GLBP) groups for the gateway and its redundancy peer —
   device, interface, virtual IP, subnet, protocol, state, priority, preemption
5. Confirm whether both gateways share symmetric uplinks and routing tables

## Step 2 — Generate PDF Report

Structure: Cover page → Executive Summary (stat cards + current hop sequence) →
FHRP Configuration Table (all groups, state/priority/preempt, load balancing analysis) →
What-If Scenario (trigger events, current vs failover two-column comparison,
modified hop path with changed gateway highlighted, unchanged segments rationale) →
Failover Timeline (detection → transition → convergence → recovery phases with timing) →
Risk & Recommendations (strengths, risks, remediation table)

Design: A4, 2cm margins, Helvetica only, green=#28a745/amber=#ffc107/red=#dc3545,
hop sequences in Courier monospace, changed hop in red bold, current vs failover
columns green-tinted vs red-tinted, alternating table rows.
Footer: Gateway Redundancy | SOURCE_IP → DESTINATION_IP | SNAPSHOT | Page X of Y.
Output: /mnt/user-data/outputs/Gateway_Redundancy_{source}_{dest}_{snapshot}.pdf — execute and confirm.

The output should look something like this:

Get more MCP server prompts in our dedicated prompt library.

Get Underlay & Overlay Topologies for SD-WAN

In SD-WAN environments, you’re managing two topologies instead of one. When something goes wrong, you may think to check either the underlay or the overlay first, but it’s vital to check them both simultaneously in order to get the full picture of network behavior. Without help from automation, that could mean hours of cross-referencing technology tables, topology maps, and path analysis outputs.

Meanwhile, IP Fabric’s MCP server is capable of correlating the states of your overlay and your underlay in a single natural language request. It maps tunnels to physical paths, surfacing any gaps or anomalies between the two layers for swift triage and remediation.

## Variables
SNAPSHOT = last
SITE_FILTER = all

---

You are a network topology report generator with access to IP Fabric MCP tools.
Use SNAPSHOT and SITE_FILTER throughout all steps.
SITE_FILTER can be: "all", a site name, or a comma-separated list of sites.

## Step 1 — Data Collection via IP Fabric MCP

1. Resolve snapshot ID matching SNAPSHOT
2. Query SD-WAN inventory — devices, sites, WAN transport types (MPLS/internet/LTE),
   physical interfaces, ISP links, underlay IP addressing
3. Query SD-WAN overlay tunnels — tunnel ID, type (IPsec/GRE/TLOC),
   local device, local IP, remote device, remote IP, state (up/down), site pair
4. Query physical topology — device interconnects, interface states,
   uplink utilization where available
5. Cross-correlate: for each overlay tunnel identify the underlay physical path
   it traverses — flag tunnels where underlay path is unknown or ambiguous
6. Identify anomalies: tunnels up but underlay link degraded, tunnels down,
   overlay design relying on single underlay path (no redundancy),
   physical changes not reflected in overlay (orphaned or mismatched tunnels)

## Step 2 — Generate PDF Report

Structure: Cover page → Executive Summary (stat cards: SD-WAN devices, active
tunnels, degraded tunnels, sites with underlay/overlay mismatch) →
Underlay Topology per site (physical devices, WAN interfaces, ISP links, states) →
Overlay Topology (tunnel table: local device, remote device, transport, state,
underlay path mapped) → Correlated View (per site-pair: underlay path + tunnels
riding it, redundancy assessment, single-point-of-failure flags) →
Anomalies & Incident Triage Guide (table: issue, affected layer, underlay or
overlay root cause, recommended first diagnostic step) →
Architecture Recommendations

Design: A4, 2cm margins, Helvetica only, underlay=#2c5282/overlay=#6b46c1/
healthy=#28a745/degraded=#ffc107/down=#dc3545, dual-layer diagrams as nested
tables (underlay row + overlay row per site pair), monospace for tunnel IDs and IPs,
alternating row shading.
Footer: SD-WAN Underlay & Overlay Report | SNAPSHOT | Page X of Y.
Output: /mnt/user-data/outputs/SDWAN_Topology_{snapshot_name}.pdf — execute and confirm.

The output should look something like this:

Get more MCP server prompts in our dedicated prompt library.

Download the Full Prompt Library

Want to explore more use cases and prompts? Download our prompt library to get our entire quickstart library. In addition to 10 expert-tested prompts, you’ll also get:

• Detailed guidelines for engineering your own prompts.
• Tips on how to keep AIOps secure as you scale.
• Strategies for connecting AIOps use cases to measurable business outcomes.

Ready to see the MCP server in action? Contact our team for a demo today.

FAQs

How Does IP Fabric’s MCP Server Work?

IP Fabric discovers 100% of your network devices, connections, and configurations from core to edge to cloud. Using that discovery data, it maps out your actual network state and behavior at a given moment in time. The result is a normalized, timestamped snapshot, which you can query via the MCP server. Any member of your team—human or AI agent—can ask the MCP server questions in natural language and get responses back in the form of actionable, customizable reports.

Think of the MCP server as an abstraction layer that helps both humans and AI to interface with the network. It makes it easy to access reliable, validated network data, which is essential for building trustworthy enterprise AIOps.

Can’t I Just Build My Own MCP Server?

Yes and no. You can build your own MCP server, but the more important part is the data that’s underneath it. If your server is built on top of incomplete or unstructured network data, then your outputs will likely results in hallucinations and other errors. If a human or AI agent is using that MCP server, then their actions won’t be reliable. TL;DR: an MCP server built on bad data won’t get you very far.

What Kind of Data Do You Need for Successful Enterprise AIOps?

In order to be reliable, your AI agents and workflows need data that’s:

• Accurate and free of errors.
• Contextualized by a complete understanding of network behavior.
• Structured and normalized so that an AI agent can understand it.
• Easily accessible, so an AI agent can get the data it needs, when it needs it.

If your network data is missing any one of these elements, then your AI agent may not have the data it needs to make trustworthy decisions.

How Does IP Fabric Help With MCP Security?

IP Fabric’s helps with MCP security in two key ways:

1. Instead of shipping our MCP server a third-party hosted service, we ship it in your local VM. This keeps sensitive network data inside your environment and out of external systems.
2. You must explicitly opt in to using the MCP server. This is essential for proper network governance.

Once IP Fabric’s MCP server is up and running, you can use it to validate your security posture and compliance with all major frameworks like CIS, ISO 27001, and NIST, as well as your own internal baselines. You can also proactively prevent security gaps by running “what-if” simulations before pushing any change to production.