Guide · MCP Registry Distribution

Getting your MCP server listed on MCP.so

MCP.so is a community-driven MCP server directory that catalogs servers across every major category — from database connectors and file system tools to browser automation and code execution environments. It is one of the most browsed starting points for developers evaluating which MCP servers to add to their Claude Desktop or agent pipeline configuration. Getting listed on MCP.so adds a discoverable presence for your server in a high-intent audience: developers who are specifically looking for MCP server options, not just general-purpose tools.

TL;DR

Submit your MCP server to MCP.so via their submission form — provide your GitHub repository URL (for open-source servers), a short description, and the appropriate category. MCP.so may verify your endpoint for remote servers before listing. Write a compelling description that matches what developers search for. Use AliveMCP to monitor your endpoint so it's always up when MCP.so's crawler re-checks it.

What MCP.so shows for each listing

MCP.so's directory shows each server with a standardized card layout. Understanding what goes into each field helps you optimize your submission:

Card field	Source	Optimisation
Server name	Your submission + repository name	Use a clear noun phrase: "PostgreSQL MCP Server", not "mcp-pg"
Short description	Your submission (140 chars)	Lead with the use case: "Query your PostgreSQL database directly in Claude — run SELECTs, describe tables, list indexes"
Category	Your selection at submission	Pick the most specific available category
GitHub stars	GitHub API (live)	Stars accumulate with quality + promotion — they're a trailing indicator
Last updated	Latest repository commit date	Commit regularly — stale repositories score lower in recency sort
Install command	Your submission or parsed from README	Provide the npx/uvx one-liner; reduce installation friction
Tool list	Parsed from README or live protocol check	List tools explicitly in README; name them clearly

The short description is the most influential field for click-through rate. Developers scanning the MCP.so directory see dozens of server cards in a single scroll — your description must communicate the specific value in the first few words. Descriptions that start with "A powerful MCP server that..." lose readers before they reach the substance.

Category selection strategy

MCP.so organizes servers into categories and developers often browse by category when they know what type of tool they need. Choosing the right category is as important as writing a good description. The major categories and their typical servers:

Category	Typical servers
Database	PostgreSQL, MySQL, SQLite, MongoDB, Redis connectors
Developer Tools	GitHub integration, code execution, CI/CD, linting
File System	Local file access, S3, Google Drive, Dropbox
Web & Browser	Web search, Playwright automation, screenshot tools
Communication	Slack, email, calendar, notifications
Data & Analytics	Metrics platforms, data warehouses, BI tools
Productivity	Notion, Jira, Linear, project management
AI & ML	Vector databases, embedding services, model inference
Monitoring	Uptime tools, log aggregation, alerting systems

If your server spans multiple categories (a common pattern — many servers both query a database and expose analytics), pick the primary use case. You can mention secondary capabilities in the description. Servers in the "Other" or "Miscellaneous" category receive less discovery because developers browsing categories skip it.

Verification for remote servers

For servers that expose a public HTTP endpoint (as opposed to locally-installed stdio servers), MCP.so may verify that your endpoint speaks MCP before publishing your listing or displaying a "verified" badge. This verification is similar to what other registries perform:

# Test your endpoint before submitting to MCP.so
# 1. Verify TLS and HTTP reachability
curl -I https://your-server.example.com/mcp

# 2. Send a real MCP initialize request
curl -X POST https://your-server.example.com/mcp \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "initialize",
    "params": {
      "protocolVersion": "2024-11-05",
      "capabilities": {},
      "clientInfo": { "name": "mcp-so-verifier", "version": "1.0" }
    }
  }'

# 3. Verify tools are returned
curl -X POST https://your-server.example.com/mcp \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":2,"method":"tools/list","params":{}}'

Run these commands from a machine with a different network than your server (or use a service like check-if-mcp-server-is-alive) to simulate what MCP.so's verifier will see. A common pitfall is a server that works on your local network but is blocked at the firewall for external traffic.

The serverInfo object in your initialize response should include a meaningful name and version — MCP.so may display these on your listing. Use a human-readable name ("My Analytics MCP Server") rather than a technical identifier ("mcp-analytics-v2-prod").

Embedding the AliveMCP status badge in your listing

MCP.so allows custom links and README-embedded content to appear alongside your listing. An AliveMCP status badge communicates real-time reliability to developers evaluating your server:

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

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

The badge reflects real-time status from AliveMCP's 60-second probe cycle. A green badge on a GitHub README that is embedded in a MCP.so listing provides immediate trust signal to developers. Developers comparing two similar MCP servers will prefer the one that visibly demonstrates reliability over the one with no status information.

The status badge is available on AliveMCP's Author tier ($9/mo). Your server is automatically monitored on the free tier — the badge embed requires the Author tier to get a stable, publicly-linked badge URL tied to your claimed listing.

Related questions

Does MCP.so have a manual review process?

MCP.so's review process varies by submission type and has evolved over time. Most community submissions go through a lightweight moderation check (primarily to prevent spam and verify the submission is a genuine MCP server) rather than deep technical review. Automated verification for remote endpoints is handled programmatically. If your submission is not approved within a few days, check that your endpoint passes the manual verification commands above and that your description is clearly an MCP server rather than a general software tool.

Can I update my MCP.so listing after submission?

Most directory platforms including MCP.so allow you to edit your listing metadata (description, category, links) after initial approval. GitHub stars and last-updated date refresh automatically from the GitHub API. For protocol-level information (tool list, server capabilities), MCP.so may need to re-scan your endpoint to update the listing. Contact MCP.so's team to request a re-scan if your tool list has changed significantly since your original submission.

How does MCP.so compare to listing on Smithery or Glama?

Each directory has a different user base and discovery mechanism. Smithery is tightly integrated with the Cursor and Claude Desktop ecosystems and has the most sophisticated install-from-browser UI. Glama targets developers using Glama's AI playground and has a strong emphasis on protocol verification. MCP.so is the broadest community directory with the most categories and the most browsed-by-category UI. List on all three — they have different users and there's no exclusivity. Being on all directories is a distribution multiplier with minimal ongoing work beyond keeping your server healthy.

What happens if my server goes down after being listed on MCP.so?

If MCP.so re-checks your endpoint and finds it unreachable or not speaking MCP, your listing may lose its verified badge or be marked as inactive. More impactfully, developers who try to connect to your server based on the MCP.so listing will fail — and that failure creates negative associations with your server's reliability. The best defense is continuous external monitoring: AliveMCP alerts you within 3 minutes of a failure (3 consecutive failed probes), giving you time to fix the issue before it becomes a multi-hour outage that generates user complaints and registry re-scan failures.