slm-mcp-hub

**Run every MCP server once. Reach them from every client through one local endpoint.**
SLM MCP Hub sits between your AI clients and your MCP servers: clients connect
to the hub, the hub connects to each backend once and shares it across every
session — adding governance, observability, and reliability on top. Part of
Qualixar's work on AI Reliability Engineering.
**Who it's for:** anyone running more than one MCP client (Claude Code, Cursor,
Windsurf, Claude Desktop, custom agents) against a shared set of servers — or
anyone whose machine is buckling under duplicate MCP subprocesses.
> **Alpha software.** The interfaces work and are tested — 2,306 tests at 98.54%
> line coverage, with the full transport matrix exercised against real
> processes — but they can still change between releases. Please file
> reproducible failures through
> GitHub Issues.
Why
Every AI client that speaks MCP spawns its own copy of every server it uses.
Run a few sessions and the math turns ugly fast:
The hub runs each backend once, multiplexes every client through a single
endpoint, and keeps memory bounded while your tools stay one call away.
Hub vs configuring servers in each client
| | Per-client config | With SLM MCP Hub |
|---|---|---|
| **Processes** | every client spawns every server | each server runs once, shared |
| **RAM** | grows with every session | bounded by spawn policy + LRU cap |
| **Server config** | duplicated in every client | one file, one place |
| **Adding a server** | edit every client by hand | slm-hub server add, hot-reloaded |
| **Health & metrics** | none | live state, p95 latency, and RAM per backend |
| **OAuth backends** | re-authorize in every client | authorize once, token in the OS keychain |
What you get
| | |
|---|---|
| **One connection, every backend** | Point a client at the hub once and reach every configured server through three meta-tools — no per-client server list to maintain. |
| **Shared process pool** | Backends start once and are shared across all client sessions instead of being re-spawned per session. |
| **RAM governance** | Lazy spawn, idle eviction, and an LRU cap on live backends keep memory bounded. Evicted backends stay discoverable and reconnect on the next call. |
| **Unified call pipeline** | Every call takes one path: a per-backend concurrency gate, per-server timeout classes, live progress forwarding, and p95 metrics on every dispatch. |
| **Every transport** | stdio, Streamable HTTP, SSE, and OAuth 2.0-protected HTTP backends, all behind one endpoint. |
| **Observability** | Live per-backend state, uptime, restarts, p95 latency, and RAM over REST, an SSE event stream, a localhost dashboard, and the CLI. |
| **Secure by default** | Loopback-only unless you set an API key; OAuth tokens in the OS keychain; secrets never land in logs or config. |
Install
Python 3.11 or newer.
Or via npm — the shim installs the matching Python release into an isolated
environment it owns:
The two packages are release-locked. Installation fails loudly rather than
falling back to a mismatched version or modifying an externally managed Python.
Two optional extras, both off by default:
Nothing else is pulled in. The hub talks to SuperLocalMemory over HTTP, so
[full] does not install a memory engine, a model runtime, or anything else you
did not ask for — see SuperLocalMemory below.
Quick start
The hub is now serving every imported backend at one endpoint:
- **HTTP:** http://127.0.0.1:52414/mcp
- **Health:** http://127.0.0.1:52414/api/health
- **Dashboard:** http://127.0.0.1:52414/
Point a client at it over native stdio:
Confirm what's connected:
Routing modes
**Federated** — one hub entry in your client config exposes three meta-tools
(search_tools, call_tool, list_servers) that reach everything. Best when
context size matters:
**Transparent** — each backend keeps its own route at /mcp/{server-name} with