mcp-reachability

Two observations of MCP registry reachability, plus a live health-check CLI. Zero runtime dependencies; Node.js 22+.

712 of 777 previously failing registry server rows failed again (91.63%). In the same second run, 4 of 300 randomly selected previously working controls failed (1.33%). The frozen threshold was at least 75% repeated failures; more than 15% control failures would void the run. This is evidence of repeated failure with this method, not proof of continuous downtime or global deadness.

npx mcp-reachability summary
npx mcp-reachability check https://tandem.ac/mcp
npx mcp-reachability lookup ac.tandem/docs-mcp
npx mcp-reachability dataset > reachability.jsonl

check performs MCP initialize, notifications/initialized, and paginated tools/list over HTTP POST, accepting JSON or SSE responses. It never invokes a tool. Requests have a 12-second timeout and the check has a 12-minute total cap. Exit codes: 0 for ok/auth_required/empty_tools, 1 for a classified failure, 2 for usage or local errors. Only check URLs you intend to contact; redirects are followed. This CLI is not a hosted URL-checking service.

dataset emits all 4,609 original registry server rows with probe1, probe2, and cohort. Probe 2 is null for 3,532 rows that were not re-probed; null does not mean dead. Each observation retains individual remote endpoint traces, response statuses, timestamps, and error messages. lookup matches an exact registry name or original remote URL. summary supplies counts, transitions, metadata, and caveats. These commands work offline except check.

JavaScript API:

import {check, dataset, summary, metadata} from 'mcp-reachability';
console.log(await check('https://tandem.ac/mcp'));
console.log(summary.persistent_failures); // 712

Probe 1: 2026-09-08T15:26:29.493Z–2026-09-08T15:38:29.541Z. Probe 2: 2026-09-09T03:42:23.820Z–2026-09-09T03:44:15.812Z, more than 12 hours after probe 1 completed. Both use the same protocol/classification logic, concurrency 25, request timeout 12 seconds, and 12-minute run cap. The random control selection and shuffled combined run order were frozen before execution; data/manifest.json records the seed, names, source hashes, and thresholds.

Coverage and limitations:

• 4,609 of 16,444 remote registry servers were attempted initially, in an ordered, time-capped traversal. The other 11,835 were not probed. The second run covers only the 777 prior failures and 300 controls. Do not extrapolate these rates to the full registry.
• Single workspace network vantage per run. Geographic location and egress IP were not recorded or verified; controls check degradation, not geographic equivalence. A server failing from here may be alive elsewhere.
• auth_required is alive, not dead. The 65 recoveries comprise 57 ok and 8 auth_required.
• Frozen failure outcomes: not_found, network_error, rpc_error, timeout, server_error. These include protocol incompatibility and tools/list errors, not just unreachable hosts. Legacy SSE-only and tools-free servers may be usable by other clients. empty_tools is not one of the frozen failures.
• Rows are registry servers, sometimes with multiple endpoints. The original aggregation chooses any ok endpoint, otherwise the first endpoint. An auth-required secondary endpoint does not override a failing first endpoint; inspect endpoint traces before drawing endpoint-level conclusions.
• Repeated network_error is not proof of dead DNS: the original prober captures only the top-level error. Two observations do not prove persistent failure throughout the intervening hours.

The package is free and has no payment mechanism. This result establishes repeated failures in the sampled population; it does not establish customer demand.