MCPM: A Global Package Manager for MCP Servers, With Profiles and Routing
CLI MCP package manager & registry for all platforms and all clients. Search & configure MCP servers. Advanced Router & Profile features.
At a glance
- What is it?
- MCPM is a Python CLI that installs MCP servers once into a global configuration, tags them into profiles, and writes the resulting entries into client configs such as Claude Desktop and Cursor. The global-first model is a real simplification over per-client setup, but the registry it depends on is the project's own, and the README leaves several operational details unstated.
- Who is it for?
- Adopt MCPM if you run several MCP clients on one machine and are tired of editing each client's JSON by hand; the global install plus profile model is the point. Skip it if you only use one client with one or two servers, or if you cannot accept that server discovery runs through the project's own registry.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 24 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The Problem: MCP Server Configs Are Per-Client and Duplicated
Every MCP client keeps its own list of servers. Claude Desktop has one config file, Cursor another, Windsurf another, and so on through the list MCPM names: Vscode, Cline, Continue, Goose, 5ire, Roo Code, OpenCode. If you use three of them, the same server definition exists three times, and adding a fourth client means copying it again. The README frames MCPM v2.0 as replacing v1's target-based system with a global workspace model, and the tagline is explicit: install servers once, use everywhere. That is the whole pitch. The audience is engineers who already run more than one MCP-capable client on the same machine and want one place where a server is defined. It is not aimed at someone who has never configured an MCP server, and it is not a server runtime or a protocol implementation. MCPM manages configuration and lifecycle, not the servers themselves.
How the Global Configuration and Profile Model Fits Together
The architecture has three layers. The bottom layer is the global install: mcpm install SERVER_NAME pulls a server from the MCP Registry into a global configuration, and mcpm ls lists what is installed along with its profile assignments. The middle layer is profiles, described in the README as virtual tags that organize servers into logical groups for different workflows. A profile is not a copy of a server; mcpm profile rm PROFILE removes the profile and the README states that servers remain installed. The top layer is client integration: mcpm client edit CLIENT_NAME enables or disables servers for a specific client interactively, and mcpm client import CLIENT_NAME goes the other direction, pulling existing server configurations out of a client. Data flows from registry to global config, from global config into profiles, and from profiles or individual servers into client config files. Execution is separate from configuration: mcpm run SERVER_NAME executes over stdio, mcpm run SERVER_NAME --http executes over HTTP for testing, and mcpm profile run PROFILE does the same for every server in a profile. The share commands (mcpm share SERVER_NAME, mcpm profile share PROFILE) expose a server or profile through a tunnel for remote access, which is a different concern from local client wiring.
Installation and the Commands You Actually Type
The README recommends a shell installer: curl -sSL https://mcpm.sh/install | bash. It also points to brew, pipx and uv as alternatives, and the badges indicate the package is published on both Homebrew and PyPI under the name mcpm. Once installed, the working loop is short. mcpm search QUERY finds servers in the registry, mcpm info SERVER_NAME shows details, mcpm install SERVER_NAME adds one to the global configuration. mcpm ls shows what is installed. mcpm profile create PROFILE and mcpm profile edit PROFILE build groups, with edit described as interactive server selection. mcpm client ls lists supported clients and their status, which is the first command worth running because it tells you whether MCPM has found your client's config at all. mcpm edit SERVER_NAME changes a single server's configuration, and mcpm inspect SERVER_NAME launches MCP Inspector against it, which is the debugging path when a server installs but does not respond. The README also notes a non-interactive CLI mode and an llm.txt guide, aimed at agents driving the tool rather than humans.
Update Semantics Depend on Where the Server Came From
MCPM tracks server provenance (git repo, npm package, HTTP remote) and updates accordingly, but the three cases behave differently and the README is honest about it. Git-based servers are updated with git pull --ff-only by default, with --rebase available as an opt-in alternative. NPX and UVX servers auto-update at runtime, so mcpm update only shows them for informational purposes; running the command does not change them. mcpm update --check is a dry run that reports without applying. Two flags handle the case where provenance is missing or wrong: mcpm update --init scans servers and populates source metadata, and mcpm update --init --force re-detects all of it. This is the part of the tool most likely to surprise people. If you installed a server from a git checkout and then switched branches locally, a fast-forward pull will fail, and the README's answer is the --rebase flag rather than automatic conflict handling.
Where MCPM Is the Wrong Tool
Discovery runs through the project's own MCP Registry, and the README invites contributions to it directly. That means the catalogue is community-maintained and its coverage is whatever contributors have added. If the server you need is not in the registry, the search-and-install path does not help you, and you are back to editing client configs or using mcpm edit to hand-write an entry. The second limitation is scope: MCPM is a configuration manager. It does not sandbox servers, it does not proxy their traffic for inspection, and it does not decide whether a given server is safe to run. The share feature exposes a server through a tunnel, which is a network-facing action, and the README does not describe authentication or access control around it. Treat that as unverified rather than safe. Third, the README itself flags that the demo GIF shows outdated v1 commands, so anyone copying from the animation will type commands that no longer match the v2 CLI.
Against Editing Client Configs by Hand, or a Per-Client Wrapper
The realistic alternative is doing nothing: edit each client's config file directly, or keep a dotfiles-style symlink setup that points several clients at one shared file. That approach has no dependency, no registry, and no update semantics to learn. Its cost is exactly what MCPM targets: clients that do not share a config format, and the manual work of adding a server to each one. A second alternative is a thin wrapper script that writes the same JSON block into every client config. That is closer in spirit to MCPM but handles only the copying step. MCPM's difference is the middle layer. Profiles let you define a group once and run or share the whole group (mcpm profile run, mcpm profile share, mcpm profile inspect), and mcpm client import can pull existing per-client definitions back into the global store, which a copy script cannot do. If you never group servers and never run more than one client, the wrapper script and MCPM converge, and the script has fewer moving parts.
Maintenance, Licence and What the README Does Not Say
The project is MIT licensed, which permits commercial use, modification and redistribution provided the licence and copyright notice are preserved; that is a summary of the licence text, not legal advice, and you should read the LICENSE file in the repository for the binding terms. Release cadence visible in the material runs roughly every two months across v2.13.0, v2.14.0 and v2.15.0, with the most recent push in August 2026. The upgrade path is the same installer or package manager you used originally, and mcpm doctor exists as a diagnostic command, though the README excerpt cuts off inside its description so the checks it performs are not documented here. What the README does not cover: where the global configuration is stored on disk, how profiles are serialised, whether mcpm client edit rewrites client files in place or backs them up first, and what the usage analytics feature records or where that data goes. If any of those matter to you, read the source before installing, because the README as supplied does not answer them.
Editorial conclusion
Adopt MCPM if you run several MCP clients on one machine and are tired of editing each client's JSON by hand; the global install plus profile model is the point. Skip it if you only use one client with one or two servers, or if you cannot accept that server discovery runs through the project's own registry. Before committing, run mcpm doctor, run mcpm client ls to confirm your client is detected, and test mcpm update --check against a git-based server you care about.
Community notes