Chapter 30: Publishing, Community & Future

Somewhere between the first working prototype and the day a stranger files an issue against your repository, an MCP server stops being a private tool and becomes a public commitment. That line is easy to cross without noticing. One week the server lives on a developer laptop; the next week it is in a directory listing next to servers maintained by companies with dedicated platform teams. The question is when a server is actually ready to leave your walls, and what healthy participation in the broader ecosystem looks like.

Publishing is a promise about support, trust, and interface stability, not only a distribution decision. Treat it as a marketing step and you will spend the next six months apologizing for choices you did not realize you were making. The rule for this chapter: publish an MCP server only when a named owner can keep that promise for a year, which means answering reports, holding the interface stable, and putting a date on every deprecation.

Currency note. Directory requirements and registry details in this chapter were checked on 2026-09-27 and 2026-09-28. Both change, so check the linked pages for current details before you submit.

What “Publishable” Actually Means

A server is publishable when three separate things are simultaneously true.

The first is that the server solves a defined problem for an identifiable user. Not “anyone who uses an LLM,” but “engineers running Postgres on AWS who want safe read-only access to production schemas from Claude.” If you cannot write that sentence out loud, you are not ready to publish; you are ready to sketch more demos.

The second is that the server has an owner, not just an author. An owner answers questions, reviews security reports, cuts releases, deprecates capabilities on a schedule, and updates documentation when things change. Before publishing, identify who will play that role for the next twelve months and whether they have time for the role on top of their other work. If the answer is “nobody, really,” you are about to publish a liability.

The third is that the interface is stable enough that changing it in the next quarter would feel uncomfortable. Stability does not mean frozen. It means you are willing to add tools, rename them only with a deprecation cycle, and avoid reshaping schemas every time you learn something new. Early-stage servers should not be in public directories precisely because their schemas are still in motion.

The practical minimum set of things a publishable server needs is short and boring:

• Documentation that explains purpose, scope, and hard limits.
• A clear authentication and onboarding path.
• At least three worked examples that reflect real intended usage.
• A named support contact and a channel for security reports.
• A versioning and deprecation policy the owner actually intends to follow.
• A plan for how incidents and breaking changes will be communicated.

If any of those are missing, the server is reachable, not publishable. The pre-publication checklist at the end of this chapter starts from this list and adds what reviewers check.

Distribution Channels

Each distribution channel represents a different audience and a different contract.

The Official MCP Registry at registry.modelcontextprotocol.io launched in preview in September 2025 under the Linux Foundation’s MCP Steering Committee and entered API freeze at v0.1 in October 2025. The registry is deliberately boring: it is a canonical index that clients, aggregators, and marketplaces can pull from, not a curated app store. It hosts metadata only, never your code. You publish the package to its own registry (npm, PyPI, NuGet, an OCI image or an MCPB release) first, then describe it in a server.json manifest that the mcp-publisher CLI submits. The registry validates the manifest against a JSON schema and checks that you own both the package and the name. There is no editorial review, no curated badge, and no ranking. That is a feature. Clients and downstream catalogs layer their own trust decisions on top.

For the book’s notes server shipped as a PyPI package, the whole manifest is this:

{
  "$schema": "https://static.modelcontextprotocol.io/schemas/2025-12-11/server.schema.json",
  "name": "io.github.example/notes",
  "title": "Notes",
  "description": "Create, search, and tag plain-text notes stored on your machine",
  "version": "1.2.0",
  "repository": { "url": "https://github.com/example/notes-mcp", "source": "github" },
  "packages": [
    {
      "registryType": "pypi",
      "identifier": "notes-mcp",
      "version": "1.2.0",
      "transport": { "type": "stdio" }
    }
  ]
}

Ownership is proven twice. The io.github.example/ prefix must match the GitHub account you log in with, and the package’s PyPI README must contain the line <!-- mcp-name: io.github.example/notes --> so the registry can tie the package to the name. Then two commands publish it:

mcp-publisher login github
mcp-publisher publish

mcp-publisher init writes a starting server.json from your project, and mcp-publisher validate checks one without publishing. Bump version in both places on every release; the registry treats each version as a separate entry. A remote server uses a remotes entry with its canonical URL instead of packages, as shown for tickets in Chapter 22.

The Anthropic Connectors Directory at claude.com/docs/connectors/directory is a storefront rather than an index. You submit through the developer portal at claude.ai/directory/manage. Anthropic scans each submission automatically for policy compliance and, by default, lists it as a Community connector; some submissions also get a human review, with times that vary by queue. The requirements include several things this book has argued for throughout. Every tool must have a title and the applicable readOnlyHint or destructiveHint annotation, authenticated services must use OAuth 2.0, and submissions must include a test account for reviewers. Local connectors must also ship a privacy policy, both in the README and in a privacy_policies array in manifest.json. A missing or incomplete privacy policy is grounds for immediate rejection. The directory explicitly targets the union of Claude surfaces — web, Desktop, Mobile, Code, Cowork — which means “it works in Claude Desktop” is not enough; you must test across the target clients.

Docker MCP Catalog and PulseMCP are community-maintained indexes that add their own metadata layer on top of the underlying servers. Docker’s catalog is especially useful when your server’s deployment unit is a container image; PulseMCP focuses on discovery and comparison. These directories change rapidly. Treat them as downstream consumers of your canonical information, not as authoritative records.

awesome-mcp lists and community aggregators occupy the long tail. They are useful for discoverability and ecosystem awareness but are not a substitute for owning your own documentation. A stale awesome-list entry with a dead link erodes trust faster than no entry at all.

Desktop extensions (MCPB) are a distinct distribution format rather than a directory. The MCP Bundle format packages a local MCP server, its dependencies, and a manifest into a single installable file that Claude Desktop and compatible hosts can install with one click. MCPB replaces the earlier .dxt extension. Note that the Connectors Directory has deprecated desktop-extension listings and no longer accepts new MCPB submissions; to distribute a local server through the directory, include it in a Claude plugin. MCPB is still a useful packaging format for direct distribution. If your server is fundamentally local — filesystem access, git, SQLite, local dev tools — MCPB is the right distribution unit. If it is fundamentally remote — SaaS integration, internal platform surface, anything that needs secrets you do not want on user laptops — publish it as a remote server and skip MCPB entirely.

The rule underneath all of this: distribution channels are downstream consumers. Your own repository and your own documentation must remain the authoritative source of truth for capability scope, auth expectations, supported environments, change history, and escalation paths. Directory listings will drift, and stale listings erode trust faster than missing listings. Update your canonical docs first and let the channels follow.

Submission Requirements, Practically

The Connectors Directory submission flow is a useful forcing function even if you never actually submit. Walk through the list and ask whether your server would pass review today.

• Tool annotations. Every tool must carry a title and readOnlyHint: true or destructiveHint: true. If you read Chapter 6 and Chapter 20, you already have these in place. If you do not, adding them now is roughly thirty minutes of work and immediately improves the quality of downstream client UX.

• OAuth 2.0 for authenticated services. The directory requirement is OAuth 2.0, not “here is how to mint a personal access token in our dashboard.” Claude also offers a request-header option (static_headers) for a fixed API key or bearer token, but it is in beta for a limited set of organizations and set up by an organization Owner. Don’t plan a public listing around it. Chapter 19 covered the OAuth implementation; Chapter 18 covered why.
• Privacy policy. For local connectors this must live both in a README section and in a privacy_policies array in the manifest, with HTTPS URLs. The policy must describe data collection, storage, third-party sharing, retention, and contact. “We don’t collect anything” is a valid policy if it is accurate; silence is not.
• Working test account. Reviewers will not have your internal Postgres. Provide sandbox credentials and a written walkthrough that takes someone unfamiliar with your product from zero to a successful tool call.
• Transport compliance. HTTPS, valid CORS where relevant, correct Streamable HTTP behavior, passing MCP Inspector against the live endpoint.
• Branding and surface confirmation. Logo, favicon, and an explicit declaration of which Claude surfaces you have tested. If you have only tested in Claude Desktop, say so.

Even teams who have no intention of submitting to Anthropic’s directory benefit from using this checklist as a pre-publication gate. It makes the implicit requirements of “publishable” explicit, and it forces teams to discover missing pieces before users do.

Documentation That Earns Trust

The minimum publishable documentation answers six questions, in this order, near the top of the README:

1. What is this server for?
2. Which systems can it read from or write to?
3. Which clients and deployment modes does it target?
4. What authentication and approvals does it involve?
5. What data boundaries matter, and what does the server never touch?
6. How should users report problems or security issues?

The best documentation also explains what the server intentionally does not do. “This server does not write to the production database. It never modifies shared calendars. It cannot access files outside the configured project root.” Clear limits reduce support load, discourage misuse, and give reviewers something concrete to verify against. Ambiguity in documentation is not humility; it is an invitation for users to discover your limits by accident.

Include a short changelog at the top of the README, not buried in releases. When a connector user hits a surprising behavior, the first question they ask is “what changed?” Make that question easy to answer.

Finally, write at least one failure-mode section. Not “troubleshooting,” not “FAQ” — a direct description of known sharp edges, the conditions that trigger them, and what the user should do. Honest failure documentation is one of the strongest trust signals a published server can offer.

Strangers Remember Every Breaking Change

Internal users will forgive a renamed tool or a quietly changed schema. External users will remember it as instability, and they can’t walk over to your desk to ask what happened.

Chapter 28 covers the mechanics: additive-only evolution, graceful removal, and changelogs. Publishing tightens one of them. Every deprecation gets a calendar date, written in the tool description, where both the model and the user see it: Deprecated: use search_notes_v2. Removed on 2027-03-01. A sunset of “after the next minor version” means nothing to someone who doesn’t follow your releases, and a deprecation without a date is just a comment.

Publishing converts convenience decisions into trust decisions. That reframe alone catches most of the common mistakes.

Commercial and Organizational Models

When teams ask “can I make money from an MCP server?” the honest answer is: not reliably, and not from the server itself. The server is a shape of access. Value comes from what is on the other side of the access.

Think in layers:

1. Access to proprietary systems or data — defensible when the system itself has a moat.
2. Domain-specific workflow logic — defensible when the logic encodes real operational knowledge.
3. Hosted operation with policy and governance — defensible when customers cannot or should not run it themselves.
4. Enterprise support, compliance, and reliability guarantees — defensible when the buyer is an enterprise with procurement requirements.

A thin MCP wrapper around a commodity API is rarely durable as a standalone business because anyone, including the upstream vendor, can ship the same wrapper next week. A well-operated gateway into a proprietary system with a SOC 2 report, a published SLO, and a human on call is durable because the work is in the operation, not the code.

The same reasoning applies inside a company that does not charge for anything. Shared internal servers still need a clear owner, a support model, and an understanding of who pays for incidents. “Free to use but someone still has to run it” is the foundation of every durable platform, and MCP servers are platforms in disguise.

Participating in the Community Without Adding Noise

The MCP ecosystem is still small enough that individual contributions visibly move the standard. That cuts both ways: helpful contributions compound, and noise compounds too.

Useful contributions, roughly in order of impact:

• Publishing well-scoped example servers that others can learn from — especially servers that demonstrate less-common patterns like Tasks or elicitation under the 2026-07-28 multi round-trip model.
• Improving SDK and specification documentation when you hit something confusing. The fix almost always takes less time than the frustration of the confusion.
• Reporting interoperability pain points with concrete reproductions. “It doesn’t work” is noise; “Client X omits capability Y from the request _meta, but SDK Z requires it” is a useful bug.
• Proposing specification changes (SEPs) with real implementation evidence. The Model Context Protocol Enhancement Proposal process is the formal channel, and the current roadmap explicitly prioritizes SEPs that fall within the stated priority areas and arrive with Working Group backing.
• Sharing postmortems and migration lessons honestly. The ecosystem gets better when practitioners publish what actually broke in production, not only the success stories. Chapter 21 draws on postmortems and advisories that teams and researchers published.

Working Groups and Interest Groups are the structures where most real standards work happens now. The roadmap updated 2026-08-22 names the Transports, Agents, Triggers & Events, SDK, and File Uploads Working Groups, with Agent Identity and Core Primitives groups forming; the Working and Interest Groups page on modelcontextprotocol.io has the current set. If your experience touches any of those, the WGs are the high-impact place to spend your community energy. If you just want to read along, the #registry-dev Discord and the GitHub discussions on modelcontextprotocol/modelcontextprotocol are the lowest-friction entry points.

One warning: the community is big enough now to attract hype. Standards harden through specific feedback, not slogans. If your proposed contribution is a blog post announcing a paradigm shift, it is almost certainly less useful than a pull request fixing a schema typo.

Emerging Patterns Worth Watching

Two patterns have gained enough traction that they are worth understanding even if you are not ready to adopt them.

Code Mode and progressive tool discovery. Cloudflare’s Code Mode, introduced in February 2026, collapsed an entire 2,500-endpoint API into two MCP tools: a search tool over the OpenAPI spec and an execute tool that runs typed code against the resolved operations inside a sandboxed runtime. The result was roughly a thousand tokens of tool surface for an API that would otherwise take over a million tokens to describe. Anthropic independently explored the same idea in “Code Execution with MCP,” and Speakeasy and others have pursued “dynamic toolsets” that combine semantic search with progressive discovery.

The cost is a different security model. The execution surface is now code rather than individual tool calls, so sandboxing, debuggability and review all get harder, and the patterns are still evolving. For a server whose tool surface strains the context window (CRUD over hundreds of entities, or a cloud provider’s full API), progressive discovery is the direction the ecosystem is heading; Chapter 13 makes the same argument without the code sandbox. Budget for it the way you budget for caching: not on day one, but as a known future move.

MCP Apps and interactive UI. The MCP Apps track, shipped in early 2026, lets servers expose interactive UI elements that a compatible host renders inside the chat window. This is still early; host support is partial, the security implications of rendering server-supplied UI are still being worked through, and the submission process for the Connectors Directory imposes extra requirements for MCP Apps (screenshots, UX review). For most servers this is not yet a reason to refactor, but it is a reason to keep tool outputs clean and structured — an MCP App layer becomes much easier to add when your server already treats its responses as data rather than pre-formatted text.

The Optimist and the Skeptic

It is tempting to close a book like this with either cheerleading or cynicism. Neither is honest.

The optimist’s case is real: MCP is a multi-vendor standard under a neutral foundation, and 2026-07-28 turned a remote MCP server into an ordinary stateless HTTP service. The standard is now stable enough that most failures are operators’ choices, not the protocol’s.

The skeptic’s case is also real. Client capability parity is still uneven. Cost and tracing remain unsolved. Several enterprise requirements are expected to ship as extensions rather than core protocol features, which means ecosystem fragmentation is a live risk. Some teams will look at this and reasonably decide that “wait six months” is a defensible posture.

These gaps are not reasons to wait. They are reasons to build conservatively: assume the stable core, treat faster-moving features as optional advantages, and make sure your server still delivers value even if a client does not support the newest primitives.

The operator’s answer is that both views compress into the same guidance. Build against the stable core. Expose intent-shaped tools with honest annotations. Run the auth story correctly. Assume partial client support. Instrument what you can. Publish slowly enough that users can trust you. The features you are tempted to wait for are exactly the ones that will benefit from a production feedback loop.

A Final Implementation Checklist

Before publishing an MCP server to any external channel, check every item on the minimum list in What “Publishable” Actually Means. Then add what reviewers and strangers will check:

• Tool annotations (title, and readOnlyHint or destructiveHint) on every tool.
• OAuth 2.0 with PKCE for remote servers with user identity.
• A privacy policy in both README and manifest, for any server that touches user data.
• A test account with reviewer-ready setup instructions.
• A README that lists the systems the server never touches and carries a failure-mode section.
• A working MCP Inspector session against the published transport.
• A validated server.json, if publishing to the Official Registry.
• A realistic plan for answering issues and security reports within 48 hours.

Any item you cannot check blocks shipping publicly, not shipping internally.

What Comes Next

The Model Context Protocol is getting boring in the right places. The core concepts (tools, resources, prompts, and the client/server split) are stable, even though 2026-07-28 still changed the wire format by removing the handshake and sessions. The authorization story is coherent. The registry exists. Deprecations now follow a published policy with at least twelve months’ notice. The next wave of work is about scale, enterprise fit, and closing the last parity gaps, not about reinventing the core.

That means the hard part has moved where it always eventually moves in a maturing standard: into the operator’s hands. Most MCP servers will not fail because the protocol was wrong. They will fail because someone renamed a tool without a dated deprecation, shipped a destructive action without an annotation, treated publishing as distribution instead of commitment, or stopped answering security reports. All of those are choices an owner makes, and all of them are learnable.

The best shared MCP servers are not the ones with the longest feature lists. They are the ones with clear boundaries, honest documentation, stable behavior, and owners who understand that interoperability is a long-term responsibility. Build those. Publish them carefully. Then get back to work on the next problem your users actually need solved.