mcp-liveness
Does an MCP server work for a stock client? By registry name or URL. Tool drift too. Free, no key.
- 0.3.0
- Version
- remote
- Transport
- 5
- Tools
Security review
Review passedReviewed 1d ago.
- tools: 5 tools scanned
- metadata: scanned
No findings.
Tools (5)
mcp_liveness_check
Makes one handshake with an MCP server's endpoint — `server/discover` at protocol revision 2026-07-28, then `initialize` for a server on the older revision — with no credential, and reports what a stock client gets. The server is named either by its exact official-registry `name`, or by its endpoint `url` when it is not in the registry or is listed under another name; exactly one of the two is accepted. Outcomes: `usable` (it connected and negotiated a protocol version), `needs_credential` (401 or 403 — by name, the answer also says whether a credential can be obtained in-band or whether a person has to create one), `charged` (402, access is for sale), `unreachable` (not an MCP server there: wrong URL, dead host, or a 200 that is not JSON-RPC), and, for a name only, `local_only` (no remote endpoint; it must be spawned as a process) and `not_listed` (no server with that exact name; its endpoint can still be checked by `url`). A `url` must be public https: private, loopback, link-local
mcp_liveness_explain_outcomes
Returns the six outcomes this server can report — usable, needs_credential, charged, unreachable, local_only and not_listed — what each means for an agent choosing a server from the registry, and the usual next move for each. A static reference: it makes no network request and its answer never changes between calls.
mcp_liveness_drift
Given a server's exact name in the official MCP registry, reports which of its tools were added, removed, or had their description, input schema or output schema change between a named month and the latest monthly snapshot. Useful when a server that worked before behaves differently now, when a prompt or an integration written against its tools has started failing, or before relying on a cached tool description. A liveness check says a server answers today; this says whether it is still the same server that code was written against. The answer names the changed tools and the kind of change. It does not diff the schemas themselves: the snapshots keep content hashes, not bodies, so `detail` hands back the release-asset location of both full months for a caller that needs the exact diff. A month with no snapshot for that server gets an error naming the months that do have one, never an empty diff that would read as `nothing changed`.
mcp_liveness_check_auth
Walks a remote MCP server's OAuth sign-in chain from outside, with no credential and no client registration, and returns the first step that breaks, whose it is (`server`, `identity_provider`, or `client` for a known client bug, with its issue URL), the fix, and the spec section that requires it. Steps, in order: one unauthenticated request (it must answer 401 with a WWW-Authenticate challenge); RFC 9728 protected-resource metadata; RFC 8414 or OpenID Connect discovery at the locations the 2026-07-28 MCP spec lists, with the issuer and PKCE S256 checked; and how a client gets a client ID (client ID metadata documents, dynamic registration, or a pasted ID). Then a verdict per client — claude.ai, Claude Code, ChatGPT, VS Code, Cursor — emulated from each client's published requirements and known issues; no client is run. Use it when a user says a connector shows an error such as 'Authorization with the MCP server failed' or 'Dynamic Client Registration not supported', or before publish
mcp_liveness_check_apps
Checks a remote MCP server's MCP Apps UI (SEP-1865 `ui://` resources) from outside, with no credential and without calling any tool, and returns the first step that stops the view rendering, whose it is (`server`, or `host` for a known host bug with its issue URL), the fix, and the source (the spec, or the host's published page, with the date read). It opens the server as an MCP Apps host would, then reads tools/list, resources/list and resources/read: each tool's link to its view (_meta.ui.resourceUri, or ChatGPT's openai/outputTemplate alias), the view's MIME type (text/html;profile=mcp-app) and HTML, what the HTML loads against the CSP a host builds from _meta.ui.csp, whether it sends ui/initialize, ui.domain for Claude and for ChatGPT, and what OpenAI's directory review checks (explicit tool annotations, descriptions, a public https endpoint, the domain-verification file). Verdicts per host — `spec`, `claude`, `chatgpt`, `chatgpt-directory` — are judged from each host's published