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

> Source: <https://dev.to/jay_elsheikh_59b14ad67922/how-i-listed-my-mcp-on-the-official-mcp-registery-and-how-you-can-do-yours-too--1lp>
> Published: 2026-08-10 11:25:49+00:00

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.