AI Assistants (MCP) v7.0.20
Connect Claude or any MCP-capable client to the appliance and ask it about your network in plain language. This page covers what the assistant can see, what it can never do, the guided playbooks, and how each kind of client connects.
The appliance is a Model Context Protocol (MCP) server. MCP is the open standard that lets AI assistants work with external systems, and Netmon speaks it natively: connect Claude — or any MCP-capable client — and the questions that used to mean four browser tabs and a mental join become a sentence:
- “Which devices went down this week, and what did they log right before?”
- “What’s eating the WAN uplink right now — and is that normal for a Tuesday?”
- “Summarize IDS activity since Friday. Which source IPs keep coming back?”
- “Is anything about to fill a disk on the Hyper-V hosts?”
The assistant answers by calling the same permission-checked API the web interface uses — as you, with your permissions and your tag scope. It is a new way to ask; it is not a new way in.
A public demo server answers the same 36 tools from recorded data, with no account and no appliance. The MCP Server page has the one-line setup for each client and two worked sessions.
What the assistant can see
A connected client is offered thirty-six tools, each a read window onto one part of the appliance. Most clients show tool names when asking your approval to use them, so they are listed here by group:
| Area | What it answers | Tools |
|---|---|---|
| Health & inventory | “How’s the network?”; what is monitored, per-device detail, day/week/month stats | overwatch_summary, device_list, device_find, device_get, device_metric_summary, interfaces_search, tags_list |
| Logs & security events | Search and summarize syslog, Windows event logs, and IDS events | syslog_search, syslog_facets, eventlog_search, eve_search, eve_get, log_severity_summary |
| Alerting | What is configured to fire, what actually fired and when, what is suppressed | alerts_list, alerts_history, maintenance_windows_list |
| Traffic | Who is using bandwidth, one host’s conversations, the full NetFlow history | top_bandwidth, flow_summary, netflow_search, netflow_raw_search |
| Windows agent hosts | Live services, processes, and disk usage on agent-managed devices | agent_services, agent_processes, agent_disk_usage |
| Live probes | Reachability and interrogation, run from the appliance’s vantage point | ping, traceroute, port_map, snmp_test, snmp_walk_run, snmp_walk_last |
| Context & lookups | Chase one address across everything: every log and flow mention, WHOIS/GeoIP/DNS identity, LAN presence, WAN speed-test history | search_ip, get_network_entity_info, arp_lookup, arp_table, speedtest_history |
| Captures | List finished packet-capture sessions and read their contents | capture_list, capture_get |
Tag scope follows you here as everywhere: a user restricted to certain tags gets the same restricted view through an assistant that they get in the browser.
What the assistant can never do
The tool surface is deliberately read-only. There is no tool that creates, edits, or deletes anything — not a device, not an alert, not a user, not a setting. The closest thing to “active” is the probe group, which runs the same ping, traceroute, port-scan, and SNMP operations the Network Tools pages run, from the appliance. Packet captures illustrate the boundary: the assistant can list and read sessions that exist, but cannot start one.
Guided playbooks
Alongside the tools, the server publishes three investigation playbooks (MCP prompts). Where the client surfaces them — a slash command, a prompt picker — depends on the client, but each walks the assistant through a proven sequence instead of leaving it to improvise:
- triage — cold-start “something is wrong” triage: fleet rollup, then log severities, then drill-down into whatever stands out.
- host_postmortem — one-host deep dive: identity, logs, in-host state (agent or SNMP), traffic context, assembled into a timeline.
- security_review — IDS-driven review: triage Suricata alerts, pivot on repeat-offender IPs, correlate with system logs.
Connecting Claude Desktop
The System → System Settings → Downloadables card publishes the Claude Desktop Extension (a .mcpb file). Install it in Claude Desktop (Settings → Extensions), and it asks for exactly two things:
- Netmon URL — the appliance’s MCP endpoint:
https://<your-netmon>/mcp - API Token — a personal access token. Mint one under System → Users with the key icon on your account; the creation form’s checkboxes decide which functional areas the token unlocks (devices, logs, alerts, and so on).
The extension works with the appliance’s certificate as shipped — self-signed included; it remembers the certificate the first time it connects.
Connecting other clients
Any client that speaks MCP over HTTP connects to the same endpoint:
https://<your-netmon>/mcp
Clients with OAuth support (Claude Code among them) need nothing pasted: first use opens a browser consent page where you sign in and approve the client and its scopes against your normal account. Clients without OAuth support send a personal access token with each request instead — for most of them, configuration looks like:
{
"mcpServers": {
"netmon": {
"url": "https://your-netmon.example.com/mcp",
"headers": { "Authorization": "Bearer <token>" }
}
}
}
Some clients verify TLS strictly and will refuse the appliance’s self-signed certificate. If yours does, install a certificate your workstations already trust (System → System Settings → HTTPS Certificate, covered in System Settings).
Where this sits in the access model
Nothing in this chapter adds a door; it reuses the ones you already manage. The API / MCP Access permission gates every connection. A token or consent acts as the account that approved it — permissions and tag scope included — and narrows further to the scopes chosen at creation. Revoking the token (or uninstalling the extension) ends the access; the token-hygiene guidance in API & Integrations applies to assistants unchanged. On the appliance side the whole feature is one service — MCP Server on the Services card — which you can stop like any other if policy requires it.