The homepage check leaves no trace in the directory
The box on our homepage takes an MCP endpoint URL and runs the probe against it while you wait. It is the fastest way to see what we do. It is also the part of the product with the strictest list of things it must not do, and this post is that list.
What happens when you press the button
The probe runs the same read-only sequence it runs on a scheduled check: the handshake, tools/list, and the protocol-level observations. You get a result page at a private link. That page shows the raw observations, and it expires; the exact expiry time is printed on the page itself rather than promised in prose here.
That is the whole feature. The rest of this post is about the negative space around it.
What it must not do
It never creates a directory page. A trial does not add the endpoint to the public directory, does not create a target record, and does not write a run into the history any directory page is built from. If you check a server that we already list, your trial does not touch that server’s page either. Directory pages are built only from scheduled runs, and new servers enter only through our own discovery or a maintainer’s claim.
It is never signed. Signed attestations belong to the scheduled runs a directory page is built from. A trial is a one-off observation outside any page’s history, so signing it would attach our key to an observation no page stands behind. The result page says “unsigned” and means it.
It respects opt-out completely. If the endpoint’s host has opted out by emailing us, a trial against it makes zero outbound requests to that host and writes nothing. You get the same “no result to show” page as any refused check, and that is all that happens. (robots.txt is read only when we discover servers on our own; a check a visitor asks for is not subject to it.)
It does not carry credentials. Same as every probe. There is no field for an API key because the probe would have nowhere to put one.
What it does record
Honesty requires the other half. The result page carries a sentence saying that the check is recorded as a tracking request, and that recording it does not guarantee the server will ever be listed. Concretely: we keep the request, the endpoint you asked about, and the result, in tables that are separate from the directory and purged on a schedule by the database itself. Nothing in that table can become a directory page without a human decision.
Why keep it at all? Two reasons. Rate limiting, so one person can’t turn the homepage into a free probing service against a stranger’s server. And demand: if many people ask about the same endpoint, that is a signal about which servers a directory ought to cover. It is a signal we read, not an automatic promotion.
Why the wall between trial and directory is load-bearing
A directory that anyone could populate by pasting URLs would fill with typos, staging servers, and endpoints their operators never intended to expose. Worse, it would let a trial result, which is a single unsigned observation at one moment, masquerade as a page with history and a maintainer behind it.
So the wall is structural, not a policy: the trial path has no code that writes to the directory tables, and our tests assert that stays true. Beyond the short hand-picked list we started with, entry into the directory happens by two routes, both of which involve someone taking responsibility: our own bounded discovery from public registries, with robots.txt honoured before the first request, or a maintainer claiming an address they can prove they control.
If you tried the homepage and want the page to exist for real, claim it. That is usually what the link at the bottom of your result page is for.