Netmon
com.netmonPublished by netmon.comv0.1.9Updated Oct 24, 2026
Query devices, alerts, syslog, Suricata IDS, NetFlow and captures on your Netmon appliance.
The publisher's own server: Netmon (demo)
Overview
A local bridge that connects an AI assistant to a Netmon network-monitoring appliance, letting it read devices, logs, flows, alerts and captures.
- What you can do
- Find, list and inspect monitored devices, tags, interfaces and device metrics, plus Windows-agent processes, services and disk usage on managed hosts. Search and summarize syslog, Windows event logs and Suricata IDS events, and break down log severities and syslog fields. Search NetFlow history and raw flows, rank top bandwidth talkers, summarize a host's conversations, and read the ARP table. List alert definitions, alert incident history and maintenance windows. Run live diagnostics from the appliance: ping, traceroute, ARP lookup, port scan, SNMP test and walk, WHOIS/GeoIP/DNS lookup, and cross-stream IP search. List packet captures and their status, and read WAN speedtest history.
- When to use it
- Useful when you run a Netmon appliance and want an assistant to answer operational questions in plain language, such as what is down, which host is using the most bandwidth, or what Suricata alerts fired last week. A public read-only demo endpoint lets you try the same tools without an appliance.
- Requirements
- A Netmon appliance running 7.0.20 or newer with the MCP server enabled, reachable over HTTPS. A user account with the API permission and a personal access token carrying the mcp scopes you want. Claude Desktop for the .mcpb install (it supplies its own Node runtime); running the bridge elsewhere needs Node 18 or newer. The appliance URL must include the /mcp path.
Installation
In SourceWeft
- Open Netmon in the dashboard and add it to a workspace.
- Enable the server for the chats that should use its tools.
Desktop only via STDIO. STDIO servers start a local process, so they need the SourceWeft desktop host.
Other MCP clients
Follow the launch instructions in the repository.
README
Netmon MCP
Connect an AI assistant to a Netmon appliance.
Netmon ships an MCP server on the appliance itself. This repository holds the client-side bridge: a small Node process that runs on your own machine, speaks stdio to Claude Desktop, and forwards every JSON-RPC message to your Netmon's /mcp endpoint over HTTPS.
Once connected, an assistant can read your devices, interfaces, logs, flow records, alerts, and Windows-agent data by calling Netmon's tools directly — with the same sign-in and permissions as any operator, and the same tag restrictions.
- Product overview and public demo: https://netmon.com/mcp-server/
- Setup guide: https://netmon.com/netmon-7-user-guide/ai-assistants/
- API reference: https://netmon.com/api-reference/authentication/
Try it first — no appliance needed
A public, read-only demo server answers the same 36 tools from a recorded, de-identified snapshot of a fictional 90-device network:
No account, no token, no install. Point any MCP client at it:
GUI clients — Claude Desktop (Settings → Connectors → Add custom connector) and ChatGPT (developer mode → Connectors) — take the URL with authentication set to None. For Cursor, Zed, Kimi Code CLI, Continue and LM Studio, drop the URL into that client's MCP config file:
Then ask it something real: "what's down?", "show me the Suricata alerts from last week", "which host is using the most bandwidth, and who is it talking to?"
It is a fixture, not an appliance: nothing writes, nothing reaches a real network, and every answer is the same shape a live Netmon returns — with timestamps shifted forward so the snapshot always reads as the last day or so.
Why a local bridge
Two separate walls stand between an MCP client and an appliance on your LAN, and the bridge exists for both.
Where the connection comes from. Claude Desktop's remote-connector option and ChatGPT's custom connectors both fetch the MCP URL from their vendor's cloud, not from your machine — Anthropic's docs say so outright, and their connector resolves the hostname and rejects private addresses before any request leaves their network, so your appliance's log stays empty. Most other clients (Claude Code, Codex, Gemini CLI, Cursor, VS Code, Zed, Cline, Continue, opencode, Goose, LM Studio, Kimi) connect from your own machine and are unaffected.
The certificate. This one catches nearly everyone. Most clients validate TLS against the operating system trust store and expose no skip-verify option, and an appliance ships a self-signed certificate — so the route succeeds and the handshake fails. Either install the appliance's certificate in the machine's trust store, or use the bridge, which pins it on first use.
The bridge runs as a local process and handles both. It is not a Claude-specific workaround; it is the general answer.
If your appliance is internet-facing with a publicly-trusted certificate, you can skip the bridge and point any MCP client straight at the endpoint. See Install — any MCP client below.
Requirements
- A Netmon appliance with the MCP server enabled (Netmon 7.0.20 or newer).
- A user account with the API permission, and a personal access token carrying the
mcp:*scopes you want the assistant to have. - Claude Desktop for the
.mcpbinstall. Claude Desktop supplies its own Node runtime, so nothing else is needed. Running the bridge outside Claude Desktop requires Node 18 or newer.
Install — Claude Desktop
-
Download
netmon-mcp-<version>.mcpbfrom Releases. The same bundle ships with your appliance — Settings → System → Downloadables → Claude Desktop Extension. -
In Claude Desktop, open Settings → Extensions → Advanced settings → Extension Developer → Install Extension… and select the file.
-
Fill in the two settings the extension asks for:
-
Restart the extension. Ask Claude something like "list the devices that are down" to confirm it is working.
Minting a token
In Netmon, go to Settings → Users, click the key icon on your user, and create a personal access token. Select only the scopes the assistant needs — the token cannot be widened later, and it can be revoked from the same screen at any time.
The account must hold the API permission. Without it, token minting and OAuth consent are both refused.
Install — any MCP client
The appliance serves Streamable HTTP at https://<your-netmon>/mcp (POST for JSON-RPC, GET for the server-to-client SSE stream, DELETE to end a session).
Clients that support OAuth 2.1 discover the authorization server on their own: the endpoint answers an unauthenticated request with 401 and a WWW-Authenticate: Bearer resource_metadata="…" challenge pointing at RFC 9728 protected-resource metadata, alongside RFC 8414 authorization-server metadata and dynamic client registration at /auth/register. You sign in through your browser on your own Netmon and approve the scopes on a consent page.
Clients without OAuth support pass a token directly:
Claude Code and self-signed certificates
Most appliances serve a self-signed certificate. A direct type: http entry will fail against one — the OAuth bootstrap rejects the certificate and does not consult NODE_EXTRA_CA_CERTS. Use the bridge instead, which handles the certificate itself:
Tools
36 read tools, each wrapping a Netmon API endpoint and gated by an OAuth scope that is checked before the call runs.
All 36 tools
Eight scopes exist in total — the six above plus mcp:reports and mcp:system, which map to their permissions but have no tools yet.
Security model
Everything stays on your appliance. The bridge connects to the one URL you configure and nothing else. No telemetry, no vendor endpoint, no third-party service sits in the path. Netmon Services receives nothing.
Read-only. Every tool is a read. Netmon's agent write paths — killing a process, starting or stopping a Windows service, deleting a file, running PowerShell — are permanently excluded at the MCP layer, regardless of what the underlying token's permissions would otherwise allow. An assistant cannot change your monitoring configuration, acknowledge an alert, or act on a managed host.
Scoped. Each tool declares the OAuth scope it requires, and the scope is checked before the tool body runs. A token granted mcp:logs only cannot call device_list.
Yours, and no wider. A token acts as the user who minted it. Tag restrictions apply: an operator limited to the branch-offices tag gets an assistant limited to the same devices. The permission model is the one already governing the web interface and every other API client.
Revocable. Revoke a token from Settings → Users and the assistant loses access immediately. Tokens can also be scoped narrowly at mint time rather than revoked later.
Transport security
On first connection the bridge captures the appliance's TLS certificate and stores it at ~/.netmon-mcp/<hash-of-url>.pem, then verifies every later connection against that pinned certificate. This is trust-on-first-use: it protects against interception after the first connection, not during it. Make the first connection from a network you trust.
If you replace the appliance's certificate, delete the stale pin (rm ~/.netmon-mcp/*.pem) or the bridge will verify the new certificate against the old one and refuse to connect.
The bridge requires https://. Plain HTTP is rejected at startup.
Troubleshooting
The bridge writes a diagnostic log to ~/.netmon-mcp/wrapper.log.
Building
Output lands in build/netmon-mcp-<version>.mcpb.
Privacy Policy
Full policy: https://netmon.com/privacy-policy/
What is collected. This bridge collects no data. It holds no account, no analytics, and no callback to Netmon Services. Two files are written locally, both under ~/.netmon-mcp/: the pinned certificate of the appliance you configured, and a diagnostic log of connection events. Your Netmon URL and token are supplied by you and are held only in the extension's own configuration.
How data is used and stored. Queries and results pass between your MCP client and your appliance. The bridge forwards messages and retains none of them. All monitoring data stays in the appliance's database, under your control, in your building.
Third-party sharing. None. The bridge contacts exactly one host — the appliance URL you configure. It sends nothing to Netmon Services or any other party.
Note that your MCP client is a separate product with its own policy. When you ask an assistant a question, the tool results it receives are handled by that client's vendor under their terms. Netmon does not control that leg, which is why the scopes on a token are worth setting narrowly.
Retention. Local files persist until you delete them: remove the extension, or rm -rf ~/.netmon-mcp. Revoking the token in Settings → Users ends access immediately. Retention of the monitoring data itself is configured on your appliance, by you.
Contact. [email protected]
Support
- Documentation: https://netmon.com/documentation/
- Issues with the bridge: GitHub Issues
- Everything else: [email protected]
License
Mozilla Public License 2.0 — see LICENSE.
Source: README.md at commit 484852b
Tools
0Version history
1- v0.1.9LatestSep 16, 2026
Score
50% of the applicable checks met
How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.
- Reached in the last 30 days25 pts
Keep the endpoint answering the MCP handshake; SourceWeft probes it every 30 days.
- Auth declared10 pts
Declare the credential headers in the registry entry, or keep the endpoint answering the probe so its auth can be classified.
- Tools listed15 pts
Answer tools/list without a credential, or ship a package that starts in a sandbox without one.
- DescriptionRequired15 pts
- Logo10 pts
- Documentation15 pts
- License10 pts