What a listing is
A listing is a public page for your remote MCP endpoint — probed every six hours, with an uptime record, an auth matrix, and a contract changelog where every change is classified breaking, compatible, or cosmetic. Listing is free, there is no review queue, and the page goes live with a real probe verdict the moment your proof checks out.
Your server may already be listed: the directory ingests remote endpoints from the official MCP registry automatically. Search for it on the front page first — if it is there, claim it instead of publishing a duplicate.
Publish
Scan or fill the form
On the front page, either paste your domain into the scan — it finds the endpoint and pre-fills the form — or fill the publish card directly: name, endpoint URL, an optional one-line description and homepage.
Prove control
You get a verification value shaped mcpi-verify=<token>. Publish it in
either place:
- DNS — a TXT record at
_mcpi.<host>(the bare host also works, for DNS interfaces that fight underscores). - HTTP — the same value as a line in the body of
https://<host>/.well-known/mcpi-verify. Redirects are not followed: a redirect proves control of its target, not of your origin. This is the route for platform subdomains whose DNS you cannot touch.
Verify
Press verify. The listing goes live immediately, is probed on arrival, and arrives pre-claimed — you are its verified owner from the first second, with the owner controls unlocked.
WebMCP pages
The directory also lists web pages that register WebMCP tools for the agent driving the browser. Those tools live in the browser, so no probe of ours can see them — the listing's contract comes from you.
Switch the publish card to WebMCP page, name the page, enter its URL, and
paste the tools it registers. On the page, in the browser console (Chrome 149+
with chrome://flags/#enable-webmcp-testing, or any browser where the page
loads the WebMCP polyfill), run:
copy(JSON.stringify((await document.modelContext.getTools()).map(t =>
({ name: t.name, description: t.description, inputSchema: t.inputSchema, annotations: t.annotations }))))Proving control works as for a server, against the page's host — plus one
option a page has and a server does not: put
<meta name="mcpi-verify" content="mcpi-verify=<token>"> in the page's own
<head>. That is the route when you can edit the page but not the host's
DNS or its root. The paste becomes the listing's first contract entry, marked
owner-reported;
when the page's tools change, paste again from the owner card on the listing
and the difference is classified like any other contract change. The
six-hourly prober leaves these listings alone, and the page says on every
surface that its tools were reported by their owner, not observed by us.
What happens after
The six-hourly prober takes over: every check lands in the listing's uptime record, and every contract change lands in its public changelog and Atom feed. If your server requires authentication, the probe can verify the handshake but cannot record your contract — owner snapshots fill that gap from your own CI.