
NetOps Field Notes
io.github.labaccessnowPublished by GitHub account labaccessnowv0.1.0Updated Oct 24, 2026
Config drift, CIS/PCI checks, 802.1X diagnosis, certs inside configs, topology, change pre-flight.
Overview
Read-only network operations toolkit that lets an assistant analyze pasted device configs: diffs, CIS/PCI checks, 802.1X diagnosis, certificates, topology and…
- What you can do
- Compare and explain config diffs across EdgeOS, RouterOS, OPNsense, EdgeSwitch and IOS-style configs, with risk ratings
- Run CIS/PCI compliance checks and get one-line fixes for each miss
- Diagnose 802.1X failures from RADIUS, switchport or supplicant logs, and look up ISE failure codes
- Find embedded certificates in configs and check expiry, weak keys and self-signed leaves, plus inspect a public host's TLS certificate
- Extract device facts, infer topology as a Mermaid diagram, explain OPNsense firewall rule changes, pre-flight a proposed change, and sanitize secrets before sharing a config
- When to use it
- Useful for network engineers and admins who want an assistant to review pasted switch, router or firewall configs, explain what changed, check basic compliance, troubleshoot port authentication, or judge whether a change is safe to push.
- Requirements
- Runs locally over stdio via uvx (needs Python 3.10 or newer, installed by uv) or as a Docker image. No account, API key or environment variables. Two tools need network access: one to the named public host for TLS checks, one to a public RSS feed.
Installation
In SourceWeft
- Open NetOps Field Notes 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
netops-field-notes-mcp
The things I check by hand on network gear, as tools your coding agent can call: what changed between two config snapshots and how much it matters, whether a config passes the CIS/PCI basics, why a port will not pass 802.1X, which certificates are hiding inside a config and when they expire, what a device is and what it sits next to, what an OPNsense rule change actually does, and whether a proposed change is safe to push.
Read-only. Deterministic — no model call, so two engineers get the same answer. No account, no telemetry, nothing read from your disk: configs and logs go in as text.
Install
Pin the version.
Claude Code
Claude Desktop, Cursor, or any client with a JSON config
Docker
Python 3.10 or newer for the uvx route (uv installs it). Also in the
official MCP registry as io.github.labaccessnow/netops-field-notes-mcp.
Tools
diagnose_dot1x
The one that saves the most time. Paste what you have — any of the three inputs — and it names the failure mode rather than restating the log:
It knows the difference between a CoA sent to port 1700 and one sent to 3799, an unknown-CA
failure and a missing client certificate, and a permit any any eq 443 dACL that IOS will reject.
find_certs_in_config
Web monitors watch ports. Certificates on network gear live in the config — Cisco crypto pki
chains, RouterOS exports, OPNsense <crt> blobs — and expire without anybody watching. This reads
them out of the text and applies the same rules as the endpoint check: expiry buckets, RSA under
2048, MD5/SHA-1 signatures, self-signed leaves (rated by where they are used), CA certificates
inside 90 days of expiry.
What it does not do
- No account, no signup, no key. No telemetry.
- Nothing is read from your disk; every input is text you pass in.
- Nothing is written to a device.
preflight_changetells you what would happen; applying it is your job, with the rollback it hands you. - Two tools open a socket:
check_tls_endpointto the host you name (it refuses private and reserved addresses, so it cannot be turned on your own network), andlatest_field_noteto a public RSS feed. - The compliance checks are regex over one config. They catch the obvious; they are not a benchmark run.
Where this comes from
These are the read-only cores of DriftWatch and its siblings, which run the same rules nightly across a fleet, keep the history, and turn the results into reports. Here you get the single-shot version on what you paste. That is deliberate — the rules are the useful part, and they work on their own.
Licence
MIT. Written by James Son — network, security, and automation engineer — and run against a live multi-vendor lab before shipping. Corrections welcome, especially to the ISE code table.
Source: README.md at commit 0b0cd88
Tools
0Version history
1- v0.1.0LatestSep 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