Skip to main content
The Aviatrix MCP server gives an AI assistant read access to your Controller and CoPilot: gateways, tunnels, BGP, Distributed Cloud Firewall (DCF) policies, SmartGroups, firewall and intrusion logs, audit trails, traffic analytics, and network diagnostics such as ping, traceroute, and FlightPath. This page collects prompts that have been validated against a live Aviatrix fabric, organized by the role most likely to run them, with abridged example outputs.
All example outputs on this page come from a demo fabric: 25 gateways across AWS, Azure, GCP, and OCI, with 5 full-mesh transits, 3 edge sites, 47 SmartGroups, and a 30-policy DCF chain. Threat indicators shown, including domains such as malware.net and exploit source IPs, are synthetic data seeded into the demo environment. Your results reflect your own fabric.
The depth and formatting of responses varies with your MCP client and the model behind it. The prompts below describe what the MCP server returns; how your assistant assembles, summarizes, and renders that data depends on the client you use.

​
Start here: fabric health sweep

The best first prompt after connecting the MCP server. It exercises gateway inventory, tunnel state, Site-to-Cloud (S2C) connections, BGP diagnostics, controller logs, and DCF in a single pass, and gives you an immediate baseline for everything else on this page.
After the summary lands, drill into any finding with a short follow-up such as “expand on the egress finding” or simply the finding number if your assistant numbered them.
Fabric health: 25/25 gateways up, 5/5 S2C tunnels active. Three findings need attention.
  1. Egress to a flagged domain on one spoke. operations-aws-spoke-k8s permits traffic to malware.net (synthetic demo indicator) while the identical SNI is denied on marketing-azure-spoke-all and accounting-aws-spoke-dev. Root cause: the strict SNI WebGroup is attached on two spokes but missing on operations-aws-spoke-k8s. This is policy drift, not a detection gap.
  2. IPS is in monitor-only mode. Roughly 2,000 alerts over 7 days, 0 blocks. Detection without enforcement.
  3. BGP session reset 6 days ago on sv-equinix (145 prefixes in / 158 out). Session is currently established; worth correlating with any change that day.
Everything else checked clean: no gateway CPU or memory distress, no tunnel flaps in the current log window, default-deny DCF rule active and terminal.

​
Security

​
Security posture audit and auditor evidence

Ask for a full posture sweep when you need to know what is inspected, what bypasses inspection, and what you could show an auditor. This is one of the heaviest prompts on the page; expect the assistant to make dozens of MCP calls.
The MCP server does not care which language you ask in. The same prompt in French, German, or Japanese runs the same tools and returns the same evidence.
Inspection coverage: 13 of 14 spokes covered, 1 blind. Ten spokes enforce DCF locally and log continuously; the accounting spokes are inspected by the vendor firewall on transit-aws-us-east-1 (FireNet). operations-oci-spoke-shared has no DCF logs and is not in the FireNet inspection list: it moved 680 MB in 7 days with zero policy visibility. That is your single blind spot.Bypassing inspection: a leftover test-lambda-egress rule (priority 50) permits any protocol and port from the Lambda group to the internet; HTTPS egress carries no IDS because the combined http+https IDS policy at priority 999 has never matched (0 hits in 7 days, a dead rule).Correlation finding: the number 2 top talker by volume (13.5 GB in 7 days, synthetic demo source IP) is also the source of a permitted HeartBleed exploit attempt against marketing-app-prod. That is not a coincidence, that is a pattern.Auditor evidence pack: 30-policy DCF export ending in an explicit default-deny-all that fired 7,033,384 times in 7 days with zero allows, plus timestamped cross-segment deny samples (marketing to accounting on 8443: Denied; marketing to enterprise-data on 1433: Denied) alongside same-segment permits.

​
CVE exposure analysis

When a scanner flags a package on your gateways, exposure depends on reachability and traffic direction, not just package presence. The assistant can reason about both because it can read your DCF policy chain and security posture.
Reframing the question. This CVE targets the SSH client side, so “is port 22 reachable on the gateway” is the wrong question. The right question is “what on these gateways initiates outbound SSH to untrusted endpoints”, and the answer is: nothing in the observed traffic or configuration.Policy evidence: exactly one TCP/22 permit exists in the 30-policy DCF chain, scoped to a management SmartGroup. No gateway-initiated outbound SSH appears in 7 days of flow data.Verdict: the scanner undersold the footprint (all 14 spokes share the same base image, not just the flagged ones) and oversold the risk (no viable attack path under current policy). Recommended remediation: patch on the normal cycle as P3, not emergency P1; add a detection for unexpected outbound SSH as a compensating control.A SOC-ready handoff table with per-gateway package status and a P1-P4 action plan follows.

​
Kubernetes SmartGroup and DCF coverage

If you run Kubernetes behind Aviatrix, ask the assistant to map your SmartGroup selectors against your cluster reality. The mental model is close to a network policy label selector, enforced at the cloud network layer instead of the node.
47 SmartGroups total, 9 with native Kubernetes selectors. Three findings:
  1. The gcp-demo namespace selector is over-broad: it matches every pod in the namespace rather than the intended app labels.
  2. azure-aks is Kubernetes in name only: membership is CIDR-based with no label selectors, so pod churn silently breaks the mapping.
  3. The qa environment has zero Kubernetes SmartGroup coverage.
A note on the follow-up “which pods are covered”: the MCP server has no pod inventory tool. Kubernetes SmartGroups are dynamic; the selector is the definition. To verify actual membership, compare the selector against kubectl get pods --show-labels output, or check DCF logs for traffic attributed to the SmartGroup.

​
Operations

​
Pre-upgrade risk assessment

Before a controller or gateway upgrade, ask what tends to break. The assistant checks for the known risk patterns (custom SNAT, non-standard routing, missing HA, legacy features) with configuration evidence rather than folklore.
The assistant also checks your premise. In one validated run, a request for a “7.2 to 8.0 pre-upgrade check” was refused because every gateway already reported 9.0: the assistant flagged the version mismatch instead of performing a meaningless pre-flight.
Cleared risks: no custom SNAT found (snat_target empty, enable_nat=no across inspected gateways); no customized CIDRs, BGP over LAN, or PBR; at 25 gateways, scale is a non-issue.Risk register, ranked:
  1. Zero HA fabric-wide. No gateway has an HA peer, so every image upgrade is a hard data-plane outage for that VPC: 25 sequential micro-outages. Plan waves (dev, qa, prod) with transits in a dedicated window.
  2. transit-aws-us-east-1 is a single point of failure. FireNet, S2C termination, 4 transit peerings, 8 attachments, no HA peer. Verify vendor firewall re-registration behavior before and after.
  3. An apparently orphaned legacy FQDN gateway with zero tags attached. Legacy code paths are the most common upgrade casualties; identify the owner or decommission before upgrading.
  4. A Public Subnet Filtering gateway on a t3.micro. Niche legacy feature on a burstable instance; confirm filter behavior immediately post-upgrade.

​
On-call incident walk

When an application is reported down, one prompt can chain IP classification, path computation, gateway health, and policy verdicts.
Path walk for 10.2.2.100 to 10.1.2.10:8443:
  1. Classification: source is marketing-app-prod (marketing segment, Azure); destination is accounting-backend-api-prod (accounting segment, AWS).
  2. FlightPath: route exists end to end; security group and NACL checks pass on both sides. The cloud path is clean.
  3. Gateway health: all gateways on the path up, no resource distress, tunnels established.
  4. Policy verdict: DCF logs show the flow hitting default-deny-all. Marketing to accounting is not covered by any permit rule. This is segmentation working as designed, not an outage. If this flow is newly required, it needs an explicit policy, not a ticket to networking.

​
Investigating a log delivery gap

When a log type stops appearing in CoPilot, the fastest diagnosis is a binary search over log counts, then eliminating causes layer by layer. This method generalizes to any telemetry gap.
When: log counts over successive time ranges pin the cutoff to a single timestamp (in the validated run, 792,393 entries before the cutoff, zero after).What still works: enforcement is intact. The last logged entries show both Permit and Deny with is_enforced: True, all producing gateways are up and passing traffic, and other log types (gateway syslogs, NetFlow) continue to flow. So the gap is in DCF log delivery, not in the firewall and not in the gateways.What was ruled out, with evidence: no policy changes (audit timeline empty around the cutoff), per-rule logging still enabled on all 29 policies, syslog profile enabled and pointed at CoPilot, no external syslog redirect configured.Conclusion: every layer the API can verify is healthy, which isolates the fault to the log delivery pathway between controller and CoPilot. The cutoff coincides with a controller upgrade. Recommended next step: open a support ticket citing the exact cutoff timestamp, the build number, and the elimination evidence above. That evidence chain typically saves days of back-and-forth.

​
Network engineering and IaC

​
Topology diagram generation

Ask for a diagram of the fabric the MCP server can see. This use case depends on your client’s ability to write files; the MCP server supplies the topology data (gateways, peerings, attachments, edge sites), and the client renders it.
An editable .drawio file reflecting the live fabric: 5 transit gateways in full mesh across AWS, Azure, GCP, and OCI, 10 transit peerings, 14 spokes grouped by segment, 3 edge sites, and the FireNet transit marked with its inspection role. Because the data comes from the live Controller, the diagram matches reality rather than the last time someone updated a slide.

​
Terraform generation with live verification

The assistant can generate Aviatrix Terraform grounded in your actual fabric: real VPC IDs, real transit names, real account names, pulled through the MCP server instead of guessed.
The assistant first asks clarifying questions (which cloud, which VPC, HA or not, attach to which transit), then produces a module using the current provider schema with real values from the fabric: the target VPC ID, region, account name, and transit gateway name for attachment. Validate with terraform validate and review before applying, as with any generated IaC.

​
Capability boundaries

The MCP server is honest about what it cannot answer, and you should be aware of these limits before relying on it:
  • Gateway syslog retention is short, on the order of 24 hours. A question like “how many times did this tunnel flap in the past 6 months” is unanswerable from gateway syslogs, and the assistant should say so rather than guess. For long-horizon history, ship logs to a SIEM.
  • There is no pod inventory. Kubernetes SmartGroups are defined by their selectors; verifying actual pod membership requires cluster-side tooling.
  • Some data is not exportable via API in all builds, for example WebGroup domain contents in certain versions. The assistant will tell you when a value must be read from the CoPilot UI instead.
  • Scheduled rekeys are not flaps. IPsec IKE reauthentication appears periodically in logs as make-before-break events; a good response distinguishes these from real tunnel instability.
A refusal backed by a stated limitation is more useful than a fabricated answer. If your assistant confidently reports six months of tunnel history, be suspicious.

​
Prompting tips

  • Drill down instead of re-asking. After a sweep, reply with the finding number or a short phrase (“expand on finding 2”). The assistant reuses the data it already fetched.
  • State your premise and let it be checked. Include your assumed versions, topology, or timeline in the prompt. Validated runs show the assistant correcting a wrong upgrade premise rather than executing it.
  • Phrase time windows within retention. Ask about “the last 24 hours” or “the current log window” for gateway syslogs; use CoPilot-backed data (DCF logs, flow data) for multi-day windows.
  • Ask for a deliverable, not just an answer. “Give me a remediation summary I can hand to my SOC” or “what would I show an auditor” produces a structured artifact you can forward, not a chat reply you have to rewrite.
  • Any language works. The tools are language-agnostic; ask in the language your team works in.