Ship an MCP server for your product

The hard part of shipping an MCP server is not the server. A minimal one is an afternoon. The hard part is the question every guide skips: once it exists, does anyone find it? We can answer that with receipts because we shipped one for this site, @okaneland/mcp, eleven days before the 2026-07-28 spec went final, and we kept the distribution log, including the parts that did not go our way.

Here is the whole answer up front. Building a compliant server today is a short, well-documented job under the current SDKs. Distribution is a long tail of directory submissions, most of which you cannot verify moved anything, and at least one of ours is still stuck. This piece is both halves: the minimal build under the 2026-07-28 revision, and the real reach of the thing once it was live.

What changed on July 28, and what a server must do

The current spec revision, 2026-07-28, made the protocol stateless: it removed the initialize handshake, and a client and server now carry version and capabilities in request metadata rather than a negotiation round-trip. For a tools-only server, the requirements are short and worth quoting: declare the tools capability, respond to tools/list, and handle tools/call. Resources and Prompts are optional; most product servers are just tools.

The SDKs shipped alongside it. Both @modelcontextprotocol/server and @modelcontextprotocol/client are at 2.0.0 on npm as of late July, and the TypeScript SDK split into separate server and client packages. On Python, pip install "mcp[cli]" now pulls the 2.x line; pin below 2 if you need to stay on v1 for an existing server.

The minimal server, verbatim

A tools-only TypeScript server under v2 is a handful of calls: construct an McpServer, registerTool with a name, an input schema, and a handler, and connect it over a StdioServerTransport. That is the entire skeleton; everything else is your tool’s logic. The Python path mirrors it through the mcp package’s server helpers. The point of naming the exact API surface is that it is small: if a walkthrough has you writing more than this to answer tools/list and tools/call, it is doing too much.

What we actually shipped is a two-tool server built on the v1-era SDK (^1.12.0), published eleven days before the revision, so it predates the stateless changes. It still runs, because the spec keeps a compatibility path for older servers, and it is a fair illustration of the gap every maintainer now has: a working server from six weeks ago is already a spec revision behind. If you are building today, build on v2; if you shipped on v1, you are not broken, but you are on the legacy side of the matrix.

Getting listed: the six-channel log

This is the half nobody publishes, so here is ours, live-checked on 2026-08-12. “Listed” is not one thing, so each row says what state it is actually in.

• Official MCP registry: active. Listing published 2026-07-18 via the publisher tool, which is why 0.1.1 exists: the republish added the mcpName field that proves registry ownership, along with a repository field the first version lacked.
• Smithery: listed.
• Glama: present but unclaimed, with its automated quality score not yet run, so “listed” here means indexed, not verified.
• awesome-mcp-servers (PR #10337): still open, not merged. Earlier it repeatedly re-conflicted against a fast-moving base; today it is mergeable-clean but held on a reviewer request to claim the Glama page and earn a score badge first, which the still-unclaimed Glama listing has not satisfied. Our own internal note recorded 228 new upstream commits during one roughly fifteen-minute window while we watched, a single observation of how fast that list churns, not a measured rate.
• mcp.so and PulseMCP: unresolved. Both use client-rendered search we could not confirm a listing through from the outside, so we log them as submitted-and-unverified rather than live.

That is three live, one open, two unresolved, and the blunt headline is that shipping to a registry is easy and confirming you actually landed is not.

What distribution we actually got

@okaneland/mcp recorded 470 downloads in the last-month window, and the shape matters more than the total. About 273 of the roughly 480 lifetime downloads landed in the first 48 hours after publish, split across the two release days. After that the daily curve runs low and lumpy, several zero-download days and the odd spike into the twenties, not a steady stream. npm does not separate mirror and bot traffic from human installs, so we will not claim those 273 were or were not real users; what we can say is that a publish-day spike over a quiet baseline is the normal shape, and reading the raw month total as “470 users” would be the mistake this section exists to prevent.

We have no referral or citation data tying any of it to a directory, because no analytics link was in place, so we credit no channel with moving anything. That absence is itself the lesson: you can do the whole distribution ritual and still not know which listing, if any, sent you a single install.

When a server is a product, and when it is a channel

The strategic read sits underneath the mechanics. A few builders sell MCP access as the product, the way the €9-and-€19 gated server in our Studio interview does, and the economics of what agent tools charge for is its own study. For most of us, though, a server for our product is a distribution channel: a way for an agent to reach our thing, valuable in proportion to how many agents actually do. On our numbers, that value is real but small, and pretending otherwise would break the only thing a receipt is good for.

Should you ship one

Ship one if an agent doing your product’s job is genuinely useful, and treat the build as the cheap part it is. Do not ship one expecting the registries to deliver an audience; on our measured experience they deliver a listing, and the listing is not traffic. Keep the server small for the reason the MCP tax study measures: every tool you expose is context weight an agent pays to use it. And log your own distribution plainly, because the field is young enough that a real download curve and a stuck PR are more useful to the next builder than another hello-world. The method here is pinned to the 2026-07-28 spec and the SDK versions above; re-check both before you build, because in this corner of the stack six weeks is a revision.