MCP Server Listings and Agent Install Retention

A listing in the official MCP registry produced a median of about 600 installs in the first thirty days for the servers we have shipped. Roughly one in nine of those was still calling a tool at day 30. Directories report the first number. The second one decides whether the listing was worth doing, and most of the work that improves it happens inside your repository rather than on any directory page. Where the listing lives: The official MCP registry, with a valid server.json and namespace verification completed properly. That means a DNS TXT record on a domain you control if you want your own reverse-DNS namespace, rather than sitting under a GitHub-derived namespace that quietly signals a side project. Then Smithery, Glama, PulseMCP and mcp.so, each of which reads slightly different metadata and each of which has a submission path with its own review latency. Host-side surfaces matter more than aggregate directories: the Claude desktop extension route with a properly built bundle, Cursor's directory and its one-click install deeplink, and the VS Code, Cline and Continue marketplaces. Package registries are install paths too, and a server that only installs by pasting JSON into a config file loses most of the audience that a directory sends it. What actually moves installs and retention: The agent is the reader, not the human. Tool names and description strings are what a model consults when deciding whether to call you, and the listing of your tools is charged against the host's context on every turn. A server exposing forty thinly described tools loses to one exposing eight precise ones, both in selection and in whether the host keeps it enabled. We rewrite tool descriptions and input schemas, cut and merge the tool surface, and where the server is genuinely broad we add a single well-named entry point with the detail behind it. Transport matters next: whether you ship stdio, streamable HTTP or both determines which directories can list you at all and whether remote installation works without a local runtime. Authentication is where retention is usually lost; an OAuth flow that completes in the host beats an API key pasted into a config file by a wide margin, and we will tell you when that engineering work is the whole problem and the listing is not. What we change in your repository: server.json and manifest files, tool names, descriptions and schemas, the README's first ninety seconds, a short recording of an agent using the server, install deeplinks per host, and a minimal telemetry hook that is opt-out and counts tool call names rather than payloads, so that day-30 retention is knowable at all. Every change arrives as a pull request your engineers review. We do not merge to your main branch. Outside scope: We do not write your server's business logic. We do not perform a security review; we will flag a tool that accepts an unbounded shell command or returns credentials in a response, but that observation is not an audit and should not be treated as one. We do not buy stars, arrange review swaps or post on your behalf under other identities. We will not submit to directories that charge for placement and present the result as editorial, and there are now several. Who this is not for: Servers that wrap a public API with no authentication and no logic of their own. The agent can call that API directly, and distribution will not change that fact. Teams who want listing volume as the reported outcome. Servers handling data with a consent question attached to it, which in our own recruiting-tools work usually means candidate records: an ATS server whose most useful tool searches a candidate database has a legal question ahead of a distribution question, and we will ask about it before we take the work and have twice declined afterwards.