mcpm.sh: a global package manager for MCP servers

The problem MCPM picks, and who feels it

Every MCP client keeps its own list of servers. Claude Desktop has a config file, Cursor has one, Windsurf has one, and the entries are near-identical because an MCP server is described the same way everywhere: a command, arguments, environment variables, or a URL for the HTTP and SSE transports. The duplication is the bug. You add a server in four places, you rotate a token in four places, and you remove it in four places, and nothing tells you when the four have drifted apart.

MCPM's answer is a global workspace. The README describes the v2 model as install once, use everywhere: servers live in one global configuration, and each client integration copies from that store rather than from a per-client list you maintain by hand. The README also states that v2 removes v1's target-based system in favour of this global model, which is a compatibility break rather than a refinement, and the repository carries a MIGRATION_GUIDE.md for it.

Who is this for? Someone running two or more of the supported clients, or someone who tests servers before wiring them into a client. The command set is aimed at that person: mcpm run executes a server directly over stdio, mcpm run --http does the same over HTTP, and mcpm inspect launches the MCP Inspector against a server. None of that requires a client at all.

Global config, profiles, and how a server reaches a client

There are three layers, and the separation between them is the design decision worth understanding.

The first layer is the server store. mcpm install SERVER_NAME pulls a server from the MCP Registry into the global configuration; mcpm uninstall removes it. The registry is a directory in the repository itself, under mcp-registry/, and the README invites contributions to it, so discovery is centralised rather than scraped from arbitrary sources.

The second layer is profiles, which the README calls virtual tags. A profile is not a container and not a copy of a server. mcpm profile create makes a name, mcpm profile edit opens an interactive server selection for it, and mcpm profile rm removes the profile while the servers stay installed. That distinction matters operationally: deleting a profile is cheap and reversible in the sense that nothing was deleted from the store.

The third layer is client integration. mcpm client ls lists the supported clients and their status, and mcpm client edit CLIENT_NAME opens an interactive enable/disable screen for that client. There is also mcpm client import CLIENT_NAME, which reads existing server configurations out of a client, the migration path for someone who already has a working setup. The supported list in the README covers Claude Desktop, Cursor, Windsurf, Vscode, Cline, Continue, Goose, 5ire, Roo Code and OpenCode, with more described as coming.

Execution sits beside these layers rather than inside them. mcpm profile run executes every server in a profile over stdio or HTTP, and mcpm profile share exposes them through a tunnel. The README does not document what the tunnel service is or what it costs, which is a gap if you intend to expose anything beyond localhost.

Installing MCPM and adding your first server

The README lists the recommended install as a shell script fetched over HTTPS. It is a curl pipe into bash, so read it first if that pattern bothers you; the README also points to alternatives such as brew, pipx and uv under its other installation methods section.

curl -sSL https://mcpm.sh/install | bash

After that, mcpm --version should print the installed version. The project uses semantic-release, so version numbers are generated from commits rather than chosen by hand.

Search the registry before installing anything. The query is optional, and with no argument the command browses what is available.

mcpm search
mcpm info SERVER_NAME

mcpm info prints the details of a single server, which is the point at which you can see what command and arguments it will run before it lands in your configuration.

mcpm install SERVER_NAME
mcpm ls

mcpm ls lists installed servers together with their profile assignments, so it doubles as the check that the install worked.

Now wire it into a client. mcpm client ls shows which clients MCPM can see on this machine, and mcpm client edit opens the interactive enable/disable screen for one of them. If you already have servers configured in that client, import them instead of rebuilding the list.

mcpm client ls
mcpm client edit CLIENT_NAME
mcpm client import CLIENT_NAME

To test a server without touching any client, run it directly. The --http flag switches the transport.

mcpm run SERVER_NAME
mcpm run SERVER_NAME --http

Finally, mcpm doctor is the diagnostic command listed under system and configuration. The README excerpt ends at that command, so its full output and the checks it performs are not documented in the README.

Updates assume git, and that assumption leaks

MCPM tracks where each server came from and can pull changes. The README is specific about the mechanism: git-based servers are updated with git pull --ff-only by default, with --rebase as an opt-in alternative, and NPX or UVX servers auto-update at runtime and are only shown for informational purposes.

That is a real constraint, not a detail. A fast-forward-only pull fails whenever the local checkout has diverged from the remote, which happens as soon as anyone edits a server's files locally. The failure is safe in the sense that it will not create a merge commit behind your back, but it is a failure, and the fix is either --rebase or discarding local changes. If you routinely patch servers in place, the default update path will stop working for you and you should know that before you build a workflow on top of it.

The second constraint is metadata. MCPM has to know a server came from git before it can pull it, and the README provides mcpm update --init to scan servers and populate source metadata, plus mcpm update --init --force to re-detect all of it. Those flags exist because detection is not automatic for everything already installed. Run mcpm update --check first, which the README describes as a dry run that checks for updates without applying them. If the check reports nothing for a server you know has moved, the source metadata is probably missing.

A third limitation is simply the registry. Installing by name only works for servers the MCP Registry knows about. Anything else has to be added by hand, and the README does not describe a command for registering a local or private server; mcpm edit SERVER_NAME edits an existing configuration, which implies the entry has to exist first.

How MCPM differs from editing client configs yourself

The obvious alternative is the one most people already use: edit each client's JSON by hand, or use a generator that writes the same block into every client. The difference is where the source of truth lives.

With hand-edited configs, each client file is authoritative for itself. There is no central list, so there is nothing to drift from, and nothing to reconcile. Adding a server means editing N files, and the tool you use to edit them is whatever editor you already have. For one client, this is strictly simpler than installing a package manager, and MCPM does not pretend otherwise.

With MCPM, the global store is authoritative and client files are derived. That buys you one edit instead of N, and it buys you profiles, which have no equivalent in a hand-edited file: you cannot tag a server as belonging to a research workflow in Claude Desktop's JSON. It also buys you the execution commands, since mcpm run and mcpm inspect operate on the store directly.

The cost is a new dependency in the middle of your setup. If MCPM writes a client config incorrectly, or a client changes its config format, you are waiting on MCPM rather than fixing it yourself. The repository layout suggests this is understood: there is a dockerfiles/ directory, a flake.nix and default.nix for Nix users, and a README.nix.md, so the project supports more than one way of getting the same CLI onto a machine. The MIT licence means you can fork and patch if the client integration lags, which is the practical escape hatch for a tool that sits between you and another vendor's file format.

Maintenance, packaging and licence

The repository is not archived, and the last push was on 2026-08-22. Recent tagged releases are v2.15.0 on 2026-05-22, v2.14.0 on 2026-03-27 and v2.13.0 on 2026-01-15. Release automation runs through semantic-release, configured in package.json with the changelog, git and github plugins, so the CHANGELOG.md in the repository root is generated from commit messages rather than written by hand. That means the changelog is only as informative as the commits are, and it is the file to read before an upgrade.

Upgrade cost is low if you installed through a package manager and higher if you did not. The three distribution channels the README names are the install script, Homebrew and PyPI (with pipx and uv as the suggested runners), and the badges at the top of the README track the Homebrew and PyPI versions separately. Installing from PyPI with pipx or uv keeps the CLI in its own environment, which avoids the dependency conflicts you would get from installing it into a project virtualenv.

The dependency list is worth reading before you install, because it is not small. Python 3.11 or newer is required, and the runtime pulls in click, rich, rich-click, requests, pydantic (pinned below 2.12.0), mcp, fastmcp pinned at exactly 2.13.0, ruamel-yaml, watchfiles, duckdb, psutil, prompt-toolkit, inquirerpy, rich-gradient, tomli, tomli-w and jsonschema. DuckDB appears in that list, which fits the usage analytics feature the README mentions, but it also means a columnar database engine is part of your CLI's install footprint. The exact pin on fastmcp and the upper bound on pydantic are the two entries most likely to collide with another tool in the same environment, which is another argument for pipx or uv over a shared venv.

The licence is MIT, stated in pyproject.toml and in the LICENSE file. MIT is permissive: it allows commercial use and modification with the copyright notice retained. This is a description of the licence text, not legal advice, and if you are redistributing MCPM inside a product you should read the LICENSE file yourself. Note that the MIT licence covers MCPM, not the servers it installs; each server in the registry carries its own terms, and MCPM does not appear to surface them at install time.

Editorial conclusion

Adopt MCPM if you run more than one MCP client and are tired of keeping separate server lists in each one; the global install plus profile model is the whole point, and profiles are virtual tags, so removing a profile leaves the servers installed. Skip it if you only ever use a single client, or if you need a server that is not in the MCP Registry and you do not want to hand-edit its config with mcpm edit. Before committing, verify three things on your own machine: that mcpm doctor reports your clients, that mcpm update --check shows the source metadata it detected for your git-based servers, and that your Python is 3.11 or newer. The update mechanism is the part to watch, because it defaults to git pull --ff-only and only uses rebase when you pass --rebase.

Frequently asked questions

Official sources

1. License: MIT
2. pathintegral-institute/mcpm.sh on GitHub
3. Project website
4. README
5. Releases