Make Money Developing and Listing MCP Servers

The Official MCP Registry Is the Central Discovery Hub for MCP Servers

The Model Context Protocol (MCP) ecosystem is expanding at a breakneck pace, with developers building thousands of custom servers to extend the functionality of AI coding assistants like Cursor, Claude Desktop, and GitHub Copilot. But for all the innovation happening in the space, discoverability remains a key challenge for builders. That’s where the Official MCP Registry comes in: the central, curated directory where developers search for ready-to-use MCP integrations, and the first place your tool needs to be listed if you want to reach users. I recently listed our hosted AI code review MCP server, ThinkReview, on the registry, and the process was far simpler than I expected — no binary uploads, no complex approval workflows, just a few well-structured files and a public documentation repo. Below is exactly how it works, and how you can list your own MCP server in minutes.

How the Official MCP Registry Works

Unlike traditional app stores, the registry does not store your server binaries or proprietary code. Instead, it stores lightweight metadata that points clients and developers to your server, whether it’s a locally installed package or a hosted remote endpoint. There are two common server formats supported:

• Package-based servers: Your server is published to a package registry like npm, PyPI, NuGet, or Docker Hub, and the MCP registry points to that package for installation.
• Remote (hosted) servers: Your server runs as a public Streamable HTTP endpoint, and the registry points directly to that URL for clients to connect to.

Step 1: Build a Public Documentation Repo

• A clear description of the MCP’s core functionality and target use cases
• Our public endpoint URL and transport type (Streamable HTTP)
• Step-by-step authentication setup guides for Cursor, Claude Desktop, and Copilot, including OAuth and Bearer token configuration
• Ready-to-use configuration snippets that developers can copy and paste to connect the MCP to their clients
• Links to troubleshooting re

Step 2: Generate and Publish Your server.json Metadata

• mcp-publisher init: Generates a starter server.json file in your documentation repo
• mcp-publisher login: Authenticates you with the registry
• mcp-publisher publish: Pushes your finalized server.json to the official registry

Your server’s name in the registry is tied directly to your authentication method, with two common options:

• GitHub authentication: The fastest path for most developers, your server name follows the format io.github.[your-username-or-org]/[server-name]. For ThinkReview, we use io.github.Thinkode/thinkreview, tied to our GitHub organization account. No additional domain setup is required for this option. Note that server names are globally unique within your authentication namespace, so you’ll need to pick a name no other user has claimed under your GitHub org or custom domain.
• Custom domain authentication: If you want a branded name under your own domain (ideal for commercial products), your server name uses a reverse-DNS format tied to your domain, and you’ll prove domain ownership /.well-known/mcp-registry-auth file hosted on your domain.

Configuring server.json for Remote Hosted MCP Servers

For remote hosted servers like ThinkReview (which uses a public Streamable HTTP endpoint at https://mcp.thinkreview.dev/v1), you’ll edit the generated server.json to include your endpoint URL, transport type, authentication requirements, and links to your documentation, while skipping package-related fields unless you also ship a local install version of your MCP. The file uses a public JSON schema (current version 2025-12-11) that you can validate against to catch errors before publishing.

Step 3: Publish and Optimize Your Listing for Discovery

Once your server.json is finalized, navigate to your documentation repo in your terminal, run mcp-publisher login followed by your chosen auth method (e.g., mcp-publisher login github for GitHub auth), then run mcp-publisher publish to push your metadata to the registry. The registry is still in preview as of 2024, so expect minor breaking changes before general availability, but all current listings will be easy to update when GA launches.

To maximize your discoverability on the registry, make sure your server.json description is clear, keyword-rich, and explicitly states what your MCP does and which tools or services it integrates with. For example, if your MCP connects to a popular project management API, mention that API name directly in the description so developers searching for that integration can find you. Keep your linked documentation repo up to date with new features, client compatibility notes, and troubleshooting guides, as many developers will review your repo before deciding to adopt your MCP.

Use Cases for Listed MCP Servers Across the Ecosystem

• Open- If you’re building a free, locally run tool (like a local file system manager, code linter integration, or database query tool), publish your full
• Commercial SaaS MCPs: If you’re running a paid, hosted MCP (like ThinkReview’s AI code review tool, or an MCP that integrates with a paid analytics or CRM API), keep your core backend, authentication, and billing infrastructure private. Publish only public docs and configuration in your linked repo, and point the registry to your public Streamable HTTP endpoint. You can handle usage tracking, billing, and support
• Internal enterprise MCPs: If you’re building custom MCPs for internal company use, you can use the same naming conventions and server.json format to publish private listings, or host your own internal registry instance for your team to discover internal tools without exposing them to the public.

Get Started Listing Your MCP Today