Guide · MCP Registry Distribution

Getting your MCP server into PulseMCP

PulseMCP (pulsemcp.com) aggregates MCP servers primarily through GitHub topic crawling. Unlike Smithery (which requires a smithery.yaml manifest) or Glama (which runs live protocol verification), PulseMCP's discovery is largely automatic — if your repository is public and tagged with the right GitHub topics, PulseMCP's weekly scan will find it. But "automatic" does not mean "effortless": how your repository is structured, what GitHub topics you use, and whether your README communicates the right information all affect how well PulseMCP's listing represents your server.

TL;DR

Add the mcp-server GitHub topic to your repository. PulseMCP's crawler will discover it within one to two weekly scan cycles. Ensure your README clearly states what your server does, what tools it exposes, and how to install it. For remote servers with public endpoints, PulseMCP may perform a liveness check — keep your server available with AliveMCP monitoring so that the check passes and your listing shows as healthy.

GitHub topics that trigger PulseMCP discovery

PulseMCP's primary discovery mechanism is the GitHub topic index. Repositories tagged with specific topics are crawled and added to PulseMCP's directory. The core topic is:

# Required for PulseMCP discovery
mcp-server

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

Adding GitHub topics to a repository takes three steps:

Go to your repository on GitHub
Click the gear icon next to "About" on the repository sidebar
Under "Topics", add mcp-server and any other relevant topic tags

GitHub topics have a 20-topic limit per repository and a 50-character limit per topic. Use your remaining topic slots for domain-specific terms (analytics, database, jira, etc.) that describe what your server does. PulseMCP may use these to categorize your listing, and GitHub's own search uses them to surface your repository to potential users.

Discovery is not instantaneous — PulseMCP crawls GitHub topics on a schedule (observed as roughly weekly). After adding the topic, expect your server to appear in PulseMCP within 1–2 weeks at most. You can submit your server manually via PulseMCP's submission form to accelerate this if the GitHub topic alone isn't enough.

Repository metadata PulseMCP reads

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

Field	Where PulseMCP reads it	Used for
Repository description	GitHub repository "About" description	Listing short description (140 chars visible)
Repository name	`github.com/org/repo-name`	Listing title if no explicit name is set
Stars count	GitHub API	Popularity sorting in PulseMCP's directory
Last commit date	GitHub API	Activity signal — recently-updated servers rank higher
License	`LICENSE` file or `package.json`	Listed as open-source or proprietary
Install command	README.md (first code block in Installation section)	Shown to users as the quickstart
Tool list	README.md or static analysis of source	Tool names shown on listing page

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

README structure for optimal PulseMCP listings

PulseMCP uses your README to extract tool information and display it alongside your listing. A README that follows a predictable structure gets parsed more reliably:

# mcp-your-server

> One-sentence description of what this MCP server does.

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 | Description |
|----------|----------|-------------|
| `DATABASE_URL` | Yes | PostgreSQL connection string |
| `MAX_ROWS` | No | Maximum rows to return per query (default: 100) |

The Tools table is the most important section for PulseMCP discoverability. PulseMCP extracts tool names from this table to display on your listing and for internal search. If PulseMCP cannot parse a tool list from your README, your listing will show "Tools: unknown" — which reduces click-through from developers who are evaluating whether your server matches their needs before installing it.

How PulseMCP aggregates from other registries

PulseMCP does not only crawl GitHub — it also aggregates listings from other MCP registries including the Official MCP Registry and Smithery. This means a server that is already listed on Smithery or in the official registry may appear in PulseMCP's directory automatically, with metadata sourced from those registries rather than from GitHub.

This has an important implication for monitoring: PulseMCP's health status for your server may reflect the last known state from whichever registry it's syncing from. If Smithery marks your server as unhealthy (because it failed Smithery's re-crawl), PulseMCP may display that unhealthy status too, even if your server is currently working. The opposite is also true — a server that is healthy in Smithery but down in reality will show as healthy in PulseMCP until the next crawler cycle.

This cross-registry latency is why external, independent monitoring matters. AliveMCP probes your endpoint directly every 60 seconds — it does not rely on registry sync cycles. When you know your server is down in real-time, you can fix it before any registry's next scan captures the failure state.

Related questions

How do I get removed from PulseMCP if I shut down my server?

PulseMCP's crawler will eventually detect that your server's repository is archived or your endpoint is gone. For faster removal, contact PulseMCP's team directly through their website or GitHub. Alternatively, archive your GitHub repository — PulseMCP typically stops featuring archived repositories in active listings. If you are shutting down a remote server but keeping the repository, add a notice to the README stating the service is discontinued and remove the mcp-server GitHub topic to signal to crawlers that the repository is no longer actively maintained.

Does PulseMCP show stats like install counts or usage?

PulseMCP surfaces GitHub stars and last-updated date as activity signals, but not install counts (which are not publicly available from GitHub or npm beyond aggregate download statistics). If your server is published on npm, you can display the npm weekly download badge in your README — PulseMCP may surface this in its listing if it reads the README's badge section. GitHub stars are the most visible signal; consistent activity in your repository (commits, releases, issue responses) also contributes to PulseMCP's freshness score.

What's the difference between PulseMCP and the official MCP server registry?

The official MCP registry (github.com/modelcontextprotocol/servers) is maintained by Anthropic and contains a curated list of officially supported and community-contributed MCP servers. Getting into the official registry requires a pull request to that repository and human review. PulseMCP is an independent third-party directory that aggregates from multiple sources including the official registry. Getting into PulseMCP is largely automatic via GitHub topics. For maximum distribution, aim for both: the official registry for credibility and PulseMCP for aggregated visibility.

Does PulseMCP penalize servers that are frequently down?

PulseMCP does not have a publicly-documented uptime SLO requirement, but servers that are persistently unreachable may be marked as "inactive" or demoted in search results over time. More importantly, a server that is frequently down when users try to connect to it generates negative word-of-mouth in the MCP community — which affects your GitHub stars and repeat usage more than your PulseMCP ranking. Use uptime monitoring to keep your server healthy regardless of any specific registry's crawl behavior.