muxmcp

Transparent stdio MCP proxy that multiplexes one wrapped MCP server into multiple independent instances.

Why

Many MCP servers are inherently single-session: opening a second file clobbers the first. The radare2 MCP server is a typical example — it can analyze one binary at a time, which makes cross-referencing two binaries in the same conversation awkward.

muxmcp wraps any stdio MCP server and exposes it as a multi-instance service. The client gets a spawn_instance tool that returns an instance_id; every subsequent call is routed to the chosen instance.

Install

npm install -g muxmcp

Requires Node.js 18+. No runtime dependencies.

Usage

muxmcp -- <server-cmd> [server-args...]

Everything after -- is the wrapped server's command line. Example with the radare2 MCP server:

muxmcp -- r2-mcp

In your MCP client config (e.g. Claude Desktop), instead of pointing at r2-mcp directly, point at muxmcp with r2-mcp as the wrapped command:

{
  "mcpServers": {
    "r2": {
      "command": "muxmcp",
      "args": ["--", "r2-mcp"]
    }
  }
}

How it works

The proxy speaks MCP on its own stdio and spawns child processes of the wrapped server on demand. Each child gets its own initialize handshake, forwarded from the client's original init params.

Tools

The proxy exposes three additional tools:

• spawn_instance — start a new instance, returns {instance_id: N}
• kill_instance(instance_id) — terminate an instance
• list_instances — list live instance IDs

Every upstream tool is exposed with an injected required instance_id parameter. Calls without it are rejected.

Resources

resources/list and resources/templates/list are aggregated across all live instances. URIs are rewritten as mux://<instance_id>/<urlencoded-original> so that resources/read can route back to the right instance.

Prompts

prompts/list aggregates across instances; names are rewritten as i<instance_id>__<original>. prompts/get decodes and routes.

Capabilities

The proxy advertises only the capabilities the wrapped server actually supports (discovered from the template instance's initialize response). Wrapping a tools-only server still results in a tools-only proxy.

Limitations

v1 deliberately does not implement:

• Sampling (server → client LLM completions). Almost no servers use it; the routing is bidirectional and would add real complexity.
• Resource subscriptions (resources/subscribe / unsubscribe and the corresponding change notifications).
• Server-initiated logging (notifications/message).
• Crash recovery — if a child dies, its instance is gone; no auto-respawn.

If you hit a server where any of these matter, open an issue.

License

MIT