How I listed my MCP on the official MCP Registery and how you can do yours too ?

Thinkode has listed its ThinkReview MCP server on the official MCP Registry at registry.modelcontextprotocol.io, using the mcp-publisher CLI. The hosted server, which runs AI code reviews on GitHub, GitLab, Azure DevOps, and Bitbucket PR/MR URLs from Cursor, Claude, and Copilot, is published under the GitHub org namespace io.github.Thinkode/thinkreview. The process involves creating a public docs repo, initializing a server.json with remote endpoint metadata, and publishing via the CLI.

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 https://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 https://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 https://github.com/modelcontextprotocol/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 semver name 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 URL mcp-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.