Netmon Docs · Product Guide

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:

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.

Try it before you connect an appliance

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:

AreaWhat it answersTools
Health & inventory“How’s the network?”; what is monitored, per-device detail, day/week/month statsoverwatch_summary, device_list, device_find, device_get, device_metric_summary, interfaces_search, tags_list
Logs & security eventsSearch and summarize syslog, Windows event logs, and IDS eventssyslog_search, syslog_facets, eventlog_search, eve_search, eve_get, log_severity_summary
AlertingWhat is configured to fire, what actually fired and when, what is suppressedalerts_list, alerts_history, maintenance_windows_list
TrafficWho is using bandwidth, one host’s conversations, the full NetFlow historytop_bandwidth, flow_summary, netflow_search, netflow_raw_search
Windows agent hostsLive services, processes, and disk usage on agent-managed devicesagent_services, agent_processes, agent_disk_usage
Live probesReachability and interrogation, run from the appliance’s vantage pointping, traceroute, port_map, snmp_test, snmp_walk_run, snmp_walk_last
Context & lookupsChase one address across everything: every log and flow mention, WHOIS/GeoIP/DNS identity, LAN presence, WAN speed-test historysearch_ip, get_network_entity_info, arp_lookup, arp_table, speedtest_history
CapturesList finished packet-capture sessions and read their contentscapture_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:

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:

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>" }
    }
  }
}
Note

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.