How do you read an MCP endpoint check result?

What the check actually does, in order

AdminKit’s MCP endpoint check sends a real initialize request — the first call any MCP client makes — to the URL you enter, with no credentials attached. What happens next depends entirely on how the server responds:

1. If initialize fails or returns an authentication error, the check reports that the endpoint requires auth and stops there — it never attempts to guess or brute-force credentials.
2. If initialize succeeds with no credentials, the check continues to tools/list, which asks the server to describe every tool it exposes: names and descriptions.
3. The check never sends tools/call. It reads what a tool is named and what it claims to do, but never invokes one, so it cannot trigger a file write, a database query, or a shell command on the server it’s checking.

A result is therefore one of three shapes: authenticated (initialize rejected the unauthenticated attempt), open (initialize succeeded, and tools/list shows what’s exposed), or not an MCP server (the endpoint didn’t behave like one at all — wrong status code, connection refused, or a response that doesn’t match the expected handshake).

Reading an “open” result: why tool names matter

If your result shows the server accepted initialize with no credentials, the next thing to read is the tool list tools/list returned. The Model Context Protocol specification describes tools as the mechanism by which a server lets an agent take real action — reading files, querying data, calling an internal API — so a tool list visible to anyone, authenticated or not, is effectively a map of what an unauthenticated caller could ask the server to do if it also allowed tools/call. A name like read_file, run_query or execute_command is a stronger signal to act on urgently than something read-only and narrowly scoped like get_status. The check doesn’t grade severity for you — it hands back the names and descriptions, and reading them in context of what the server is meant to do is what turns “open” into an informed next step.

Reading the SSRF guard

A result that comes back refused, rather than open or authenticated, can mean the target resolved to a private, loopback, or otherwise internal address. AdminKit’s Check API refuses to probe such targets at all — this is a safety control on the check itself, not a finding about the server you’re testing. It exists specifically so the check can’t be repurposed to reach into a network it shouldn’t be able to see, the same reasoning behind server-side request forgery (SSRF) defenses generally: a service that fetches a URL on a caller’s behalf has to validate where that URL actually points, not just that it’s syntactically a URL.

What “authenticated” doesn’t confirm

A result showing initialize rejected without credentials is good news, but it only confirms that one call enforces authentication — not that the server’s broader authorization setup is sound. The MCP Authorization specification defines a full OAuth 2.1-based flow with requirements beyond a single rejected call: token audience validation (so a token issued for a different service can’t be replayed here), scope enforcement per tool, and correct metadata discovery. This check is a single external probe of the front door, not a substitute for reviewing that the rest of the authorization flow is implemented to spec.

What to do next, depending on the result

• Open, and not meant to be public — restrict network access or add authentication before anything else; this is the most urgent state, since any agent or script that finds the URL can currently read your tool list.
• Open, and intentionally public — confirm none of the exposed tools can take a consequential action without further confirmation, since an unauthenticated caller can see exactly what’s available.
• Authenticated — a good baseline; see how to secure an MCP server for the fuller checklist beyond authentication alone, including tool allowlists and treating tool responses as untrusted input.
• Not an MCP server / unreachable — confirm the URL and that the service is actually running before assuming anything about its security posture.

Exposure can change without anyone touching the server’s code — a redeploy, a network change, or a forgotten debug build can reopen a gap you already closed. Re-running this check periodically catches that; scan an MCP endpoint in CI covers running the same probe automatically on every push instead of relying on remembering to re-check by hand.

Next step: check your own endpoint

Run AdminKit’s MCP endpoint check against a server you own or are authorized to test. Only test a server you control — reachability probing against one you don’t can violate its own terms of use even though this specific check never calls a tool.