Network management utility MCP server that provides tools for network scanning, testing, packet capture, and performance measurement on remote probes
This MCP server exposes 9 network diagnostic tools with significant quality gaps. Tool names are abbreviated and non-standard (trcrt, trcrt_dns, scan_vuln, scan_srvc, scan_snmp, scan_custom, scan_map, test_srvr, test_clnt), most violate verb_noun naming convention and lack clarity. Descriptions are present but generic/boilerplate, mostly copied from underlying utilities (iperf3, traceroute, nmap documentation) rather than optimized for LLM decision-making. Input parameter schemas are visible and typed (strings, integers), but lack enums for constrained options, no ranges on numeric params, and no documented defaults or dependencies. Output schemas are completely undocumented, callers have no idea what data structures these tools return. Error handling and recovery guidance are absent. No tool annotations (readOnlyHint, destructiveHint). No secret injection pattern despite tools accepting user-provided options that could include credentials. Risk annotations claim all tools are READ_ONLY but several (scan_vuln, scan_snmp, scan_custom, scan_map) perform active network probing that could impact production systems, Risk designation is misleading.
Custom scan runs an nmap scan with the specified commandline options on all devices within a subnet or on the specified network host target.
Full scan runs a full network device discovery an a specified subnet. Enable OS detection, version detection, script scanning, and traceroute.
SNMP scan identifies SNMP capable network devices, runs specified nmap SNMP scripts to perform SNMPv3 GET requests and SNMP polling and retireves all available SNMP data for the specified target.
Identifies all running services on the specified target by performing a nmap service/version detection scan (-sV).
scan_vuln runs a vulnerability scan against the specified target. will return list of CVEs with a CVSS score of 5 or higher by default. The scan uses the nmap vulners script which leverages the vulners.com vulnerability database to perform vulnerability detection based on the software and services running on the target host(s).
Tool names violate verb_noun convention. 'trcrt', 'trcrt_dns', 'scan_vuln', 'scan_srvc', 'scan_snmp', 'test_srvr', 'test_clnt' are abbreviated and not self-documenting. LLMs cannot infer intent from these names alone.
No output schemas documented for any tool. Callers have no specification of what data structures are returned, making it impossible for LLMs to plan downstream tool chaining or extract required fields.
'options' parameter on test_srvr, test_clnt, trcrt, scan_custom accepts arbitrary command-line flags as free-form strings without validation. This invites command injection via prompt injection attacks. Should either enumerate allowed flags or sanitize/reject shell metacharacters.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 39 | - | v1 |
Starts the client-side of the speedtest to assist with active measurements of the maximum achievable bandwidth from client to the specified server.
Runs speedtest server which performs active measurements of the maximum achievable bandwidth on the specified IP network (host). Supports tuning of various parameters related to timing, buffers and protocols (TCP, UDP, SCTP with IPv4 and IPv6) via the command line flag options provided by the user. For each test it reports the bandwidth, loss, and other parameters.
traceroute tracks the route packets taken from an IP network on their way to a given host. It utilizes the IP protocol's time to live (TTL) field and attempts to elicit an ICMP TIME_EXCEEDED response from each gateway along the path to the host.
dnstraceroute is a traceroute utility to figure out the path that a DNS request is passing through to get to its destination. Comparing it to a network traceroute can help identify if DNS traffic is routed via any unwanted path.
scan_snmp exposes 'community' parameter as a tool parameter. SNMP community strings are credentials and must use server-side secret injection (environment variables or vault), not be passed as user inputs. Credentials in tool parameters end up in agent traces and logs.
Risk annotations claim all tools are READ_ONLY, but scan_vuln, scan_snmp, scan_custom, and scan_map perform active network probing (port scans, vulnerability scans, OS detection) that can disrupt production systems, trigger IDS/IPS alerts, or impact network performance. READ_ONLY is misleading, should use destructiveHint or custom annotations documenting network impact.
Parameter descriptions often copy tool documentation verbatim (e.g., traceroute man page for trcrt). Descriptions are not optimized for LLM decision-making, they lack WHEN to use, dependencies, expected duration, or relationship to sibling tools (when to use scan_map vs scan_custom vs scan_srvc?).
No input validation or constraints on parameters. 'target' parameter accepts any string (no IP/CIDR format validation). 'syn_ports' and 'ack_ports' are strings, not integer arrays, no schema validation. 'min_score' has type integer but no min/max bounds documented.
No error handling or recovery guidance. Tools can fail for many reasons (target unreachable, nmap not installed, permission denied, timeout) but no guidance on what to do next or how to self-correct.
No tool annotations present. Tools lack readOnlyHint (appropriate for discovery tools), destructiveHint (for active scans), or idempotentHint (for safe retries). Agents cannot distinguish safe-to-retry tools from stateful operations.