MCP endpoint checker
Point it at a remote MCP server. It walks the discovery chain the way an AI client does and names the step that failed.
This runs from your browser, so it is subject to
CORS. A server that does not send Access-Control-Allow-Origin
will block the request and appear unreachable even when it is healthy. That is
itself useful information — some clients need those headers too —
but do not read a CORS failure as proof the server is broken.
What it checks, and why each step matters
1. The unauthenticated challenge
An unauthenticated request must return 401 with a
WWW-Authenticate header carrying resource_metadata.
Without that header a client has no way to discover where to authenticate and
fails with an opaque connection error. This is the single most common reason a
connector silently refuses to work.
2. Protected resource metadata (RFC 9728)
The resource field must equal the server's canonical URI
exactly. Clients compare it literally, so a trailing slash or an
http against https is a hard failure with an unhelpful
message.
3. Authorization server metadata (RFC 8414)
Must advertise authorization, token and registration endpoints, and must list
S256 in code_challenge_methods_supported. OAuth 2.1
requires PKCE and forbids the plain method; a server offering
plain is not spec-compliant and some clients will refuse it.
4. Transport
New connectors are expected to speak Streamable HTTP. The older standalone HTTP+SSE transport is deprecated and no longer accepted for directory submissions.
Why we built this
Varven is itself a remote MCP server, and getting the OAuth handshake right took longer than the retrieval engine did. The failure mode is brutal: the client reports only that it could not connect, with no indication which of seven steps went wrong. This walks them in order and names the one that broke.
Common questions
My server works in Claude but fails here.
Almost certainly CORS. Browsers enforce it; native clients do not.
Do I need dynamic client registration?
If you want clients to connect without you pre-registering each one, yes. Without it every client needs credentials issued by hand.
Which spec revision should I target?
Build to the current authorization spec and expect churn — it has revised several times, and the SSE to Streamable HTTP migration is recent enough that some clients still lag.