Analyzes Cisco IOS-style configuration snapshots and Cisco ISE authentication failure codes, supporting config diffs, 802.1X diagnosis, and embedded certificate discovery.
Inspects OPNsense config.xml changes and firewall rule modifications, providing risk assessment, shadowing notes, and embedded certificate checks.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@netops-field-notes Here's a RADIUS log and switchport config — why won't this port authenticate?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
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.
Pin the version.
Claude Code
claude mcp add netops-field-notes -- uvx --from "git+https://github.com/labaccessnow/netops-field-notes-mcp@v0.1.0" netops-field-notes-mcpClaude Desktop, Cursor, or any client with a JSON config
{
"mcpServers": {
"netops-field-notes": {
"command": "uvx",
"args": ["--from", "git+https://github.com/labaccessnow/netops-field-notes-mcp@v0.1.0", "netops-field-notes-mcp"]
}
}
}Docker
{
"mcpServers": {
"netops-field-notes": {
"command": "docker",
"args": ["run", "-i", "--rm", "ghcr.io/labaccessnow/netops-field-notes-mcp:0.1.0"]
}
}
}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.
Related MCP server: netmiko-mcp
Tool | What it answers |
| What changed between two snapshots, grouped by section, risk-rated, in plain English — EdgeOS, RouterOS, OPNsense, EdgeSwitch, Cisco IOS-style |
| Does this config pass ten CIS/PCI checks, and what is the one-line fix for each miss |
| Why won't this port authenticate — from the RADIUS log, the switchport config and/or the supplicant log |
| What does ISE step code 12514 (or 11036, 22056…) mean and what fixes it |
| Which certificates are embedded in this config, and which are expiring, weak or self-signed |
| The same findings on the certificate a public host actually serves |
| Hostname, role, addresses, subnets, VLANs from a config |
| Which of these devices share segments — as a Mermaid diagram |
| An OPNsense config.xml change, rule by rule, with risk grounds and shadowing notes |
| Is this proposed change safe — risk, compliance regressions, blast radius, a gate verdict |
| Scrub secrets and map addresses consistently before a config goes anywhere |
| What happened in networking this week |
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:
ROOT CAUSE
Two defects: (1) dot1x failed on an EAP mismatch (EAP-TLS vs EAP-PEAP); (2) MAB then
Accepted with NO dynamic VLAN, so the endpoint landed on VLAN 10 instead of VLAN 30.
RECOMMENDED FIX
1. Align EAP: either enroll a client cert + set the supplicant to EAP-TLS, OR allow EAP-PEAP
in the ISE auth policy for this port. Make both ends match.
2. Fix the ISE authorization profile "MAB_Guest": add Tunnel-Type=VLAN(13),
Tunnel-Medium-Type=802(6), Tunnel-Private-Group-ID=30.
3. On the access port add: `authentication event fail action authorize vlan 30` as a local backstop.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.
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.
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_change tells you what would happen; applying it is
your job, with the rollback it hands you.
Two tools open a socket: check_tls_endpoint to the host you name (it refuses private and reserved
addresses, so it cannot be turned on your own network), and latest_field_note to a public RSS feed.
The compliance checks are regex over one config. They catch the obvious; they are not a benchmark run.
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.
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.
Run a CIS/PCI starter pack over one device config: cleartext management, SSH, default SNMP communities, centralised AAA, remote logging, NTP, hashed credentials, default credentials, management exposed to any source, login banner. Ten deterministic checks, each with a framework reference and a one-line remediation. Cisco, MikroTik, EdgeOS, OPNsense.
| Name | Required | Description | Default |
|---|---|---|---|
| config | Yes | ||
| vendor | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses that there are ten deterministic checks, each returning a framework reference and a remediation line, and it lists the concrete checks. It does not explicitly state whether the operation is read-only, offline, or if any network/device access is required, though 'over one device config' implies offline analysis.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense sentence that front-loads the tool's purpose, then efficiently lists checks, output characteristics, and supported vendors. Every clause adds useful information with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema covers return values, so the description does not need to explain those. What is missing is explicit treatment of the `vendor` parameter and clearer routing guidance versus siblings. For a simple two-parameter tool, the description is otherwise quite complete, but those gaps prevent a higher score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It makes clear that `config` is a device config and that supported vendors are Cisco, MikroTik, EdgeOS, and OPNsense. However, it never explicitly ties these vendors to the `vendor` parameter, does not state that `vendor` is optional or what happens when it is empty, and provides no parameter-level guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Run') and a specific resource ('CIS/PCI starter pack over one device config'), and enumerates the exact check categories. It clearly distinguishes this tool from siblings like sanitize_config or explain_config_diff by defining a distinct compliance-checking behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: it operates over one device config and supports four named vendors, so an agent can infer when to call it. However, it gives no explicit 'when not to use' or alternatives, such as pointing to sanitize_config for cleanup or explain_config_diff for change understanding.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Connect to a public host:port, read the certificate it actually serves, and run the same findings as find_certs_in_config on it (expiry, weak key, weak signature, self-signed, hostname not in SANs, CA expiry). Any port. Refuses hosts that resolve to private or reserved addresses.
| Name | Required | Description | Default |
|---|---|---|---|
| host | Yes | ||
| port | No | ||
| role | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, and it discloses meaningfully: it reads the certificate the host 'actually serves' (live data, not config), accepts any port, and refuses private/reserved address resolutions — an important SSRF-style safety behavior. The enumerated findings also tell the agent what classes of issues it will surface. It omits failure behavior (timeouts, unreachable hosts, non-TLS ports), but the disclosed traits go well beyond the bare schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences with zero filler: the first front-loads the action and finding set, the second adds the safety constraint. Every phrase earns its place, including the parenthetical finding list that would otherwise require a schema or docs lookup.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a network-dependent tool with an output schema, the core purpose, constraints, and safety behavior are well covered, and return values are handled by the schema. The gaps are the unexplained role parameter and the absence of failure-mode context (timeouts, connection refusal, non-TLS endpoints), which an agent would need to anticipate errors when invoking a live-network tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description is the only source of parameter meaning, and it does clarify host ('public host:port') and port ('Any port'). However, the role parameter is completely unexplained — its likely semantic (e.g., SNI name) is left to the agent to guess, which is a real gap given nothing else documents it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action sequence (connect to a public host:port, read the served certificate) and enumerates the exact findings (expiry, weak key, weak signature, self-signed, hostname not in SANs, CA expiry). It also distinguishes itself from the sibling find_certs_in_config by framing this as the live-endpoint variant, so an agent can tell them apart without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'run the same findings as find_certs_in_config on it' clearly situates this tool against its sibling, implying the config-checking alternative for offline analysis. The 'Refuses hosts that resolve to private or reserved addresses' constraint and 'Any port' scope give an agent concrete boundary conditions for when the tool applies. It stops short of an explicit when-not rule, but the routing signal is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Diagnose a port that will not authenticate. Paste any of: the RADIUS/ISE authentication log, the switchport interface config, the supplicant (Windows wired AutoConfig) log. Names the root cause — EAP method mismatch, unknown CA, shared-secret/NAD mismatch, missing dynamic VLAN, CoA NAK on the wrong port, invalid dACL — decodes ISE failure codes, and gives the fix on the switch AND in ISE. Read-only, rule-based.
| Name | Required | Description | Default |
|---|---|---|---|
| radius_log | No | ||
| supplicant_log | No | ||
| switchport_config | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states 'Read-only, rule-based,' and explains what the tool will name and deliver, including fixes on both switch and ISE. It does not discuss failure behavior on unparseable input or limits on log size, but the core behavioral traits are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and information-dense, front-loading the core purpose before enumerating inputs, root causes, and outputs. Every clause adds value; the final 'Read-only, rule-based' tag is a useful behavioral note without surplus wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a diagnostic tool with free-text log inputs, the description covers inputs, scope, root causes, and fix guidance well. An output schema exists, so return-value documentation is not the description's job. Minor gaps remain around handling malformed or empty input and when to prefer lookup_ise_failure_code for a single failure code, but the description is largely complete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It maps the three inputs conceptually: RADIUS/ISE log, switchport config, supplicant log, and says 'any of' may be pasted. However, it does not give format hints, size expectations, or more explicit per-parameter guidance, leaving some ambiguity for an agent preparing the call.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Diagnose a port that will not authenticate,' then details the exact inputs (RADIUS/ISE log, switchport config, supplicant log) and outputs (root cause, fix). This clearly distinguishes it from broader diagnostic or parsing siblings like check_config_compliance or extract_device_facts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit context for when to use the tool: when a port will not authenticate. It also tells the agent what to paste. It does not explicitly name alternative tools or exclusion conditions, but the usage context is clear and actionable despite that.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explain what changed between two network device config snapshots, in plain English. EdgeOS, MikroTik RouterOS, OPNsense config.xml (per-rule stories, save-stamp noise filtered), EdgeSwitch and Cisco IOS-style configs: volatile lines stripped, changes grouped by config section, each tagged with a risk level and why it matters. Deterministic — no model call, nothing leaves the machine.
| Name | Required | Description | Default |
|---|---|---|---|
| after | Yes | ||
| before | Yes | ||
| device | No | ||
| vendor | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description takes on the full burden and does it well: it discloses determinism ('Deterministic — no model call'), privacy ('nothing leaves the machine'), preprocessing ('volatile lines stripped, save-stamp noise filtered'), and output behavior ('grouped by config section, each tagged with a risk level and why it matters'). This goes far beyond a simple 'explains diff' statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences, front-loaded with the core action and resource. Every clause adds value: platform coverage, noise filtering, grouping, risk tagging, determinism, and data locality. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential behavioral context an agent needs: input domain, supported formats, processing quirks, output shape, and privacy/determinism guarantees. Since an output schema exists, the description does not need to detail the return structure, and the provided text is sufficiently complete for this moderately complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so parameters are bare names. The description compensates by clarifying that 'before' and 'after' are full config snapshots and by listing vendor-specific formats that map to the 'vendor' parameter. It does not define 'device' explicitly, but the overall context is sufficient for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Explain what changed between two network device config snapshots, in plain English.' It enumerates the supported platform formats and states the core output (grouped changes, risk levels), which clearly distinguishes it from siblings like explain_firewall_change or sanitize_config.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the intended use clear: comparing two config snapshots and getting a plain-English explanation. It lists supported vendors/formats, giving an agent concrete criteria for when to select this tool, though it does not explicitly state when not to use it or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explain a change between two OPNsense config.xml captures rule by rule: which rules were added, removed, edited or moved (keyed by uuid, so an edit is not mistaken for delete-plus-add), what each rule does in plain English, a risk rating with its stated grounds (any-source to a management port, any-source to the firewall itself, any/any/any pass), shadowed-rule notes, and which API call made the change. Save-stamp noise is recognised and set aside.
| Name | Required | Description | Default |
|---|---|---|---|
| after | Yes | ||
| before | Yes | ||
| device | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It reveals non-obvious behavior: changes are keyed by uuid to avoid confusing edits with delete-plus-add, save-stamp noise is recognized and set aside, and risk ratings include their stated grounds. It does not discuss permissions, limits, or side effects, but as a read-style explainer the disclosed detail is strong.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The main capability is front-loaded and every clause in the description carries high-signal information: uuid keying, plain-English rule explanations, risk grounds, shadowed-rule notes, API attribution, and save-stamp noise handling. There is no filler or repetition of schema field names.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex analysis tool with no annotations and no schema descriptions, this description covers the core domain, key behaviors, and important output semantics well. The main missing context is the 'device' parameter and explicit routing among sibling diff tools, so it falls just short of fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It indirectly defines 'before' and 'after' as OPNsense config.xml captures, but it never explains the optional 'device' parameter or how it relates to attributing 'which API call made the change'. With three parameters and zero property descriptions, this is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Explain a change between two OPNsense config.xml captures rule by rule'. It then enumerates distinct output facets such as added/removed/edited/moved rules, risk ratings, shadowed-rule notes, and API attribution, clearly differentiating it from generic siblings like explain_config_diff.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended context is implied by 'OPNsense config.xml' and the firewall-rule focus, but the description never explicitly states when to use this tool versus alternatives. It also does not name a sibling tool or provide any when-not-to-use guidance, so the agent must infer the boundary with generic config diff tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pull the facts out of a device config: hostname, inferred role, every IPv4 address with its subnet, the subnets it sits on, and its VLANs. EdgeOS config.boot, MikroTik export, OPNsense config.xml, EdgeSwitch/FastPath, and Cisco IOS-style text.
| Name | Required | Description | Default |
|---|---|---|---|
| config | Yes | ||
| device | No | ||
| vendor | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It usefully discloses the accepted input formats and the extraction outputs, but it does not mention failure behavior, handling of unsupported formats, or whether the operation is purely local/read-only. The supported formats add some transparency, but richer caveats about parsing limitations would improve it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with no filler. The main action and outputs are front-loaded, and the config format list is compactly appended. Every sentence adds meaningful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists and the input schema is simple, the description covers the key invocation context: what to pass and what to expect. It misses only guidance on the optional 'device' and 'vendor' parameters and edge cases, but these are minor gaps relative to the provided schema and output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for all three parameters. It clearly implies that 'config' is the device configuration text and hints at vendor formats, but it never explains the 'device' parameter and does not explicitly connect 'vendor' to parsing behavior. Two of three parameters remain effectively undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Pull') and resource ('device config'), then enumerates the exact facts extracted: hostname, inferred role, IPv4 addresses with subnets, subnets, and VLANs. It also names the supported config formats, which clearly distinguishes this parsing/extraction tool from siblings like explain_config_diff or check_config_compliance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by listing the supported device config formats (EdgeOS, MikroTik, OPNsense, EdgeSwitch/FastPath, Cisco IOS-style), making it apparent when this tool applies. It does not explicitly state when to avoid it or name alternatives, but the sibling tool names are distinct enough that an agent can infer the appropriate use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find every certificate embedded in a device config and check it: expiry (with severity buckets), weak RSA keys, MD5/SHA-1 signatures, self-signed leaves, CA certificates about to expire. Reads inline PEM blocks (Cisco crypto pki chains, EdgeOS, RouterOS exports, anything) and OPNsense config.xml blobs — the certificates web monitors never see because they are inside the config, not on a port.
| Name | Required | Description | Default |
|---|---|---|---|
| role | No | ||
| config | Yes | ||
| vendor | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does well: it discloses that the tool reads inline PEM blocks from multiple vendor formats and OPNsense config.xml, and enumerates the certificate health checks it performs. The read-only nature is evident from 'Find,' 'check,' and 'Reads,' though it does not discuss error handling or edge cases like malformed configs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is information-dense but not bloated: the first sentence states scope and checks, and the second adds supported formats and the differentiator about web monitors. Every clause contributes meaning, with no filler or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool's parsing complexity and check variety are well covered, and the output schema presumably handles return-value structure. The only notable gap is the undocumented `role` parameter, though it is optional with a default, so the core invocation with just `config` remains clear enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides useful context for `config` and `vendor` through examples like Cisco, EdgeOS, RouterOS, and OPNsense formats, but it never explains the `role` parameter at all, and it does not explicitly link the prose to the parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource ('Find every certificate embedded in a device config and check it') and enumerates precise checks: expiry severity buckets, weak RSA keys, MD5/SHA-1 signatures, self-signed leaves, and expiring CAs. It also differentiates from sibling tools by noting these are certificates 'inside the config, not on a port,' which clearly separates it from check_tls_endpoint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly establishes when to use the tool: when certificates are embedded in device configs or OPNsense config.xml blobs, and it explicitly contrasts with port-based certificates. However, it never names an alternative tool directly or gives an explicit when-not-to-use statement, so the routing is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Given several device configs, work out which devices share subnets or VLANs and draw the segments as a Mermaid diagram (graph LR). Shared-subnet inference: two devices with an interface on the same network are adjacent. A subnet contained in a broader declared one is merged into it. Prefixes shorter than /16 are ignored as too broad to mean a segment.
| Name | Required | Description | Default |
|---|---|---|---|
| devices | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does substantial work: it explains adjacency, subnet merging, the /16 cutoff, and the Mermaid output format. The main gap is that VLAN inference is mentioned up front but not explained in the same detail as subnet inference.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well structured: purpose first, then precise inference rules, each earning its place. There is no repetition of schema information and no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description appropriately focuses on input and behavior. It covers the main algorithm rules and output type. The only substantive omission is the exact behavior for the VLAN portion of the stated purpose and any failure behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description complements the schema by clarifying that the single devices parameter is a set of configs whose interfaces are parsed for network adjacency. This adds semantic meaning beyond the schema's bare field definitions, though it does not mention the optional vendor property.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states exactly what the tool does: consume multiple device configs, infer subnet/VLAN adjacency, and produce a Mermaid diagram. It clearly distinguishes this from sibling tools like extract_device_facts or explain_config_diff by naming a specific output artifact and inference goal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"Given several device configs" provides a clear usage context, and the inference rules make it obvious when this tool applies. There is no explicit when-not-to-use guidance, but no sibling appears to perform topology inference, so exclusions are less critical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The most recent This Week in NetOps episodes — what changed in networking, cloud and automation this week and what to do about it. The only tool here that touches the network besides check_tls_endpoint; it reads a public RSS feed.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states that the tool reads a public RSS feed, implying a read-only external fetch rather than a network mutation. It does not detail failure modes, but for a simple feed retrieval this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the core purpose in the first sentence. The second sentence adds useful sibling differentiation and source context, though the claim about touching the network is slightly ambiguous.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one optional parameter and an output schema, the description covers the purpose, content scope, and data source. It leaves out explicit guidance on the count parameter, but the output schema and simple schema reduce the need for more detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, count, is never referenced in the description, and schema description coverage is 0%. The agent must infer from the parameter name and default value that count controls how many episodes are returned; the description adds no semantic value here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (This Week in NetOps episodes), the temporal scope (most recent), and the content domain (changes in networking, cloud, and automation). It also distinguishes itself from sibling tools by noting it is one of only two tools that touch the network along with check_tls_endpoint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied: agents should call this when they need the latest weekly NetOps field notes. It names check_tls_endpoint as a sibling with network-touching behavior, but it does not explicitly state when to prefer this tool over that one or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Decode a Cisco ISE / RADIUS failure or step code (5400, 5411, 5440, 11007, 11036, 11514, 12321, 12508, 12514, 15039, 22056): what it means, the usual cause, and the fix.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the behavioral disclosure burden. It usefully states the output content ('what it means, the usual cause, and the fix'), but it does not explicitly confirm this is a read-only lookup or describe behavior for unknown or malformed codes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence that names the action, resource, example inputs, and output structure. The list of twelve example codes adds length but is genuinely useful for confirming the expected input domain.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter lookup tool with an output schema, the description is complete enough for an agent to select and invoke it correctly. The main gap is the absence of routing guidance relative to sibling diagnostic tools, but that does not prevent correct use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only a bare string parameter with 0% description coverage, so the description must compensate. It adds a list of example codes and clarifies the parameter is a 'failure or step code', giving the agent a practical expectation. It stops short of specifying exact formatting rules, such as numeric-only values or handling of leading zeros.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Decode') and a specific resource ('Cisco ISE / RADIUS failure or step code'), and gives concrete example codes. This clearly separates it from sibling tools that check, diagnose, or modify configurations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use case—interpreting an ISE/RADIUS code—is implied by the description, but there is no explicit guidance on when to choose this over siblings like diagnose_dot1x or when not to use it. No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Before you push a change: diff the proposed config against the current one, risk-tag every change, list compliance checks that would regress, and — if you pass the configs of the other devices you manage — compute the blast radius (who shares the affected subnets and VLANs). Returns a gate verdict: BLOCK, REVIEW REQUIRED, PROCEED WITH CARE, or NO CHANGE. Read-only; nothing is applied.
| Name | Required | Description | Default |
|---|---|---|---|
| fleet | No | ||
| device | No | ||
| vendor | No | ||
| current | Yes | ||
| proposed | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and handles it well: it states 'Read-only; nothing is applied', which is the decisive safety trait, and it also discloses the conditional blast-radius behavior and the exact verdict vocabulary. No annotation contradiction exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences front-load the operational context ('Before you push a change') and then enumerate the analysis steps, verdict, and safety property. Every clause earns its place; there is no filler or repetition of schema boilerplate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a preflight gate with an output schema, the description is nearly complete: it names the verdicts, covers the core diff inputs, defines blast-radius conditions, and states read-only status. The remaining gaps are minor but real: device/vendor parameters are unexplained, and no sibling routing is given for diff-only or compliance-only needs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning for current/proposed (the diff pair) and fleet (configs of other managed devices for blast radius). However, schema description coverage is 0% and the description never mentions the 'device' or 'vendor' parameters, leaving those roles to be guessed despite the vendor options in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource: diff a proposed config against current, risk-tag changes, identify compliance regressions, and compute blast radius, ending in a gate verdict. The 'gate verdict' framing clearly separates it from sibling tools like explain_config_diff and check_config_compliance, which only analyze or check rather than gate a change.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Before you push a change' gives an explicit trigger condition, and the 'if you pass the configs of the other devices you manage' clause defines when fleet input matters. It does not name alternatives or explicitly say when NOT to use this tool, so it falls one step short of the top score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scrub a config before it goes anywhere: passwords, secrets, RADIUS/TACACS keys, IPsec PSKs, SNMP communities, MD5 digests, Wi-Fi PSKs, key/certificate blocks and hashes are redacted; IPv4 addresses are mapped consistently to RFC 5737 documentation ranges (same address, same placeholder, so the logic still reads), IPv6 to 2001:db8::, MACs to the RFC 7042 range, hostnames to ROUTER-n, domains and emails to example.com. Subnet and wildcard masks are preserved. Returns the clean text and a count per category.
| Name | Required | Description | Default |
|---|---|---|---|
| config | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure and does so richly. It lists exact redaction categories, explains deterministic placeholder mapping for IPv4/IPv6/MACs/hostnames/domains, notes preservation of subnet and wildcard masks, and states that it returns clean text plus per-category counts.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well organized, front-loading the main purpose and then efficiently enumerating behaviors without filler. Every clause adds useful information, and the return behavior is stated at the end.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single string parameter, no annotations, and an existing output schema, the description provides enough context for an agent to select and invoke the tool correctly. It covers the input scope, transformation rules, and output summary without needing to duplicate schema-provided return details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is only one parameter, config, and the schema provides no description, so the description must compensate for 0% schema coverage. It adds meaning by specifying what kind of content the config may contain and how it will be transformed, though it does not explicitly define the expected input format or encoding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Scrub a config before it goes anywhere' with detailed redaction categories. It clearly distinguishes this tool from network-focused siblings like check_config_compliance and explain_config_diff by defining a unique sanitization responsibility.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'before it goes anywhere' establishes the intended context: use this when a config must be shared or exported safely. It does not explicitly name alternatives or exclusions, but none of the listed siblings compete for the same purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0check_config_compliancecheck_tls_endpointdiagnose_dot1xexplain_config_diffexplain_firewall_changeextract_device_factsfind_certs_in_configinfer_topologylatest_field_notelookup_ise_failure_codepreflight_changesanitize_configMost tools have clearly distinct purposes—config parsing, certificate checks, compliance, diffs, diagnostics, and preflight risk—so an agent can usually select correctly. However, explain_config_diff and explain_firewall_change can both apply to OPNsense config changes, and check_tls_endpoint/find_certs_in_config share the same certificate-findings logic, creating a couple of genuine boundary cases.
The vast majority of tool names follow a predictable verb_noun snake_case pattern: check_, sanitize_, explain_, find_, extract_, infer_, diagnose_, lookup_, and preflight_. The only real outlier is latest_field_note, which is an adjective-noun phrase rather than a verb-led action, but the overall naming convention is consistent and readable.
Twelve tools is well within the ideal range for a network-operations analysis server, and each tool earns its place by covering a distinct operational task: facts, compliance, sanitization, diffs, certificates, dot1x, topology, firewall changes, and preflight assessment. The count feels neither thin nor bloated.
The tool surface covers the main config-analysis workflow—extract facts, check compliance, explain diffs, sanitize before sharing, and preflight risk—along with certificate and dot1x troubleshooting. Minor gaps exist, such as no direct single-config plain-English explainer and no search or archive access for older field notes, but agents can generally work around these.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Read-only AI coding tools for change verification, release readiness, capacity, and guidance.
Read-only MCP access to a documented IT fleet: state, changes, posture. 15 tools.
Scan configs, files, or text for leaked secrets and obvious misconfigurations. Nothing stored.
Read-only CVE intelligence, remediation playbooks, and agent setup guides. Not a scanner.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/labaccessnow/netops-field-notes-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
