Guide

Publishing your MCP server

By Jorge Ortega · Updated October 3, 2026

An MCP server only gets used once agents and the people who run them can find it. They look in a handful of directories, and each one has its own way in: a JSON file, a DNS record, a form with a human review, or a machine-readable price list. This guide covers what each one asks for, in what order, and what tends to go wrong, from publishing our own servers.

Where do agents find MCP servers?

Directory	What it is	How it reviews
Official MCP Registry	The open catalog of MCP servers that clients and other directories read from.	Automated: it checks your server.json and that you own the namespace, not the server itself.
Glama	A large MCP directory. It imports the registry, checks each server’s health and grades its tool descriptions.	Automated health checks and a tool-quality score.
Smithery	An MCP directory with a gateway that clients can connect through.	Automated: it connects and scans your tools.
Claude connectors directory	The connectors people add inside Claude.	Anthropic reviews every submission.
x402 Bazaar and Agentic.Market	Coinbase’s catalog of endpoints that agents pay for per call with x402.	Automatic, once a payment settles through Coinbase’s facilitator.
x402scan	An explorer and registry of x402 endpoints.	Automated: it probes every endpoint for a live payment challenge.
x402 Trust	Trust scores for x402 endpoints, from continuous monitoring.	Automated scoring; you can verify yourself as the provider.

Companies also buy through the enterprise marketplaces: AWS Marketplace, Google Cloud Marketplace and the Stripe Directory, each with requirements of its own.

In what order?

Get the server ready. Remote, documented, with tools a model can tell apart (the checklist below).
Publish to the official MCP Registry. Other directories, Glama among them, import from it.
Claim your Glama listing once it appears, so you can see its health checks and edit it.
Publish to Smithery. It takes the server’s URL and scans the tools itself.
Submit to the Claude connectors directory. It has a human review, so allow time for questions.
Open the marketplace accounts early if you sell to companies: AWS and Google verify your business before you can list.
List your paid endpoints in the x402 directories if agents pay per call.

Before you publish: a checklist for engineering teams

A remote endpoint

HTTPS with the Streamable HTTP transport. Directories and Claude connect over the internet; a server that runs only on the user’s machine (stdio) is published as a package (npm, PyPI, a container) instead.

Quick, reliable discovery

The initialize and tools/list calls answer fast, every time: health checks and scanners call them. A stateless server is the easiest to run behind a load balancer or on serverless.

Tools a model can choose between

Names that say what they do (list_orders, refund_order), descriptions that say what the tool does, when to use it and what it returns, and annotations: readOnlyHint, destructiveHint, idempotentHint, openWorldHint. Directories grade them, and models pick tools by them.

Authentication that fits the data

No sign-in only for public, read-only data. Anything else uses OAuth as the MCP authorization spec describes, with protected-resource metadata so clients can find your authorization server.

Money-moving tools on a server of their own

Needed if you also want a Claude directory listing: its policy refuses tools that transfer money or execute financial transactions.

Limits and logs

Rate limits per client, and logs that never hold tokens or personal data you don’t need.

A documentation page and a privacy policy

How to connect, the tools, the limits and how data is handled. Reviewers and listings link to both.

Example prompts and test instructions

Three or more prompts that exercise the tools, and steps a reviewer can follow without asking you anything.

Check that the server answers the way a scanner will call it:

curl -s -X POST https://mcp.example.com/mcp \
  -H 'content-type: application/json' \
  -H 'accept: application/json, text/event-stream' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'
# A stateless server lists its tools; a stateful one wants initialize first.

If the server is generated from an API, its OpenAPI spec decides how good the tools are. Our free agent-readiness check scores a spec 0 to 100 and says what to fix first.

The official MCP Registry

The registry at registry.modelcontextprotocol.io is run by the MCP project. It holds metadata, not code: where your server is and what it is called. Publishing is free, with no human review, and other directories read from it. It is still in preview, so its maintainers may reset data before it is generally available.

Write a server.json: a name in your namespace, a description of at most 100 characters, a version, and remotes (the URL and transport) for a remote server, or packages for one users run themselves.
Prove the namespace. Sign in with GitHub for io.github.your-name/…, or prove your own domain for com.example/…: a DNS TXT record on the domain itself (the apex, not a subdomain), or a file at /.well-known/mcp-registry-auth.
Publish with the registry's mcp-publisher command-line tool.

{
  "$schema": "https://static.modelcontextprotocol.io/schemas/2025-12-11/server.schema.json",
  "name": "com.example/orders",
  "title": "Example Orders",
  "description": "Look up, track and refund orders in Example’s order system.",
  "version": "1.0.0",
  "websiteUrl": "https://example.com/docs/mcp",
  "remotes": [
    {
      "type": "streamable-http",
      "url": "https://mcp.example.com/mcp"
    }
  ]
}

A version can be published only once, so bump it to change anything. For the domain proof, the usual Ed25519 key can't be made with the OpenSSL that ships with macOS: install OpenSSL 3, or use the ECDSA P-384 option. When you rotate the key, remove the old DNS record.

Glama

Glama imports servers from the official registry, connects to each one as a client to check it is healthy, and grades every tool definition for quality. For a remote server you don't submit anything: publish to the registry and wait for the listing.

Then claim it. Sign in, start verification on the listing, and prove the domain its namespace names (or the GitHub account): put the token Glama gives you in a DNS TXT record named _glama-claim, or in a /.well-known/glama.json file. One verification covers every server under that domain, including later ones. Glama re-checks it daily, so leave it in place.

A claimed listing shows its health checks and analytics, and you can edit it. Registry updates overwrite the listing's text unless you choose to manage it on Glama instead.

Smithery

Smithery lists a remote server from its URL, on the web or from its command-line tool, and scans the tools itself through its gateway. A free account is enough. Servers live under a namespace: your personal one, or one you create for your company.

npx smithery@latest auth login
npx smithery@latest namespace create example
npx smithery@latest mcp publish "https://mcp.example.com/mcp" -n example/orders

Scan warnings about a missing configuration schema, resources or prompts are only information when a server needs no settings and offers tools alone. If the scan fails to initialize with a 403, your bot protection has probably blocked Smithery's scanner.

The Claude connectors directory

Anthropic's directory of connectors that people add inside Claude. You submit from Claude's directory settings, which needs a paid Claude plan, through a form that asks for:

the server's URL and how it authenticates;
the listing: name, a one-line description, category, links to the documentation and the privacy policy, an icon and a permanent URL slug;
use cases, each with an example prompt;
your company and how the server handles data;
test instructions for the reviewer, and a compliance checklist.

The policy points to check first: no tools that transfer money or execute financial transactions; OAuth for anything that touches a user's data (a server with only public data may need no sign-in); and annotations that tell the truth about what each tool does.

Before you submit, add the server to your own Claude as a custom connector (Settings → Connectors) and run every example prompt. The reviewers will do the same.

The enterprise marketplaces

AWS Marketplace and Google Cloud Marketplace sell to companies: each wants a seller (or producer) account in your company's name, verified before you can list, and runs its own review. Open those accounts early. The Stripe Directory and mpp.dev have requirements of their own.

Marketplace	What a listing needs
AWS Marketplace, with AgentCore Gateway	An MCP server on protocol 2025-06-18 or 2025-03-26 with two-legged OAuth, or an OpenAPI spec; a seller account.
Stripe Directory and mpp.dev	An llms.txt, example prompts and, for pay-per-call, MPP.
Google Cloud Marketplace	An A2A Agent Card, OAuth with dynamic client registration and the procurement integration.

Paid endpoints: the x402 directories

If agents pay per call with x402 (USDC on Base or Solana), three more directories matter. They read machine-readable metadata, not forms.

x402 Bazaar and Agentic.Market. Coinbase catalogs an endpoint after a payment to it settles through Coinbase's facilitator, if its 402 response carries the bazaar discovery extension that describes the input and the output. Give the resource a service name, tags and an icon, or it shows under your bare domain.

x402scan. Register your origin, the whole site, and it finds the endpoints in /openapi.json: each paid operation needs x-payment-info with its price, security: [] when no API key is needed, and a request schema. Then it probes every endpoint for a live x402 v2 challenge on Base or Solana. Register again after a price changes.

// One paid operation in /openapi.json
"/reports": {
  "post": {
    "summary": "Create a report",
    "security": [],
    "x-payment-info": {
      "price": { "mode": "fixed", "currency": "USD", "amount": "0.10" },
      "protocols": [{ "x402": {} }]
    },
    "requestBody": { "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ReportRequest" } } } },
    "responses": { "200": { "description": "The report" }, "402": { "description": "Payment required" } }
  }
}

# What x402scan will see
npx -y @agentcash/discovery@latest discover https://api.example.com

x402 Trust. Scores x402 endpoints from continuous monitoring, and finds them in the Bazaar, x402scan and other sources. Verifying as the provider (a public key in /.well-known/x402-trust.txt and a confirmed email) puts your name and contact on every endpoint. It doesn't change the score. Keep the private key safe: it authorizes changes, removal included.

What goes wrong

Bot protection blocks the scanners.

A web application firewall or a bot-fight mode can answer a directory’s scanner with 403, and the scan fails without saying why. Let the directories’ crawlers through.

Registry versions can’t change.

Each version of a server.json is published once. Fixing a typo means publishing a new version.

Discovery formats move.

x402scan moved from the older /.well-known/x402 manifest to OpenAPI and no longer reads the manifest. Check what each directory reads today, not what a year-old post says.

Validators are stricter than the spec.

For example, an x402 GET endpoint with no parameters still needs an explicit, empty query schema in its discovery metadata, or validators report its input schema missing.

Verification records get cleaned up.

Directories re-check ownership records, Glama daily. Delete an “old” DNS record or file, and the claim lapses.

One server tries to do everything.

Glama’s quality score weighs how well a server’s tools fit together, and a tool that belongs elsewhere costs points. A focused server per purpose scores better and is easier to review.

Descriptions written for people.

Models choose tools by their descriptions. Lead with what the tool does, when to use it and what comes back.

No public documentation.

Reviewers and directory pages link to documentation and a privacy policy. Without them, a review stalls.

Where are Latitude 10’s own servers?

We publish our own servers the way this guide describes. On 3 October 2026:

Agent Readiness, a free, read-only server: in the official MCP Registry as tech.latitude10/agent-readiness, on Glama (ownership verified, graded A for tool quality) and on Smithery.
The store, where agents buy our kits: tech.latitude10/store in the registry, on Glama (also graded A) and on Smithery.
Our paid endpoints: registered on x402scan, and on x402 Trust as a verified provider.

Want it done for you?

The Agent Listing Sprint turns your API into a production MCP server and submits it to these directories and the enterprise marketplaces, at a fixed price. It starts with a readiness review of your API against each one's rules.

See the listing sprint →Ask a question

General information about third-party directories, checked in October 2026. Each directory sets and changes its own rules and decides what it lists; none of them is affiliated with Latitude 10 or endorses it. Check a directory’s current documentation before you submit. Not legal advice. See the Terms of Service.