Netmon + AI Assistants
Netmon has a built-in MCP server, so AI assistants like Claude can inspect your devices, logs, traffic, and alerts — with the same sign-in and permissions as any operator. Here is what that looks like in practice.
MCP (the Model Context Protocol) is the open standard AI assistants use to talk to outside systems. Netmon ships an MCP server on the appliance: an assistant signs in through your browser with the same OAuth consent flow used by every Netmon API client, you choose exactly which scopes it gets — devices, logs, alerts, traffic, tools, captures — and from then on it can answer questions about your network by calling Netmon’s read tools directly. Tokens are scoped, revocable, and tied to your user account and tag restrictions, so the assistant sees only what you could see.
A simulated session
The conversation below is a scripted demonstration. The tool names are Netmon’s real MCP tools and the flow mirrors a genuine troubleshooting session, but the network, devices, and numbers are demo data, and tool results are shortened for readability.
The internet feels slow at the Windsor office this morning. Can you figure out what’s eating the bandwidth?
I’ll start with a fleet overview, then look at who is actually moving traffic.
overwatch_summary(){ "devices": 42, "up": 41, "warning": 1, "down": 0,
"warnings": [
{ "device": "fw-edge-01", "reason": "WAN interface utilization 94% (30-min avg)" }
] }top_bandwidth({ "minutes": 30 }){ "top_talkers": [
{ "ip": "10.10.4.61", "avg_mbps": 612.4, "direction": "outbound" },
{ "ip": "10.10.2.8", "avg_mbps": 88.1, "direction": "internal" },
{ "ip": "10.10.4.23", "avg_mbps": 12.7, "direction": "outbound" },
"…" ] }Your edge firewall is at 94% WAN utilization, and one host — 10.10.4.61 — is responsible for most of it: about 612 Mbps outbound over the last half hour. Let me identify that host.
get_network_entity_info({ "ip": "10.10.4.61" }){ "device_id": 118, "label": "WKS-ENG-14", "ip": "10.10.4.61",
"profile": "Windows Workstation (Agent)", "tags": ["workstation", "engineering"],
"agent": { "enrolled": true, "version": "7.0.20" },
"switch_port": { "device": "core-sw-01", "port": "Gi1/0/14" } }netflow_search({ "ip": "10.10.4.61", "minutes": 30 }){ "flows": [
{ "dst": "203.0.113.181:443", "proto": "tcp", "bytes": "21.4 GB",
"dst_name": "ingest-us2.cloudvault.example" },
{ "dst": "10.10.2.8:445", "proto": "tcp", "bytes": "310 MB" },
"…" ] }The host is WKS-ENG-14, an engineering workstation with the Netmon agent enrolled, patched into core-sw-01 port Gi1/0/14. Nearly all of its traffic — 21.4 GB in 30 minutes — is TLS to a CloudVault backup ingest endpoint. Since the agent is on the box, I can check what’s running.
agent_processes({ "device_id": 118 }){ "processes": [
{ "name": "CloudVaultSync.exe", "cpu_pct": 11.2, "read_mb_s": 74.8, "user": "SYSTEM" },
{ "name": "chrome.exe", "cpu_pct": 3.1, "read_mb_s": 0.2 },
"…" ] }Found it. CloudVaultSync.exe on WKS-ENG-14 is reading the disk at ~75 MB/s and pushing it to CloudVault over TLS — this looks like an initial full backup running during business hours, saturating your WAN uplink.
Nothing is broken and nothing looks malicious: the destination is a known backup service, the process runs as SYSTEM as a backup agent would, and the flow pattern is one sustained upload, not scatter-shot. The fix is scheduling, not security — move that workstation’s first full backup to an overnight window, or rate-limit the backup client, and the office link frees up immediately.
Nice. Can you make sure we hear about it before the WAN saturates next time?
alerts_list(){ "alerts": [
{ "label": "Device down — all devices", "class": "legacy", "enabled": true },
{ "label": "Syslog: FortiGate critical events", "class": "syslog_log", "enabled": true },
"…" ],
"note": "no interface-utilization alert found for fw-edge-01 WAN" }You have device-down and FortiGate syslog alerts, but nothing watching WAN utilization on fw-edge-01. This session is signed in with read scopes (mcp:devices, mcp:vne, mcp:logs, mcp:alerts), so I can’t create alerts for you — that’s by design.
An operator can add it in about a minute: on fw-edge-01’s device dashboard, set a threshold on the WAN interface tracker, then in the Alert Manager route it wherever your team lives — email, a webhook, Slack, Microsoft Teams, or Discord. Once it exists, I’ll see it and can check its history whenever you ask.
What just happened
Five tool calls, no dashboards opened: fleet state (overwatch_summary), top talkers (top_bandwidth), host identity (get_network_entity_info), traffic destination (netflow_search), and the responsible process (agent_processes) — because Netmon already had the flow records, switch-port mapping, and a Windows agent on the host. The assistant reasons; Netmon supplies the evidence.
Equally important is what the assistant could not do: its token carried read scopes only, so creating or changing alerts stayed with your operators. Scopes come from the same permission model as every other Netmon credential.
How it connects
- Get the connector. Point any MCP-capable client at the appliance directly; Claude Desktop users install Netmon’s extension bundle (see API & Integrations for setup).
- Sign in once. The assistant sends you to your Netmon in the browser; you sign in as yourself and approve the connection on a consent page that lists exactly which scopes it is asking for.
- Ask questions. From then on the assistant can query Netmon on your behalf — filtered by your permissions and tag restrictions, revocable from your profile at any time.
The same OAuth surface serves the PowerShell module and the Wireshark capture plugin — one sign-in model for every client. Details live in the Product Guide’s API & Integrations page and the API Reference authentication chapter.
What an assistant can ask
The MCP server exposes read tools across the whole product, gated by scope:
| Area | Example tools |
|---|---|
| Devices & fleet | device_find, device_get, device_metric_summary, overwatch_summary, tags_list |
| Traffic & topology | top_bandwidth, netflow_search, get_network_entity_info, port_map, arp_table |
| Logs & security | syslog_search, eventlog_search, eve_search, log_severity_summary |
| Alerts | alerts_list, alerts_history, maintenance_windows_list |
| Windows agent | agent_processes, agent_services, agent_disk_usage |
| Live tools | ping, traceroute, snmp_walk_run, snmp_test, speedtest_history, capture_list |