How to Get Your MCP Server Listed in Every Major Registry: Smithery, Glama, PulseMCP, and MCP.so

The distribution problem

When a developer needs an MCP server that does X, they do not usually go to GitHub and search. They go to a registry. Smithery surfaces servers with a polished install-from-browser UI tightly integrated with Claude Desktop and Cursor. Glama embeds its MCP directory in an AI playground where developers are already evaluating tools. PulseMCP aggregates across the ecosystem including the official Anthropic-maintained registry. MCP.so is the broadest community directory, organized by category and browsed by developers who know what type of tool they want but haven't decided which one.

Each registry serves a different slice of the developer population. Smithery skews toward developers configuring Claude Desktop and Cursor. Glama targets developers building with the Glama playground. PulseMCP is used by developers who want a cross-registry aggregate view. MCP.so is browsed by developers evaluating options category by category. Being on all four is not redundant — each one adds incremental distribution to a different audience that may never see your listing on the other three.

The upfront cost of getting listed on all four is a one-time setup of roughly two hours. The ongoing cost is keeping your server healthy — which you should be doing anyway. There are no exclusivity requirements. There is no reason not to be on all four registries simultaneously.

The universal verification sequence

Before touching any registry-specific setup, get this sequence working cleanly. Every registry runs it. If it fails, no registry will list you as verified, and some will not list you at all.

# The universal MCP registry verification sequence
# Run this from an external network before any submission

SERVER_URL="https://your-mcp-server.example.com/mcp"

# Step 1: TLS verification — all registries require HTTPS with a public CA cert
openssl s_client -connect "$(echo $SERVER_URL | sed 's|https://||' | cut -d/ -f1):443" \
  -servername "$(echo $SERVER_URL | sed 's|https://||' | cut -d/ -f1)" </dev/null 2>&1 \
  | grep "Verify return code"
# Expected: Verify return code: 0 (ok)
# Fail: self-signed cert, expired Let's Encrypt, wrong SAN

# Step 2: MCP initialize handshake — the minimum bar for "MCP-compliant"
curl -s -X POST "$SERVER_URL" \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "initialize",
    "params": {
      "protocolVersion": "2024-11-05",
      "capabilities": {},
      "clientInfo": { "name": "registry-verifier", "version": "1.0" }
    }
  }'
# Expected: {"jsonrpc":"2.0","id":1,"result":{"protocolVersion":"2024-11-05","serverInfo":{"name":"...","version":"..."},"capabilities":{...}}}
# Fail: HTTP 200 with empty body, HTML response, or missing protocolVersion

# Step 3: Tool list — must be non-empty with descriptions
curl -s -X POST "$SERVER_URL" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":2,"method":"tools/list","params":{}}'
# Expected: {"jsonrpc":"2.0","id":2,"result":{"tools":[{"name":"...","description":"...","inputSchema":{...}}]}}
# Fail: empty tools array, missing description on any tool, malformed inputSchema

Three failure modes show up more than any others across all registries:

1. HTTP 200 but initialize fails. A misconfigured reverse proxy returns 200 for any unrecognized path without forwarding to the MCP process. The registry's TCP check passes, the HTTP check passes, and then the initialize fails with an HTML page or empty body. Fix: verify your proxy routes POST requests to the MCP path to the actual MCP server process, not to a default "not found" handler.
2. Self-signed or expired TLS. Registries verify TLS chain to a public CA. Let's Encrypt via Caddy or Certbot handles this automatically if configured correctly — the most common failure is auto-renewal that stopped working silently. Fix: add certificate expiry monitoring separate from your MCP protocol monitoring.
3. Empty or undescribed tools. A server that registers tools asynchronously on startup may return an empty tools array if tools/list arrives before initialization completes. Tools without description fields fail some registries' schema checks. Fix: ensure async initialization completes before accepting any requests, and add descriptions to every tool — the spec requires them and every registry enforces them.

Once the sequence above passes from an external IP (not your development machine's network), you are ready to submit to any registry. The registry-specific setup described below is additional, not prior — it shapes how well your listing ranks, not whether it appears.

Smithery: smithery.yaml and package metadata

Smithery (smithery.ai) is where many Claude Desktop and Cursor users go first when they want to find or install an MCP server. It has the most sophisticated install-from-browser UI of any registry — users can configure your server's environment variables through a generated form without ever editing a config file. That form is generated from your smithery.yaml.

The smithery.yaml manifest

Add this file to your repository root before submitting. It is required for Smithery; every other registry ignores it.

# smithery.yaml — place in repository root
startCommand:
  type: stdio                     # or "url" for remote HTTP/SSE servers
  configSchema:
    type: object
    properties:
      apiKey:
        type: string
        description: "API key for the upstream service (required)"
      region:
        type: string
        enum: ["us-east-1", "eu-west-1", "ap-southeast-1"]
        description: "Target region for queries"
        default: "us-east-1"
      maxResults:
        type: integer
        description: "Maximum results per query (default: 20)"
        default: 20
    required:
      - apiKey

# For remote HTTP/SSE servers:
# startCommand:
#   type: url
#   url: https://your-mcp-server.example.com/mcp

The configSchema drives Smithery's installation UI. Every property with a description becomes a labeled form field. enum constraints become dropdowns. default values pre-populate fields. Properties in required without defaults become mandatory fields that block installation until filled. Write descriptions from the user's perspective — "API key for the upstream service" is more useful than "apiKey".

Package.json metadata Smithery reads

Alongside smithery.yaml, Smithery's indexer reads your package.json (or pyproject.toml for Python servers). These fields affect your listing's display and search ranking:

{
  "name": "@yourorg/mcp-your-server",
  "version": "1.2.0",
  "description": "MCP server for querying your analytics platform — surfaces metrics, funnels, and cohort data directly in Claude.",
  "keywords": [
    "mcp",
    "mcp-server",
    "analytics",
    "metrics",
    "model-context-protocol"
  ],
  "repository": {
    "type": "git",
    "url": "https://github.com/yourorg/mcp-your-server"
  },
  "license": "MIT",
  "bin": {
    "mcp-your-server": "./dist/index.js"
  }
}

The description field becomes the short description on your Smithery listing card. Write it from the user's perspective — what can they do with this server? The keywords array feeds Smithery's search index — always include mcp and mcp-server as base terms, then add domain-specific terms users would actually search. The bin entry tells Smithery how to invoke your server in stdio mode.

What Smithery's crawler verifies

Smithery re-crawls published listings on a roughly weekly schedule. A listing that was verified at submission can lose its verified badge on the next re-crawl if the server has regressed. Smithery runs the full verification sequence — not just an HTTP ping — so a server that returns HTTP 200 but has a broken MCP layer will fail re-verification even though superficial monitoring tools show it as "up".

Submit your GitHub repository URL at smithery.ai/submit. Smithery's crawler verifies within minutes to a few hours for most submissions. If your listing doesn't appear after 24 hours, run the manual verification sequence above and check that your endpoint passes before contacting Smithery support.

Glama: scanner verification and tool description quality

Glama (glama.ai) embeds its MCP directory in an AI playground that developers use to build and test agent pipelines. Glama performs the most thorough protocol verification of any registry — it sends a complete TLS verification, initialize handshake, and tools/list check before publishing your listing, and it re-scans on a weekly cadence.

Submission types

Glama accepts two submission paths. For locally-installable servers (stdio), submit your GitHub repository URL — Glama performs static analysis of your repository structure, package metadata, and tool definitions without running the server. For remote servers (HTTP/SSE), submit your public endpoint URL — Glama runs the live verification sequence. The endpoint must be HTTPS with a valid certificate from a public CA. Self-signed certificates fail immediately; Glama does not follow more than 3 redirect hops and prefers stable non-redirecting URLs.

Writing tool descriptions that rank in Glama's search

Glama indexes your tool names and descriptions for its internal search. When a developer searches "analytics MCP server" or "query database MCP", Glama matches against tool descriptions. Vague descriptions do not match meaningful queries.

The pattern that ranks well across Glama (and the other registries) is: verb + object + constraints or context.

Keep the most important information in the first 120 characters — Glama truncates descriptions in card views beyond that. The full description is still indexed for search regardless of display length.

Submit via Glama's submission form at glama.ai. Glama's scanner verifies within hours for most submissions. For authenticated servers (servers that require authentication for the initialize step), Glama cannot verify the MCP layer — it can only verify the HTTP layer. If your server requires auth for all requests including tools/list, Glama verification will fail. The common solution is to make the tool list available without authentication while requiring authentication for actual tool execution.

PulseMCP: GitHub topics and README structure

PulseMCP (pulsemcp.com) takes a different approach from Smithery and Glama. Its primary discovery mechanism is GitHub topic crawling — not a submission form. If your repository is public and tagged with the right topics, PulseMCP's weekly scan will find it automatically. PulseMCP also aggregates from other registries including the official Anthropic-maintained server list and Smithery, so a server already listed there may appear in PulseMCP automatically.

GitHub topics that trigger discovery

Add these topics to your repository via the GitHub "About" section's gear icon:

# Required for PulseMCP discovery
mcp-server

# Additional topics that increase discoverability
model-context-protocol
mcp
claude-mcp
anthropic-mcp

# Domain-specific topics for your server's niche (use remaining topic slots)
analytics          # for a metrics/data server
database           # for a SQL/NoSQL connector
developer-tools    # for CI/CD, linting, code execution
communication      # for Slack, email, calendar servers

GitHub's topic limit is 20 topics, 50 characters each. Use the mcp-server topic first — it is PulseMCP's primary crawl trigger. Then add domain-specific topics that describe what your server actually does. These also feed GitHub's own search and Google's indexing of your repository page.

Discovery is not instantaneous. PulseMCP crawls GitHub topics on a roughly weekly schedule. Expect your server to appear in PulseMCP within one to two weeks of adding the topic. You can submit manually via PulseMCP's website to accelerate this if the GitHub topic alone is not surfacing your server.

Repository metadata PulseMCP surfaces

Once PulseMCP discovers your repository, it reads several fields to populate your listing card:

The GitHub repository description (the "About" field, not the README's first line) is the most visible text on a PulseMCP listing card. Write it as a single-sentence pitch that leads with the use case: "MCP server for querying your PostgreSQL database — run SQL queries, list tables, and get schema info directly in Claude." Avoid descriptions like "An MCP server" or "MCP integration" — these provide no signal to developers scanning the directory.

README structure for optimal PulseMCP listings

PulseMCP parses your README to extract the tool list. A README that follows a predictable structure gets parsed reliably and produces a complete listing. One that doesn't gets "Tools: unknown" — which reduces click-through from developers evaluating options before installing.

# mcp-your-server

> MCP server for [your use case]. Exposes N tools to [what the tools enable].

## Tools

| Tool | Description |
|------|-------------|
| `query_database` | Run a SQL SELECT query and return results as structured JSON |
| `list_tables`    | List all accessible tables with row counts and schema info |
| `describe_table` | Get column definitions, indexes, and constraints for a table |

## Installation

### Claude Desktop

Add to `claude_desktop_config.json`:

```json
{
  "mcpServers": {
    "your-server": {
      "command": "npx",
      "args": ["-y", "@yourorg/mcp-your-server"],
      "env": { "DATABASE_URL": "postgresql://user:pass@host/db" }
    }
  }
}
```

### Remote endpoint

```
https://your-mcp-server.example.com/mcp
```

## Configuration

| Variable | Required | Default | Description |
|----------|----------|---------|-------------|
| `DATABASE_URL` | Yes | — | PostgreSQL connection string |
| `MAX_ROWS` | No | 100 | Maximum rows per query |

The Tools table is the most important section for PulseMCP discoverability. The Installation section provides the quickstart developers will copy. The Configuration table documents environment variables so developers can evaluate your server's setup requirements before installing. All three sections serve different parts of the developer evaluation funnel.

MCP.so: category selection and badge embedding

MCP.so is the broadest community directory in the MCP ecosystem, organized by category and browsed by developers who know the type of tool they want but haven't decided which one. Getting listed on MCP.so adds discoverability in a high-intent audience — developers who arrive via category browse have already decided they want an MCP server in that category.

Category selection strategy

Choosing the right category is as important as writing a good description. Developers browsing MCP.so scan by category first, then by description. A miscategorized server misses its primary audience.

If your server spans multiple categories, pick the primary use case. Servers in "Other" or "Miscellaneous" receive less discovery because developers browsing categories skip it. A server that does "Query database + send Slack alert" belongs in Database, with the Slack capability mentioned in the description — not in Miscellaneous because it does both.

Short description optimization

MCP.so's card view shows 140 characters of your description. The first sentence is what developers read before deciding to click. Apply the same verb+object+constraints pattern used for Glama tool descriptions, but at the server level:

Embedding an AliveMCP status badge

MCP.so shows your README content alongside your listing. A live status badge provides immediate trust signal to developers comparing two similar servers — one that shows "● Live · 99.8% uptime (30d)" versus one with no status information is an easy choice for a developer who needs a reliable MCP server.

<!-- In your README.md -->
[![MCP Server Status](https://alivemcp.com/badge/your-server-slug.svg)](https://alivemcp.com/status/your-server-slug)

<!-- Renders as: [● Live · 99.8% uptime (30d)] or [● Down · last seen 2h ago] -->

The badge reflects AliveMCP's 60-second probe cycle. It is available on AliveMCP's Author tier ($9/mo). Your server is monitored on the free tier — the publicly-linkable badge URL for README embedding requires Author tier.

Submit to MCP.so via their submission form. Provide your GitHub repository URL for open-source servers, your short description, and the category selection. Most community submissions go through lightweight moderation to verify the submission is a genuine MCP server rather than spam. If your submission is not approved within a few days, verify your endpoint passes the manual verification sequence above and that your description clearly identifies your submission as an MCP server.

Keeping all four listings healthy after approval

Getting listed is the one-time work. Keeping listed is the ongoing work. All four registries re-crawl published servers on periodic schedules — and a server that was healthy at submission can lose its verified badge or its listing entirely if a subsequent crawl finds it unreachable or non-compliant.

Re-crawl cadences by registry

The critical insight from this table: a server can be down for a week before any registry detects it. During that week, users who find your server via registry browse and try to connect will fail — they'll attribute the failure to your server's quality and move to an alternative. They may never return. The registry badge loss is a trailing consequence; the user loss happens first and silently.

What continuous protocol monitoring fills

HTTP uptime monitors (UptimeRobot, Pingdom) only verify that your server returns HTTP 200. They do not verify the MCP initialize handshake succeeds. You can have HTTP 200 and a broken MCP layer simultaneously — this is the most common failure mode after deployments that misconfigure a reverse proxy, break the MCP transport configuration, or ship a version that handles GET but not POST to the MCP endpoint.

AliveMCP probes the full MCP protocol sequence — TLS, initialize, tools/list — every 60 seconds, from external infrastructure. When a failure happens at 3am after a bad deployment, you know within 3 minutes (3 consecutive failed probes), not the next time you log in or the next time a registry re-crawls. That gap is the difference between a 3-minute outage and a 12-hour outage with badge consequences.

The operational discipline that protects four registry listings simultaneously is simple: set up AliveMCP before submitting to any registry. A server that has never gone undetectably dark is a server whose four registry listings stay healthy indefinitely.

The CI verification script

Add this script to your repository and run it in CI after every deployment. It replicates the verification sequence all four registries run, exits 0 on success and 1 on failure, and produces clear output for each check.

#!/bin/bash
# scripts/verify-registry-ready.sh — run in CI after every deployment
# Usage: bash scripts/verify-registry-ready.sh https://your-server.example.com/mcp

set -euo pipefail
SERVER_URL="${1:?Usage: $0 <mcp-endpoint-url>}"
HOSTNAME="$(echo "$SERVER_URL" | sed 's|https://||' | cut -d/ -f1)"
PASS=0
FAIL=0

check_pass() { echo "  ✓ $1"; ((PASS++)); }
check_fail() { echo "  ✗ $1"; ((FAIL++)); }

echo "=== MCP Registry Readiness Check ==="
echo "Target: $SERVER_URL"
echo ""

# 1. TLS certificate — all four registries require public CA, not self-signed
echo "[1/4] TLS certificate..."
CERT_RESULT=$(echo | openssl s_client -connect "${HOSTNAME}:443" -servername "$HOSTNAME" 2>&1 \
  | grep "Verify return code")
if echo "$CERT_RESULT" | grep -q "0 (ok)"; then
  check_pass "TLS certificate valid (public CA)"
else
  check_fail "TLS issue: $CERT_RESULT"
fi

# 2. HTTP reachability
echo "[2/4] HTTP reachability..."
HTTP_CODE=$(curl -s -o /dev/null -w "%{http_code}" -X POST "$SERVER_URL" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":0,"method":"ping","params":{}}' \
  --max-time 10 || echo "000")
if [ "$HTTP_CODE" != "000" ]; then
  check_pass "Server reachable (HTTP $HTTP_CODE)"
else
  check_fail "Server unreachable or timed out"
fi

# 3. MCP initialize handshake — the universal registry gate
echo "[3/4] MCP initialize handshake..."
INIT_RESP=$(curl -s -X POST "$SERVER_URL" \
  -H "Content-Type: application/json" \
  --max-time 10 \
  -d '{
    "jsonrpc":"2.0","id":1,"method":"initialize",
    "params":{"protocolVersion":"2024-11-05","capabilities":{},
              "clientInfo":{"name":"registry-verifier","version":"1.0"}}
  }' 2>/dev/null)
if echo "$INIT_RESP" | grep -q '"protocolVersion"'; then
  PROTO=$(echo "$INIT_RESP" | python3 -c \
    "import sys,json; print(json.load(sys.stdin)['result']['protocolVersion'])" 2>/dev/null)
  check_pass "initialize succeeded (protocolVersion: ${PROTO:-unknown})"
else
  check_fail "initialize failed — response: $(echo "$INIT_RESP" | head -c 200)"
fi

# 4. tools/list — must be non-empty with descriptions
echo "[4/4] Tool list..."
TOOLS_RESP=$(curl -s -X POST "$SERVER_URL" \
  -H "Content-Type: application/json" \
  --max-time 10 \
  -d '{"jsonrpc":"2.0","id":2,"method":"tools/list","params":{}}' 2>/dev/null)
TOOL_COUNT=$(echo "$TOOLS_RESP" | python3 -c \
  "import sys,json; d=json.load(sys.stdin); print(len(d['result']['tools']))" 2>/dev/null || echo "0")
MISSING_DESC=$(echo "$TOOLS_RESP" | python3 -c \
  "import sys,json; d=json.load(sys.stdin); \
   missing=[t['name'] for t in d['result']['tools'] if not t.get('description','').strip()]; \
   print(','.join(missing))" 2>/dev/null || echo "")

if [ "${TOOL_COUNT:-0}" -gt 0 ]; then
  check_pass "tools/list returned $TOOL_COUNT tool(s)"
  if [ -n "$MISSING_DESC" ]; then
    echo "  ! Warning: tools without descriptions (all registries require descriptions): $MISSING_DESC"
  fi
else
  check_fail "tools/list returned empty array or failed — response: $(echo "$TOOLS_RESP" | head -c 200)"
fi

echo ""
echo "=== Results: $PASS passed, $FAIL failed ==="
if [ "$FAIL" -gt 0 ]; then
  echo "Fix failures before submitting to any MCP registry."
  exit 1
else
  echo "Registry readiness: PASS — safe to submit to Smithery, Glama, PulseMCP, and MCP.so."
  exit 0
fi

Run this script in your deployment pipeline after every push to production. A server that passes all four checks immediately after every deployment will never have a registry re-scan catch a regression — because the regression will have been caught in CI first.

The script exits 0 on success and 1 on failure, making it composable with any CI system: GitHub Actions, GitLab CI, CircleCI, or a simple post-deploy hook in your deployment script.

The full checklist before first submission

Use this as your pre-submission checklist. Items are ordered by impact — the first three are required by all registries, the rest are registry-specific optimizations.

The most efficient approach: complete the universal requirements first (HTTPS, initialize, tools/list, response time), then add the registry-specific items in a single pass (smithery.yaml, GitHub topics, README structure, GitHub About description), then submit to all four registries on the same day.

Uptime as distribution equity

Every registry listing you earn represents distribution equity — a discoverable presence in a directory that sends developers to your server. That equity is not permanent. It decays each time a registry re-crawl finds your server unhealthy. The decay is asymmetric: it takes one bad re-crawl to lose a verified badge, but consistent good behavior over multiple crawl cycles to earn it back.

Registry uptime requirements are not demanding. No registry requires 99.9% uptime or imposes SLOs. What they require is availability at the moment their crawler visits. A server that is down for 4 hours once a month has a reasonable chance of being caught by a weekly re-crawl — that is a 12–24% probability of badge loss per month under a random outage model.

The operational cost of continuous monitoring is low. AliveMCP probes every 60 seconds — the same MCP protocol sequence registries run — and alerts within 3 minutes of a failure. The four registry listings you built over hours of setup work are protected by monitoring that catches issues before any re-scan has a chance to detect them.

Distribution without monitoring is an asset that decays silently. Distribution with monitoring is a compounding investment — each healthy re-crawl adds to your listing's trust score and search position. The technical setup for all four registries takes a few hours. The monitoring that protects it takes a few minutes. Do both before you submit anywhere.

Further reading

• MCP server Smithery listing — smithery.yaml manifest reference and submission guide
• MCP server Glama listing — scanner verification and tool description quality
• MCP server PulseMCP — GitHub-based discovery and README requirements
• MCP server MCP.so — community directory category selection and badge embedding
• Universal MCP registry requirements — the single checklist that covers all four registries
• MCP server health check — verifying your server's protocol compliance before submission
• MCP server SSL certificate — keeping TLS valid for registry re-scans
• MCP server uptime badge — embed live status in README for social proof on MCP.so and GitHub
• MCP server uptime monitoring — the gap between registry re-scans and why it matters
• More guides on MCP server reliability