How to publish an MCP server people actually install
The code is the easy half. What separates a listing with installs from one without is a short list of things that have almost nothing to do with your server working.
Most first listings are a working server and a paragraph. They collect a handful of installs, and their publisher concludes the market is small. The market is not small. The listing is doing one job when it needs to do three: convince a person, satisfy a scanner, and stay legible to a model that will be reading those tool descriptions in six months without you there to explain them.
Your tool surface is the product page
A buyer with any judgement reads which of your tools write before they read your description. Which makes tool naming and tool reach not an implementation detail but the first impression.
- Split the tool that both reads and writes. One half becomes safe to grant, and you have made the decision easier for every reader.
- Name them for what they do to the world, not for what they do in your codebase. create_issue, not handle_request.
- Do not ship a tool you cannot describe in one line. If it takes a paragraph, it is two tools or it is a bad tool.
If your server declares thirty tools, the honest question is whether it is one server or four. Four listings each with a legible surface will outperform one with a wall of them — and each is easier to review, easier to grade and easier to trust.
What a listing has to answer, in order
Nobody scrolls a listing they have not decided about yet. The first two sentences decide whether the rest gets read, and "what it reaches" belongs above the feature list rather than below it.
A free tier is not generosity, it is the funnel
Of everything a publisher controls, opening free moves installs most — and the mechanism is not that engineers are cheap. An engineer evaluating four servers will install the three that cost nothing to try. The fourth never gets evaluated; not rejected, evaluated.
Make it a real allowance rather than a countdown. A trial is a deadline the buyer has to plan around; an allowance is a habit that forms while they are not thinking about you.
Write the description twice
- For a person: what it does, what it reaches, what it costs — in the first two sentences.
- For a model: tool descriptions that state preconditions and failure modes plainly. "Returns 404 if the project does not exist" prevents a retry loop; "gets project info" causes one.
The second audience is the one publishers forget, and it decides whether your server feels reliable. A model that knows what your errors mean will report them; a model that does not will retry them, and the buyer will call that flakiness in a review that stays up forever.
What review is looking for
| What review finds | Why it holds the listing |
|---|---|
| A tool whose reach is wider than its description implies | The description is what the buyer consented to |
| A manifest that does not match the handshake | Then the printed surface is fiction |
| A dependency with a known problem | It ships to every install at once |
| Credentials scoped wider than the tools use | The most common finding, and almost always an accident |
After it is live
- Answer reviews. An unanswered one-star is the last thing a buyer reads before deciding.
- Ship the second version. A listing untouched for months reads as abandoned, whatever the code is doing.
- Watch what gets called. The tools nobody calls are the ones to cut — and cutting them narrows your surface, which raises the grade and shortens the next review.
And read your own error rate the way a buyer does. Publishers see "99% success". Buyers see the one call in a hundred that made their agent do something stupid, and that is the one they write about.