MCP server registry requirements

The universal registry checklist

Protocol compliance verification script

Run this script against your server before submitting to any registry. It replicates the verification sequence every major registry's crawler performs:

#!/bin/bash
# verify-mcp-registry-ready.sh — run before submitting to any MCP registry
SERVER_URL="${1:-https://your-server.example.com/mcp}"

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

# 1. TLS verification
echo "[1/4] TLS certificate check..."
CERT_CHECK=$(echo | openssl s_client -connect "$(echo $SERVER_URL | sed 's|https://||' | cut -d/ -f1):443" 2>&1 | grep "Verify return code")
if echo "$CERT_CHECK" | grep -q "0 (ok)"; then
  echo "  ✓ TLS certificate valid"
else
  echo "  ✗ TLS issue: $CERT_CHECK"
  exit 1
fi

# 2. HTTP reachability
echo "[2/4] HTTP reachability check..."
HTTP_STATUS=$(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":{}}')
if [ "$HTTP_STATUS" != "000" ]; then
  echo "  ✓ Server reachable (HTTP $HTTP_STATUS)"
else
  echo "  ✗ Server unreachable"
  exit 1
fi

# 3. MCP initialize handshake
echo "[3/4] MCP initialize handshake..."
INIT_RESPONSE=$(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"}}
  }')

if echo "$INIT_RESPONSE" | grep -q '"protocolVersion"'; then
  PROTOCOL_VERSION=$(echo "$INIT_RESPONSE" | python3 -c "import sys,json; d=json.load(sys.stdin); print(d['result']['protocolVersion'])" 2>/dev/null)
  echo "  ✓ initialize succeeded (protocolVersion: $PROTOCOL_VERSION)"
else
  echo "  ✗ initialize failed. Response:"
  echo "    $INIT_RESPONSE"
  exit 1
fi

# 4. tools/list check
echo "[4/4] Tool list verification..."
TOOLS_RESPONSE=$(curl -s -X POST "$SERVER_URL" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":2,"method":"tools/list","params":{}}')

TOOL_COUNT=$(echo "$TOOLS_RESPONSE" | python3 -c "import sys,json; d=json.load(sys.stdin); print(len(d['result']['tools']))" 2>/dev/null)
if [ -n "$TOOL_COUNT" ] && [ "$TOOL_COUNT" -gt 0 ]; then
  echo "  ✓ tools/list returned $TOOL_COUNT tool(s)"
  echo ""
  echo "=== Registry Readiness: PASS ==="
  echo "Your server passes the universal MCP registry requirements."
else
  echo "  ✗ tools/list failed or returned empty tools array"
  echo "  Response: $TOOLS_RESPONSE"
  exit 1
fi

Save this script as scripts/verify-registry-ready.sh in your repository and run it as part of your pre-release checklist. A server that passes all four checks is ready to submit to any MCP registry. The script exits 0 on success and 1 on failure — add it to CI to catch regressions before they affect your live registry listings.

Common registry rejection reasons

The most frequent reasons MCP servers fail registry verification or lose their listings after approval:

Why uptime monitoring is essential for registry health

There is a fundamental gap in the registry lifecycle: registries verify your server at submission time and then re-check on a schedule. Between those checks, your server could be down for hours without your listing showing any indication of a problem. The consequences compound:

1. Registry re-scan catches the failure — your verified badge is removed and your listing is deprioritized.
2. Users try to connect during the outage — they fail, attribute the failure to your server quality, and move on to an alternative. They may never return.
3. Search engines index the down state — if a registry page loads slowly or errors because your server appears unhealthy, it signals poor quality.

The economics of registry discoverability make uptime critically important. You may invest significant effort getting your server listed across four registries. That distribution work is continuously at risk if your server has reliability issues that you discover only after a registry flags them.

AliveMCP probes your endpoint every 60 seconds — the same initialize + tools/list sequence that registries run, but continuously. When a failure happens at 3am after a bad deployment, you know within 3 minutes (3 consecutive probe failures), not the next time you log in or the next time a registry crawls. This is the gap between registry monitoring and real-time protocol monitoring.

// Example: post-deploy health check that mirrors what registries verify
// Run this in your deployment pipeline after every push

async function verifyRegistryReadiness(serverUrl: string): Promise<void> {
  const client = new McpClient();
  const transport = new StreamableHTTPClientTransport(new URL(serverUrl));

  try {
    await client.connect(transport);
    // If connect() succeeds, initialize handshake completed

    const tools = await client.listTools();
    if (tools.tools.length === 0) {
      throw new Error('Server returned empty tools list — registry verification will fail');
    }

    const missingDescriptions = tools.tools.filter(t => !t.description?.trim());
    if (missingDescriptions.length > 0) {
      console.warn(`Warning: ${missingDescriptions.length} tools missing descriptions: ${missingDescriptions.map(t => t.name).join(', ')}`);
    }

    console.log(`✓ Registry readiness verified: ${tools.tools.length} tools registered`);
  } finally {
    await client.close();
  }
}

// In your CI/CD pipeline:
await verifyRegistryReadiness(process.env.MCP_SERVER_URL!);

Related questions

Further reading

• MCP server Smithery listing — smithery.yaml manifest and submission guide
• MCP server Glama listing — scanner verification requirements
• MCP server PulseMCP — GitHub topic discovery and README requirements
• MCP server MCP.so — community directory submission
• MCP server health check — complete protocol health verification guide
• MCP server SSL certificate — certificate management for production
• MCP server uptime badge — embed live status in README for social proof
• AliveMCP — continuous MCP protocol monitoring, the same checks registries run but every 60 seconds