# mcpstore: A Rust Control Plane for Managing MCP Services

> mcpstore separates MCP orchestration from invocation and exposes services to CLI, Python, Rust and six agent frameworks. Here is what the repository documents, and where it stays thin.

**ip2a/mcpstore** — Elegantly manage your MCP services

- Repository: https://github.com/ip2a/mcpstore
- Website: https://ip2a.github.io/mcpstore/
- Stars: 432 · Forks: 32
- Language: Rust
- License: MIT
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/ip2a-mcpstore

## What mcpstore solves, and who ends up using it

Every MCP server you add to an agent is a small process with its own config, lifecycle and tool list. Once you have five of them, the problem stops being "which server" and becomes "which process is up, which config is current, and which agent sees which tools." mcpstore targets that second problem. The README frames it as "MCP management built with Rust," and the repository topics list mcp, mcp-client, mcp-hub, mcpstore and python, which is a fair summary of the surface: a hub that clients talk to, plus bindings for Python applications.

The audience is narrower than the tagline suggests. You need enough MCP servers that manual config files have become a liability, or you need the same tool set reachable from more than one agent framework. A solo developer running one stdio server inside one script is not the user this was built for.

## Control plane, data plane, and the scope model in between

The architecture the README describes mirrors Kubernetes: a control plane handles orchestration, a data plane focuses on invocation. The practical consequence is stated directly: on resource-constrained hosts you can attach only the data plane and call already-shared MCP services "with zero local maintenance." That is a deployment split, not a feature list. Orchestration and invocation can live on different machines.

Above that sits a scope model. `store.for_store()` operates on the global scope, while `store.for_agent(agent_id)` creates an independent scope per agent. Services added under one agent id do not appear under another, which is how you give agent1 a wiki server and agent2 a GitHub server without either seeing the other's tools. The Python example shows both forms: `add_service` accepts either an `mcpServers` wrapper with a `url`, or a flat object with `name`, `url`, or `name`, `command` and `args` for a stdio server such as `npx -y @modelcontextprotocol/server-github`.

What the README does not document is what happens to services already attached to an agent scope when that agent is renamed or removed. There is no rollback story, and no `list_agents()` behaviour beyond the method existing in the common API table.

## Installing mcpstore and adding a first service

Two install paths are given. The npm route installs a global command:

```bash
npm install -g ip2a@mcpstore
```

Alternatively the repository ships `install.sh`, fetched and piped to bash:

```bash
curl -fsSL https://raw.githubusercontent.com/ip2a/mcpstore/main/install.sh | bash
```

After either, `mcpstore` should be on your PATH. The README's CLI section shows the first real workflow: add a service by name and URL, list what exists, connect it, then remove it.

```bash
mcpstore add wiki https://example.com/mcp
mcpstore list
mcpstore connect wiki
mcpstore remove wiki
```

`mcpstore list` is the command to check first, because it tells you whether the add actually registered. To inspect local configuration or open the Web UI, the README gives `mcpstore config show` and `mcpstore web`. To expose an HTTP API instead of a terminal, run `mcpstore api --host 127.0.0.1 --port 1820`. Note that 1820 is the port the README uses; nothing states it is a default or that it is configurable.

If you prefer code, the Python SDK installs separately with `pip install mcpstore`, and the Rust crate with `cargo add mcpstore`. The Python quick start is three lines:

```python
from mcpstore import MCPStore

store = MCPStore.setup_store()
```

From there `store.for_store().add_service({...})` registers a server and `wait_service("mcpstore_wiki")` blocks until it is ready. The Rust equivalent uses `MCPStore::setup(None)`, `add_service` with `McpConfig::from_json_str`, and `wait_service(ServiceTarget::ServiceName("mcpstore_wiki"), Duration::from_secs(30))`.

## Where the framework adapters actually save work

The adapters are the most concrete part of the project. Instead of writing a separate tool-conversion layer per framework, you call one method on the scope:

```python
tools = store.for_store().for_langchain().list_tools()
```

The README lists the same pattern for LangGraph, OpenAI, AutoGen, CrewAI and LlamaIndex, changing only the middle segment (`for_langgraph()`, `for_openai()`, `for_autogen()`, `for_crewai()`, `for_llamaindex()`). The LangChain example then feeds those tools straight into `create_agent(model=llm, tools=tools, system_prompt=...)` and invokes it with a messages array.

This is where mcpstore earns its place in a codebase. Six frameworks, one registration path. The cost is that mcpstore sits between your agent and the MCP server, so a bug in the adapter surfaces as a missing or malformed tool rather than a connection error you can read directly.

## Limits, and the cases where mcpstore is the wrong layer

The desktop GUI is labelled Beta in the README, and downloads are pointed at GitHub Releases rather than a package manager. If you need a stable graphical surface for non-technical operators, that label matters.

More importantly, the README never documents failure semantics. There is no description of what `connect` does when the remote MCP endpoint is unreachable, whether `wait_service` returns an error or times out silently, or how a crashed stdio server is reported. The Rust example passes a 30-second `Duration` to `wait_service`, which implies a timeout exists, but the README does not say what happens after it expires.

The wrong-tool case is a single application with a single MCP server. Adding mcpstore there means running a separate process, learning a scope model and accepting an extra hop, all to manage a config file that fits in ten lines. Similarly, if your requirement is a curated catalogue of third-party MCP servers with ratings or discovery, mcpstore is not that: it manages servers you already know the address of. The related searches around "MCP server Marketplace" do not describe what this repository does.

## How mcpstore differs from hand-rolled MCP config files

The realistic alternative is not another manager. It is the per-client config file that each MCP host already reads, plus a shell script to restart things. That approach has real advantages: no extra process, no SDK, and the config is exactly what the host expects.

The difference in approach is lifecycle and sharing. A config file describes servers; mcpstore runs them, tracks state, and lets two agents hold different subsets of the same pool. `store.for_agent("agent1")` and `store.for_agent("agent2")` in the README each get their own `list_tools()` result, which a static config file cannot express without duplication. The control-plane split also lets a small host attach only the data plane and call services that live elsewhere, something no config file can do.

What you give up is transparency. With a config file, the failure mode is visible in the host's logs. With mcpstore, the failure is inside a Rust process with a documented API surface but undocumented error behaviour.

## Maintenance, releases and the MIT licence

The last push to the repository was on 2026-09-08, and the most recent release is v2.3.0 from 2026-08-28, preceded by v2.2.1 and v2.2.0 on 2026-08-27. The repository is not archived. Three releases inside two days followed by a push eleven days later is a burst pattern, not a steady cadence, so treat version numbers as a signal of recent activity rather than a stability guarantee.

Upgrade cost depends on which surface you use. The CLI and the npm package move together. The Python SDK on PyPI and the Rust crate on crates.io version independently, so a CLI upgrade does not automatically pull a matching SDK. The repository contains a `RELEASING.md` and `platforms.toml`, which suggests a defined release process, though the README does not describe cross-version compatibility between SDK and CLI.

The project is MIT licensed, which permits commercial use and modification provided the copyright notice and permission notice are retained. That is the standard reading of the licence text; it is not legal advice, and if you redistribute mcpstore inside a product, have counsel confirm the notice requirements.

## Conclusion

Adopt mcpstore if you already run several MCP servers and want one place to add, connect, restart and remove them, or if you need the same tool list in LangChain, LangGraph, OpenAI, AutoGen, CrewAI and LlamaIndex code. Skip it if you run a single local MCP server inside one application: the extra process and scope model buy you nothing there. Before committing, verify on your own host that `mcpstore add` works against the specific transport your server uses, that `mcpstore api --host 127.0.0.1 --port 1820` binds where you expect, and which scope your tools land in after `store.for_agent(...)`, because the README does not document rollback or scope migration.

## FAQ

### What is mcpstore and how does it work?

mcpstore is an MCP management tool built with Rust. Its README describes an architecture that mirrors Kubernetes, with a control plane for orchestration and a data plane for invocation, and it exposes MCP services through a CLI, a Python SDK, a Rust crate and framework adapters.

### What does MCP do exactly?

The README does not define the MCP protocol itself; it treats MCP servers as services with a URL or a stdio command and args. mcpstore's job is managing those services: adding, connecting, restarting and removing them, then exposing their tools to agent frameworks.

### How do I install mcpstore?

The README gives two paths: npm install -g ip2a@mcpstore, or curl -fsSL https://raw.githubusercontent.com/ip2a/mcpstore/main/install.sh | bash. The Python SDK installs with pip install mcpstore and the Rust crate with cargo add mcpstore.

### How do I add an MCP service with the mcpstore CLI?

Run mcpstore add wiki https://example.com/mcp, then mcpstore list to see registered services and mcpstore connect wiki to connect it. The README also shows mcpstore remove wiki to take it out again.

### Does mcpstore work with LangChain and other agent frameworks?

Yes. The README lists adapters for LangChain, LangGraph, OpenAI, AutoGen, CrewAI and LlamaIndex, each exposing the same list_tools() call on a scope, for example store.for_store().for_langchain().list_tools().

### Is the mcpstore desktop app stable?

The README labels the GUI as Beta and points downloads at GitHub Releases. It describes the GUI as the control plane for managing services and tools, inspecting parameters and trying invocations.

## Sources

- [ip2a/mcpstore on GitHub](https://github.com/ip2a/mcpstore)
- [License: MIT](https://github.com/ip2a/mcpstore/blob/main/LICENSE)
- [Project website](https://ip2a.github.io/mcpstore/)
- [README](https://github.com/ip2a/mcpstore/blob/main/README.md)
- [Releases](https://github.com/ip2a/mcpstore/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/ip2a-mcpstore