
NetOps Field Notes
io.github.getlarkwrightPublished by GitHub account getlarkwrightv0.1.1Updated Nov 7, 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 diff device configs, run CIS/PCI checks, diagnose 802.1X, inspect certificates and pre-flight…
- What you can do
- Compare two config snapshots and explain what changed, risk-rated by section
- Run ten CIS/PCI compliance checks and get one-line fixes for misses
- Diagnose 802.1X failures from RADIUS, switchport or supplicant logs, and look up ISE failure codes
- Find embedded certificates in configs and check a public host's served certificate
- Extract device facts and infer topology as a Mermaid diagram
- Explain OPNsense firewall rule changes, pre-flight a proposed change, sanitize secrets, and fetch a weekly networking note
- When to use it
- Useful when you work with network gear configs (EdgeOS, RouterOS, OPNsense, EdgeSwitch, Cisco IOS-style) and want a second, deterministic opinion on drift, compliance, 802.1X failures, certificate expiry or whether a change is safe to push.
- Requirements
- Runs locally over stdio; no account, key or environment variables. Install via uvx with Python 3.10 or newer, or run the published container image with Docker. Network access is needed only for the TLS endpoint check and the RSS field-note tool.
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.getlarkwright/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 © Larkwright LLC. 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 9f59dd5
Tools
0Version history
1- v0.1.1LatestNov 7, 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
