Does my MCP server have to be publicly reachable?

Yes. The test is an ordinary HTTPS request from our server to yours, so the endpoint has to answer from the public internet. Private addresses, localhost and cloud metadata ranges are refused before any request leaves our network. A stdio server has no URL to test, and we do not run commands from strangers, so v1 cannot check one at all.

Is this the same check a submission runs?

Yes, the same code path. If your server passes here it passes the automated half of the MCP Hunter gate. A human reviews every submission after that, which is the part no test can do for you.

What if my server requires authentication?

This tester connects anonymously, so a server that guards tools/list answers with a 401 or 403 and we record it as authorization required. That is a working server, not a failed one. The submission flow at /submit takes an optional token instead, sends it as one Authorization header on a single check, and deletes it afterwards.

Do you keep the result?

Yes. Every check gets a permanent URL you can share, showing the date, the outcome and what the server returned. We do not re-test it later, so that page describes one moment and never updates. Results from this tester are kept separate from the sample behind any statistic we publish.

Free tool

Test an MCP server

Paste your Streamable HTTP endpoint. We run the handshake, call tools/list, and hand back a dated record of exactly what your server returned. No install, no signup, and you get a URL you can send someone.

What happens when you press the button

Three JSON-RPC calls, in the order the specification requires, over Streamable HTTP:

1 initialize, offering protocol version 2025-11-25. Your server replies with the version it will actually speak, its name and version, and its capabilities.
2 notifications/initialized, carrying the session id if your server issued one.
3 tools/list, following nextCursor until your server stops sending one. Stopping at the first page is the single easiest way to report a tool count that is quietly too low.

Then we stop. We never call a tool, never send arguments, and never write anything to your server. If you want the field-by-field detail of what step 3 returns, that is in the mcp tools/list reference.

What you get back

•The outcome, and the reason in plain language if it was not a clean connection.
•The protocol revision your server negotiated, which is often not the one it advertises in its docs.
•How many tools it exposed, and their names.
•Whether any of those tools carry a description. A model picks tools by reading descriptions, so tools without them are close to unusable.
•One tools/list round trip in milliseconds. Not the whole test: our DNS lookup, TLS handshake and the two preceding calls are our overhead, not your server's latency, and billing them to you would make the number a fact about us.

The seven outcomes

These are kept apart rather than collapsed into pass and fail, because only some of them mean something is broken, and telling you the wrong one is a claim about your software we did not check.

Outcome	What it means
Connected	Handshook and listed tools. This is the one that passes the gate.
Authorization required	Your server answered 401 or 403. It is running and speaking MCP, and it is guarding itself correctly. This is not a failure.
Not an MCP endpoint	The address served a web page. Usually the docs or landing page rather than the endpoint a client connects to.
Hostname did not resolve	DNS returned nothing for that host. Nothing was sent.
Unreachable	The connection never opened, or it opened and then timed out. Connection refused, a TLS failure, or a server that went quiet.
Protocol error	It answered, but not with valid MCP. Malformed JSON-RPC, an error result, or a tool list we could not parse.
Blocked before connecting	The address resolved to a private range, loopback, or a cloud metadata endpoint. We refuse those and nothing left our network.

A 401 is not a broken server, and most public MCP servers return one.

When we ran this tester across 53 public MCP endpoints on 5 August 2026, 30 of them refused an anonymous tools/list. That is 57%, and it is the correct behaviour for a server holding anyone's data. If you get this result, your server is fine. It just will not tell a stranger what it can do, which is a decision you made on purpose.

What this does not tell you

We connect to a server and record what it said. That is the entire claim, and it is worth being blunt about the edges of it:

•Nothing about safety. We have not read the server's code, audited its data handling, or looked at what its tools are permitted to do. A passing result is not a security review and we will never present it as one.
•Nothing about right now. A result is dated because it describes one moment. We do not re-test on a schedule, so a result from last Tuesday says what happened last Tuesday and nothing about today.
•Nothing about whether the tools work. We list them. We never call one, so a tool that is declared but broken looks identical to one that works.

Passed? Then you can launch it here.

MCP Hunter is a weekly launch board with one rule: your product has to ship an MCP server that we can connect to. If the check above came back connected, you already clear the automated half of the gate.

Submit your product

Questions

Does my MCP server have to be publicly reachable?: Yes. The test is an ordinary HTTPS request from our server to yours, so the endpoint has to answer from the public internet. Private addresses, localhost and cloud metadata ranges are refused before any request leaves our network. A stdio server has no URL to test, and we do not run commands from strangers, so v1 cannot check one at all.
Is this the same check a submission runs?: Yes, the same code path. If your server passes here it passes the automated half of the MCP Hunter gate. A human reviews every submission after that, which is the part no test can do for you.
What if my server requires authentication?: This tester connects anonymously, so a server that guards tools/list answers with a 401 or 403 and we record it as authorization required. That is a working server, not a failed one. The submission flow at /submit takes an optional token instead, sends it as one Authorization header on a single check, and deletes it afterwards.
Do you keep the result?: Yes. Every check gets a permanent URL you can share, showing the date, the outcome and what the server returned. We do not re-test it later, so that page describes one moment and never updates. Results from this tester are kept separate from the sample behind any statistic we publish.