Publishing and Maintaining an MCP Server
Ship an MCP server other people can trust: packaging, versioning, documentation, registries, security reviews, and keeping it working.
Building an MCP server for yourself is a weekend project. Publishing one for other people is a commitment. The moment strangers install your server, they're trusting your code with their files, credentials, and data, and running it inside agents that act on what your tools say. They need to be able to install it in one line, understand what it does before they connect it, and rely on it not breaking or turning malicious when you ship an update.
This lesson takes the notes server you've built over the last few lessons and makes it publishable: packaged for npm, versioned like the API it is, documented for humans and agents, listed in the official MCP Registry, reviewed for security before each release, and maintained as the protocol and SDK evolve.
Choose how people will run it
Decide first how people will run your server, because it shapes everything else. The MCP Registry supports several package types, plus hosted servers:
| Distribution | People run it with | Best for |
|---|---|---|
| npm package | npx -y @you/your-server | TypeScript/JavaScript servers; the most common choice |
| PyPI package | uvx your-server | Python servers |
| Docker/OCI image | docker run ... | Servers with system dependencies, or users who want isolation |
| MCP Bundle (.mcpb) | One-click install in desktop apps that support bundles | Non-technical users of desktop hosts |
| Remote URL | Adding the URL in any host | Hosted services, as in Remote MCP Servers |
Many servers offer more than one: an npm package for people who want to run it locally, and a hosted URL for everyone else. This lesson uses npm for the notes server, plus a remote entry if you deployed it.