How to Publish a Remote MCP Server to the MCP Registry Under Your Company Domain

To publish a remote MCP server to the official MCP Registry under your company name, you prove you own your domain with a DNS TXT record or a /.well-known/mcp-registry-auth file, write a server.json with a remotes entry, then run mcp-publisher login dns (or login http) and mcp-publisher publish. Your server then appears as com.yourcompany/your-server in the registry's public API.

This guide is the company version of the process. Our Lesson 28: Publish to the MCP Registry covers the beginner path with an npm package and a GitHub login. Here we focus on a hosted server, a domain namespace and automated releases.

Commands and fields below match the MCP Registry docs and the 2025-12-11 server.json schema, checked on 6 November 2026. The latest mcp-publisher release on GitHub that day was v1.8.8, published 6 November 2026. The registry is still in preview, and its docs warn that "Breaking changes or data resets may occur before general availability."

Before you start

You need four things:

• A public remote server. The remote servers guide says it "MUST be publicly accessible at its specified URL." The registry's About page says it "does not support private servers."
• Control of your domain's DNS, or the ability to host a file at https://yourdomain/.well-known/mcp-registry-auth.
• OpenSSL, to make a key pair. The docs also show Google Cloud KMS and Azure Key Vault options.
• mcp-publisher, installed with brew install mcp-publisher or the prebuilt binary from the quickstart.

If you're not sure the registry is worth it, read what the MCP Registry is first. It explains how directories pull from it.

Step 1: Choose your namespace

The namespace is the part of the name before the slash. The authentication guide says your login method decides which namespaces you can use.

For a company, the domain name is the stronger signal. A user who sees com.acme/crm can tell it came from the owner of acme.com. Pick DNS if you can edit DNS records. Pick HTTP if a web team can publish a static file faster.

The official registry's server.json requirements, in the registry's GitHub repository, put it simply: to publish to com.example/server, "the publisher must prove they own the example.com domain."

Step 2: Generate a key and publish the proof

These commands come from the authentication guide. Replace example.com with your domain.

DNS method (Ed25519)

MY_DOMAIN="example.com"

# Generate public/private key pair using Ed25519
openssl genpkey -algorithm Ed25519 -out key.pem

# Generate TXT record
PUBLIC_KEY="$(openssl pkey -in key.pem -pubout -outform DER | tail -c 32 | base64)"
echo "${MY_DOMAIN}. IN TXT \"v=MCPv1; k=ed25519; p=${PUBLIC_KEY}\""

Add the printed TXT record at your DNS provider. The docs say propagation "may take several minutes."

HTTP method (Ed25519)

openssl genpkey -algorithm Ed25519 -out key.pem
PUBLIC_KEY="$(openssl pkey -in key.pem -pubout -outform DER | tail -c 32 | base64)"
echo "v=MCPv1; k=ed25519; p=${PUBLIC_KEY}" > mcp-registry-auth

Host the mcp-registry-auth file at /.well-known/mcp-registry-auth on your domain.

Treat key.pem like any production secret. Anyone with it can publish under your namespace. Store it in your secrets manager, not in the repository.

Step 3: Write a remote server.json

You can run mcp-publisher init to generate a template, then edit it. For a hosted server, the remote servers guide shows this shape:

{
  "$schema": "https://static.modelcontextprotocol.io/schemas/2025-12-11/server.schema.json",
  "name": "com.example/acme-analytics",
  "title": "ACME Analytics",
  "description": "Real-time business intelligence and reporting platform",
  "version": "2.0.0",
  "remotes": [
    {
      "type": "streamable-http",
      "url": "https://analytics.example.com/mcp"
    }
  ]
}

Field rules from the 2025-12-11 schema:

The guide says to prefer Streamable HTTP. SSE is deprecated, so publish an "sse" remote "only to support existing clients."

Optional remote settings

• Headers. If clients must send an API key, add a headers array with name, description, isRequired and isSecret. Never put a real key in the file.
• Per-tenant URLs. Use {curly_braces} variables, such as https://{tenant_id}.analytics.example.com/mcp, with a variables object. Variables support default, choices and isSecret.
• A package too. remotes can sit alongside packages if you also ship a local version. Then the package needs its own ownership marker, as Lesson 28 explains.
• Custom metadata. Only data under _meta key io.modelcontextprotocol.registry/publisher-provided is kept, and it is limited to 4 KB. Other _meta keys "are silently dropped."

Check the file with our server.json validator before you publish. The description is the part people read most, and the moderation policy treats "a description stuffed with marketing copy" as spam.

Step 4: Log in with your domain

After the TXT record propagates, or the file is live, log in. From the authentication guide:

MY_DOMAIN="example.com"
PRIVATE_KEY="$(openssl pkey -in key.pem -noout -text | grep -A3 "priv:" | tail -n +2 | tr -d ' :\n')"
mcp-publisher login dns --domain "${MY_DOMAIN}" --private-key "${PRIVATE_KEY}"

For the HTTP method, the command is the same with login http in place of login dns.

If you see "You do not have permission to publish this server," the quickstart says your login method doesn't match your name's namespace. If you see "Invalid or expired Registry JWT token," log in again.

Step 5: Publish and verify

mcp-publisher publish

Then search the public API. The quickstart uses this pattern:

curl "https://registry.modelcontextprotocol.io/v0.1/servers?search=com.example/acme-analytics"

Your server's metadata should appear in the servers array. Downstream directories don't update instantly. The About page says aggregators are expected to pull "on a regular but infrequent basis (for example, once per hour)."

Step 6: Version every change

The versioning guide sets the rules:

• "The version string MUST be unique for each publication of the server." Once published, it and other metadata "cannot be changed."
• Semantic versioning is recommended. Ranges such as ^1.2.3 or 1.x are prohibited.
• For a remote server with an API version, "the server version should align with the API version," for example 2.1.0 for .../mcp/v2.1.
• For a metadata-only update, such as a better description, use a prerelease version like 1.2.3-1.

The registry FAQ says you can't currently delete or unpublish a server. Plan your name and first version carefully.

Step 7: Automate releases in CI

The GitHub Actions guide has a DNS version of its workflow. It triggers on version tags, installs mcp-publisher, then runs:

      - name: Authenticate to MCP Registry
        run: ./mcp-publisher login dns --domain example.com --private-key ${{ secrets.MCP_PRIVATE_KEY }}

      - name: Publish server to MCP Registry
        run: ./mcp-publisher publish

Add an MCP_PRIVATE_KEY repository secret with your Ed25519 private key. The guide also shows an optional jq step that sets version in server.json from the tag. Tag a release with git tag v1.0.0 and git push origin v1.0.0 to run it.

The guide's other options are GitHub OIDC (login github-oidc, which needs id-token: write and no secret) and a GitHub personal access token. Both tie your name to an io.github. namespace, so a company domain needs the DNS route.

After publishing: what the registry does and doesn't do

A listing proves who published the server. It doesn't vouch for quality. The moderation policy says maintainers "only remove illegal content, malware, spam, and completely broken servers," and consumers "should assume minimal-to-no moderation."

It also doesn't reach every AI app. Anthropic's directory vs custom page says the Anthropic Directory is independent of the MCP Registry, and "Publishing to those doesn't surface your server in Claude." Submit there separately, as covered in how to get listed in Claude's connectors directory. ChatGPT has its own process too: see how to submit an app to ChatGPT.

The registry is one item on the wider MCP server launch checklist. For other listing channels, see the best MCP directories.

Next step

Publishing makes your server findable by aggregators. Turning that into users takes docs, setup pages and AI search visibility. eSEOspace's MCP marketing service handles registry and directory submissions and the launch pages around them, scoped per project.

Frequently asked questions