Spec Driven Development
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
Runs on your computer
netdiag MCP
Overview
Description from the maker (original English)
MCP server wrapping dig, ping, mtr, whois and TLS/HTTP checks for on-demand network diagnostics
PopNx MCP’s three pillars
These three are never merged into one score: opinions, measurements and popularity are different things.
- User voiceiNo reviews yetReviews open together with accounts in a later step
- Our basic checksi1 of 1 passedChecked from public information; code not scanned yet
- UsageiVery new↓ 50/wk · ★ –
What you can do with it
We have not written a plain-language summary for this one yet. Below are the facts we read from the registry.
- Connection: Runs on your computer
- Transport: stdio
- Category: Other
Install
Pick the AI app you use, then copy the settings.
Before you install
- Basic checks: 1 of 1 passed
- Runs on your computer with your user’s permissions (files, network, apps).
- The registry lists no key to fill in.
You need
- PyPIPython’s uv installed (for the uvx command)
Which app do you use?
Pick your app above. We remember it, so next time the button says “Install in …”.
Open Claude Desktop → Settings → Developer → Edit Config, and paste this into claude_desktop_config.json
{
"mcpServers": {
"netdiag": {
"command": "uvx",
"args": [
"netdiag-mcp"
]
}
}
}Run this in your terminal
claude mcp add netdiag -- uvx netdiag-mcpOr copy the settings yourself
Paste into .cursor/mcp.json in your project, or ~/.cursor/mcp.json
{
"mcpServers": {
"netdiag": {
"command": "uvx",
"args": [
"netdiag-mcp"
]
}
}
}Your browser asks to open the app, then the app shows the settings and asks you to confirm. Key values are left empty for you to fill in.
Or copy the settings yourself
Paste into .vscode/mcp.json in your project
{
"servers": {
"netdiag": {
"type": "stdio",
"command": "uvx",
"args": [
"netdiag-mcp"
]
}
}
}Your browser asks to open the app, then the app shows the settings and asks you to confirm. Key values are left empty for you to fill in.
This one runs on your computer, and ChatGPT can only connect to servers on the internet. Pick another app.
Your choice stays on this device in a cookie; no account needed.
These settings are generated from the maker’s registry entry. If the README says otherwise, follow the README.
What it can do
Runs on your computer; the tool list appears in your AI app after you install it.
Basic checksi
We check information anyone can see; we have not read the code. Checks that do not apply are left out of the count. · Checked Nov 8, 2026
- ✓ Pass
Maker matches the repo
The registry name was verified with the GitHub account shigechika, which owns the repo
- … Not checked yet
Still maintained
We have not read this repo from GitHub yet
- … Not checked yet
Has a licence
We have not read this repo from GitHub yet
- – Not applicable
Endpoint responds
This one runs on your computer; there is no internet endpoint
- – Not applicable
Sign-in with OAuth
Runs on your computer and uses local settings instead
- … Not checked yet
No hidden instructions in tool descriptions
Runs on your computer; we can only read tool lists from internet endpoints
Compared with others in Otheri
- More stars than 0% of the other 18595 servers in this category
- Published to the registry more recently than 75% of the other 18595 servers in this category
- Basic checks equal to or better than 100% of the other 18595 servers in this category
Compared with every active server in this category in the registry. Stars count only when the publisher owns the repo.
Common questions
Is netdiag MCP safe?
It passed 1 of 1 applicable basic checks. We have not read the code. Before adding a key or token, see what access the server asks for and use a key with only the permissions you need.
What keys or codes does it need?
The registry does not list a required key, though some servers ask you to sign in on first use.
Does it run on my computer or in the cloud?
It runs on your computer. Your AI app starts it when needed, and data does not pass through the maker’s servers (unless it calls an online service itself).
Is it still maintained?
The GitHub repo last changed –, and the latest version (0.8.1) reached the registry 13 days ago.
Which apps can use it?
Apps that support MCP, such as Claude Desktop, Claude Code, Cursor and VS Code. You also need Python (uv) on your computer.
What can I use instead?
In the same category: Spec Driven Development, Remote Desktop Commander, Aiterm MCP
Alternatives
Servers in the same category from other makers, sorted by stars.
Reading a card:↓ Downloads per weeki★ GitHub starsiThree pillars: reviews · checks · usageiUpdated = latest version published to the registryi
Remote Desktop Commander
Remote Desktop Commander: use files, terminal and processes on your own computers from any AI app.
Runs in the cloud✓ desktopcommander.app
Aiterm MCP
Persistent terminals and one launcher for Claude, Codex, Grok, Cursor, and Antigravity harnesses.
Runs on your computer
README from the maker
Open the README
Copied from the maker’s repo as written. PopNx MCP has not reviewed or endorsed it. HTML, images and scripts are removed. Links lead off this site.
netdiag-mcp
English | 日本語
MCP server for on-demand network diagnostics — DNS lookups (with a DNSSEC AD-bit check), ping, an mtr-based path report, TCP port checks, HTTP status/redirect checks, TLS certificate inspection, and WHOIS, all from one server.
Built for triaging "can't reach X" / "is DNS propagated yet" reports without shelling into a jump host for each one-off dig/ping/curl.
Tools
| Tool | Purpose |
|---|---|
dns_lookup | Resolve a DNS record via dig (A/AAAA/MX/TXT/NS/CNAME/SOA/PTR/CAA), optionally against a specific resolver and over plain DNS/DoT/DoH |
dnssec_check | Query a known-validating resolver and report whether the AD bit is set (plain/DoT/DoH) — the only reliable way to confirm DNSSEC validation, since an RRSIG being present in a plain dig reply does not by itself prove anything validated it |
ping_host | ICMP ping (count clamped to 1-10) |
traceroute_path | Hop-by-hop path/loss report via mtr --report (fixed cycles, not a live/continuous run) |
tcp_port_check | Is a TCP port open — a plain socket connect, not a port scan |
http_check | HEAD/GET a URL and report status, redirect chain, and latency |
http_get | GET a URL and return the body. Textual types only (text/*, JSON, XML, JavaScript, YAML, +json/+xml), capped at 1 MiB. Refuses loopback, link-local and cloud-metadata destinations, including via redirect |
tls_cert_check | Fetch the certificate a host presents and report subject/issuer/validity/SANs |
whois_lookup | WHOIS lookup for a domain |
asn_lookup | ASN + country-code lookup for an IP, or org info for an AS number, via Team Cymru's whois service — no API key or GeoIP database needed |
current_time | Current date, time and weekday in an IANA timezone — the weekday is returned as data because deriving it from a date is arithmetic that fails silently. Also reports UTC and epoch, so it doubles as a clock check |
health_check | Version and which wrapped binaries (dig/ping/mtr/whois) are present on PATH |
All tools are read-only and single-target (no batch/sweep mode) — this is a convenience wrapper around checks an operator would run by hand, not a scanning tool. nmap-style multi-host/multi-port scanning is intentionally out of scope; deliberately probing many hosts or ports is a different, higher-blast-radius action that deserves its own tooling and approval flow.
tcp_port_check, http_check, http_get and tls_cert_check use Python's own socket/ssl/httpx stack rather than shelling out to nc/curl/openssl, so those four tools work even on a host with only the dig/ping/mtr/whois binaries installed (or none of them — health_check reports which are missing without failing the whole server).
dns_lookup/dnssec_check support DNS-over-TLS and DNS-over-HTTPS via transport="dot"/"doh" (dig's +tls/+https). This needs dig from BIND 9.18+ — an older dig rejects the flag outright rather than silently falling back to plain DNS, so a stale binary fails loudly instead of giving a false sense of having checked over an encrypted transport.
tls_cert_check/http_check against a bare IP address can fail TLS handshake with a "handshake failure" or similar error on SNI-hosted / CDN-fronted origins (e.g. behind Cloudflare) — TLS's SNI extension only carries hostnames, so an IP literal can't route to the right certificate on a shared edge. This is normal TLS behavior, not a tool bug; check by hostname when the target is CDN-fronted.
Setup
1. System dependencies
dns_lookup, dnssec_check, ping_host, traceroute_path and whois_lookup shell out to dig, ping, mtr and whois respectively. Install whichever of these you want available:
# Debian/Ubuntusudo apt install dnsutils iputils-ping mtr-tiny whois
mtr needs raw-socket access. Debian/Ubuntu's mtr-tiny package grants cap_net_raw to the mtr-packet helper at install time, so it normally works for an unprivileged service user without further setup — verify with getcap "$(command -v mtr-packet)" if traceroute_path reports a socket permission error. Without that capability, traceroute_path fails cleanly with a ToolError rather than crashing the server.
2. Install
pip install netdiag-mcpor
uv tool install netdiag-mcp
3. Claude Code (plugin)
This repository doubles as a single-plugin marketplace, so Claude Code can install the server for you:
/plugin marketplace add shigechika/netdiag-mcp/plugin install netdiag-mcp@netdiag-mcp
The plugin launches uvx netdiag-mcp. No environment variables are required — the only prerequisite is the system dependencies above, and the TCP, HTTP and TLS checks work even without them.
uvx must be on the PATH of the process that runs Claude Code — a login shell usually has it, but a GUI-launched app may not; install uv system-wide if the plugin fails to start.
4. Claude Code (manual)
claude mcp add netdiag -- netdiag-mcpNo environment variables are required.
5. Codex
codex mcp add netdiag -- netdiag-mcpAny other MCP client that launches stdio servers works the same way: give it netdiag-mcp as the command.
Optional: credentials for http_get
http_get can send an Authorization header to URLs under a configured https prefix, for reading a protected JSON endpoint without handing the credential to the model. Set NETDIAG_HTTP_AUTH to a JSON object mapping prefix to header value:
NETDIAG_HTTP_AUTH='{"https://reports.example.ac.jp/daily/": "Bearer <token>"}'- The header is chosen per request and per redirect hop by comparing the parsed URL (https only, exact host and port, path prefix on a
/boundary). A redirect to anywhere else drops it, along with any cookie set while it was attached.user@hostURLs never match, and neither does a path with anything beyond letters, digits,.,_,~,-and/(no%,;or./..segments), so a server cannot normalise a matched URL out of the prefix. The longest matching prefix wins; two prefixes that differ only in case,:443or a trailing dot are rejected as duplicates. Values must be printable ASCII. - netdiag-mcp never puts the value into its own output, errors or
health_check; the result's status line saysauth=appliedwhen the final hop carried it, andhealth_checklists the configured prefixes in canonical form (not the values). Errors name a bad prefix by position, not by text. A response body under the prefix has the value (and its token part) masked as[redacted], but an endpoint that transforms it (for example base64) would still reveal it, so point a prefix only at endpoints you control. - A malformed value fails loudly:
http_getreturns an error andhealth_checkreportsdegraded. - It is read from the environment only. If several instances run as the same user (for example one open to many users and one restricted), set it only in the environment of the instance that should send it — a file would be shared by all of them.
CLI
netdiag-mcp --version # print versionnetdiag-mcp --check # report missing binaries and a malformed NETDIAG_HTTP_AUTH (exit 0 when all binaries are present and the setting, if any, parses)
Security notes
- Every external-binary call passes an argv list (never a shell string), so no tool argument can break out into shell syntax.
- Hostname/IP and port arguments are validated and size/range-clamped before use — tool input is model-driven and treated as untrusted, the same as any other tool-calling surface.
tcp_port_checkconnects to exactly one host:port per call; there is no loop or range argument, by design.- The optional
http_getcredential never leaves the configured https prefix and netdiag-mcp never prints it; a response body that echoes it is the server's doing (see above).
Development
Live smoke test
Unit tests check logic against fixtures; they cannot tell you that a tool has stopped returning real data (a dead dig/ping/mtr/whois binary, a broken TLS trust store, a network that blocks outbound ICMP). scripts/ smoke_test.py runs every registered tool against real public endpoints and fails on empty, malformed or error answers:
uv run python scripts/smoke_test.pyuv run python scripts/smoke_test.py --only ping --traceback
- No inventory, so every target is a fixed public endpoint — Cloudflare's
1.1.1.1and IANA'sexample.com(reserved for documentation/testing use, RFC 2606). This server takes no config and has nothing to discover a target from, unlike a device-fleet MCP server in this family. tests/test_smoke_probes.pyis the offline half: it only checks that every registered tool has a probe spec (and vice versa), so CI catches a tool added without deciding how anyone would know it works, without needing network access.
License
MIT