When people ask “where do I find MCP servers?”, a growing chunk of the answer starts in one place: the Official MCP Registry at registry.modelcontextprotocol.io.
I recently listed ThinkReview MCP there — our hosted server that runs AI code reviews on GitHub, GitLab, Azure DevOps, and Bitbucket PR/MR URLs from Cursor, Claude, and Copilot.
Here’s exactly what I did, and how you can do the same.
The Official MCP Registry stores metadata, not your binaries.
That means:
server.json
that describes your MCPThere are two common shapes:
ThinkReview is remote. Our endpoint is:
https://mcp.thinkreview.dev/v1
So I didn’t need to publish an npm package just to get listed. I only needed a solid public docs repo + a valid server.json
.
Docs that mattered:
The registry is still in preview. Expect possible breaking changes before GA.
Directories and developers want a repo they can open.
I created a public visibility/docs repo:
github.com/Thinkode/thinkreview-mcp
It includes:
It does not include our private review engine, auth, or billing backend. For a SaaS MCP, that’s the right split:
If you’re building an open-source local MCP, your full source can live in that same repo.
brew install mcp-publisher
mcp-publisher --help
Or grab a binary from the registry releases.
You’ll use three commands most of the time:
mcp-publisher init
mcp-publisher login ...
mcp-publisher publish
Your server name
is tied to how you authenticate.
| Auth method | Name format | Example |
|---|---|---|
| GitHub login | io.github.<user-or-org>/... |
|
io.github.Thinkode/thinkreview |
||
| Domain proof (DNS/HTTP) | reverse-DNS of your domain | branded names under your company domain |
I used the GitHub org namespace because it’s the fastest path:
io.github.Thinkode/thinkreview
Note: the registry name (thinkreview
) and the GitHub repo name (thinkreview-mcp
) do not have to match. Pick a clean registry name; point repository.url
at whatever public repo you use for docs or source.
Later, you can move to a branded domain namespace if you want cleaner naming — that needs DNS TXT or a /.well-known/mcp-registry-auth
proof on your domain.
server.json
for a remote MCP In the repo:
cd thinkreview-mcp
mcp-publisher init
Then edit the file for a hosted server. Skip packages
unless you also ship a local install. Use remotes
instead:
{
"$schema": "https://static.modelcontextprotocol.io/schemas/2025-12-11/server.schema.json",
"name": "io.github.Thinkode/thinkreview",
"title": "ThinkReview",
"description": "Live PR/MR code reviews via review_url_code. OAuth or portal Bearer auth.",
"version": "1.3.0",
"websiteUrl": "https://thinkreview.dev/features/mcp",
"repository": {
"url": "https://github.com/Thinkode/thinkreview-mcp",
"source": "github"
},
"remotes": [
{
"type": "streamable-http",
"url": "https://mcp.thinkreview.dev/v1"
}
]
}
A few rules that saved me time:
"type": "streamable-http"
(SSE is deprecated)version
is required, unique per publish, and immutable once published — use semvername
must match your auth namespace (io.github.Thinkode/...
if you logged in as that org)Commit server.json
so the listing is reproducible.
For the GitHub namespace path:
mcp-publisher login github
You’ll get a device code, authorize it in the browser, and the CLI confirms you’re logged in.
That login only lets you publish under io.github.<that-account-or-org>/...
.
mcp-publisher publish
When it works, you’ll see something like:
Publishing to https://registry.modelcontextprotocol.io...
✓ Successfully published
✓ Server io.github.Thinkode/thinkreview version 1.3.0
That’s it. Your MCP is now in the official upstream registry.
Search by a short token that matches your listing:
curl "https://registry.modelcontextprotocol.io/v0.1/servers?search=thinkreview"
Or use the exact registry name:
curl "https://registry.modelcontextprotocol.io/v0.1/servers?search=io.github.Thinkode/thinkreview"
You should see metadata like:
io.github.Thinkode/thinkreview
1.3.0
active
https://mcp.thinkreview.dev/v1
https://github.com/Thinkode/thinkreview-mcp
From there, community directories (PulseMCP, Glama, mcp.so, mcpservers.org, etc.) often pick listings up over time — but the official registry is the upstream source you want first.
Every meaningful MCP release:
version
in server.json
mcp-publisher publish
againOr automate it in GitHub Actions with mcp-publisher login github-oidc
on version tags so every release republishes metadata.
| Error | What it usually means |
|---|---|
| No permission to publish this server | Your name doesn’t match your GitHub/domain auth |
| Invalid or expired JWT | Re-run mcp-publisher login github |
| Registry validation failed | Package listings need ownership proof (mcpName , etc.). Remote listings need a live public URL |
| Version already exists | Bump semver — published versions can’t be overwritten |
| Search returns empty | You’re searching the wrong string (e.g. repo name vs registry name ) |
mcp-publisher
server.json
with remotes
pointing at your hosted URLmcp-publisher login github
mcp-publisher publish
That’s how ThinkReview MCP got onto the official MCP Registry — and the same path works whether you’re shipping a local open-source server or a hosted product like ours.
If you’re listing a remote MCP too, start with the GitHub namespace, get discoverable fast, then brand the namespace later once DNS/domain proof is worth the extra step.