netdiag-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| health_checkA | Service health: version and which wrapped binaries are present on PATH. Returns a fixed shape (status/service/version + backend fields) so a monitoring caller never has to branch on missing keys. status is "healthy" when every wrapped binary is found, "degraded" when at least one is missing (the corresponding tools will fail at call time). |
| dns_lookupA | Resolve a DNS record via Pass resolver to query a specific nameserver instead of the host default (e.g. to check whether a change has propagated to a given resolver). transport: "plain" (UDP/TCP 53, default), "dot" (DNS-over-TLS, 853) or "doh" (DNS-over-HTTPS, 443). Requires dig from BIND 9.18+; an older dig rejects dot/doh outright instead of silently querying over plain DNS. |
| dnssec_checkA | Check whether a name validates DNSSEC against a known-validating resolver (AD bit). transport: "plain" (default), "dot" or "doh" — compare validation over plain DNS vs. an encrypted transport when port 53 may be intercepted. |
| ping_hostB | ICMP ping a host or IP. count is clamped to 1-10. |
| traceroute_pathB | Path/MTU-style hop report via |
| tcp_port_checkA | Check whether a TCP port is open (plain socket connect, no port scanning). |
| http_checkB | HEAD/GET a URL and report status, redirect chain and latency. |
| http_getA | GET a URL and return the response body (text/JSON/XML only, capped at max_bytes, hard cap 1 MiB). Use this to read a JSON endpoint or inspect an error page. For status/latency only, use http_check instead. |
| tls_cert_checkA | Fetch the TLS certificate presented on host:port and report subject/issuer/validity/SANs. |
| whois_lookupC | WHOIS lookup for a domain. |
| asn_lookupA | ASN + country-code lookup for an IP, or org info for an AS number (e.g. AS15169 or 15169). Via Team Cymru's whois service — no API key or GeoIP database needed. Takes an IP literal or AS number, not a hostname; resolve first with dns_lookup if you only have a name. |
| current_timeA | Current date, time and weekday in an IANA timezone (e.g. "Asia/Tokyo"). Call this rather than deriving the weekday from a date yourself — that is calendar arithmetic and it fails silently. Returns the date, the 24h time, the weekday in English and Japanese, the offset, UTC and the epoch, so it also serves as a clock check on this server. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 12 tools
Each tool targets a distinct network diagnostic action or resource: DNS resolution, DNSSEC validation, WHOIS, ASN, ping, TCP port, TLS certificate, traceroute, HTTP body retrieval, HTTP status/latency, service health, and time. The descriptions explicitly clarify potential overlaps, such as http_get vs http_check and dns_lookup vs dnssec_check. No two tools appear to do the same thing.
All tool names use snake_case and are readable, with most following a subject_action pattern like dns_lookup, tcp_port_check, or tls_cert_check. Minor inconsistency exists because ping_host and traceroute_path use verb_noun ordering, and current_time is not action-oriented. Still, the convention is predictable overall.
The server has 12 tools, which is well within the ideal 3–15 range and appropriate for a network diagnostic toolkit. Each tool covers a distinct protocol or diagnostic layer, and none feels redundant or excessive.
The surface covers core network diagnostics comprehensively: DNS record resolution and DNSSEC, WHOIS/ASN, ICMP ping, TCP port checks, traceroute/MTU, TLS certificate inspection, HTTP checks, and service health. No obvious lifecycle or operational gaps exist for a read-only diagnostic server.