How to grow your MCP server: 9 tactics that actually work

You built an MCP server. It works. Almost nobody is using it.

Most growth advice for MCP servers is recycled SaaS marketing — "post on Twitter, build a community." This list is different: it's the nine things that actually moved numbers for us, first on our own servers (Dali, a demo flights server, and the SDK they carry), then for the publishers we work with. Everything here is something we did, not something we read.

1. List everywhere — your README is your landing page

PulseMCP, Glama, Smithery, mcp.so, the awesome-mcp lists — or Lulu MCPs, which aggregates all of them into one searchable index and pays you when it does. Every registry listing is free distribution, and the crawlers aren't just human: agents pick tools out of these indexes mid-task. Your README is the landing page for both audiences, so the first screen must carry the whole pitch — what it does in one sentence, the install command, and a 30-second example. If the reader has to scroll to find out how to install you, you've already lost the agent and most of the humans. (More on the discovery stack in our distribution post.)

2. The one-command install

Friction is the number one killer, and installation is where it concentrates. The old path: clone a repo, install dependencies, hand-edit a JSON config, restart the client. The new path:

claude mcp add --transport http your-server https://your-host.dev/mcp

One line, zero local setup, working in the next conversation. When we moved our own demo server to this, the difference wasn't subtle — config-file instructions are where trial goes to die. Every step you remove keeps a real slice of people who would have quietly bailed.

3. A 40-second demo video beats a wall of docs

Nobody reads docs to decide whether to try something — they decide first, read later. Show the whole loop in under a minute: a user asks a question, your tool answers it, done. Ours is 46 seconds and it does more convincing than every page of documentation combined. Keep it real UI, not slideware, and keep it short enough that nobody checks the scrub bar.

4. Name your tools for the model, not for you

Here's the part that has no web equivalent: your tools get chosen by an LLM. When a user says "find me flights," the host model scans available tools and picks one — which means tool names and descriptions are SEO for agents. search_flights with a description that says what it does, when to use it, and what it returns gets picked. api_v2_query does not. We've watched hosts skip over perfectly good tools simply because the description didn't match how users phrase the need. Write descriptions the way your users talk.

5. Ship a hosted endpoint, not just a repo

A repo asks for an afternoon; an endpoint asks for ten seconds. Remote MCP over HTTP means the trial is zero-install: add the URL, use it, remove it if it's not for you. Our demo servers live at public endpoints for exactly this reason — the fastest path from "saw it on a registry" to "it answered my question" wins, and a hosted URL is that path.

6. Kill signup friction — the first 60 seconds decide

We rebuilt our own publisher signup this month because it was quietly bleeding people. The old flow: a marketing form, then a login wall, then re-entering everything. The new flow: name, email, URL → magic link → a three-step setup that skips whatever you already answered, with your API key created in-session and shown once. Conversion is won or lost in the first sixty seconds, and every field you ask for before delivering value is a leak. If your server needs a key, generate it inside the flow — not in an email afterward.

7. Publish your numbers

Developers share numbers, not pitches. A launch post is an ad; a numbers post is a story — and the honest version travels furthest, which means including what didn't work. We practice this ourselves: here's ours, including the production bug we didn't notice for days. Nothing on this list is cheaper per reader reached.

8. Let intent pay for your infra

The quiet killer of good MCP servers is the API bill — tools die not from lack of users but from succeeding at their own expense. One labeled sponsored field, matched to the stated intent of the call and rendered only on the host model's judgment, can cover your costs so the tool stays free — and free tools outgrow paid ones. That's the entire pitch; details here if the bill is already real.

9. Borrow other agents' traffic

The endgame is network-shaped: your MCP surfaced — disclosed, labeled — inside related workflows across other agents and tools, the way apps once grew inside other apps. We're building exactly this: a "Promote your MCP" flywheel where the revenue your server earns can be reinvested into placements across the network, so usage funds adoption and adoption funds usage. It's the tactic on this list that compounds.

The full playbook

The expanded version of this post — checklists, examples, and the parts that didn't fit — is The MCP Growth Kit: the Playbook as a designed PDF for you, plus a machine-readable playbook and ready-to-run skills your coding agent can execute (unzip, point your agent at it, say "grow my MCP"). Get the Kit free — and when you're ready to put tactic #8 to work, publisher setup takes about a minute. We timed it.