MCPHub

MCPHub is an open-source, self-hosted MCP gateway and control plane. It does not hand our agents new abilities; it puts order between the ones we already have: it aggregates scattered MCP servers behind one stable endpoint and controls access in the same place.

The project is released under the Apache 2.0 licence, runs on Node.js and starts with a single Docker command. Servers, groups, keys and logs are managed from the web dashboard.

What we use it for

• One endpoint, many servers. The /mcp endpoint serves every connected MCP server, so clients no longer need to know each server’s address and start command.
• Groups. We sort servers into logical groups and each group gets its own endpoint (/mcp/{group}), so an agent started for one task sees only the tools that matter to it.
• Single server routes. When only one server is needed, it is reachable on its own path (/mcp/{server}).
• Finding tools from a task. On the $smart endpoint the client does not list tool names, it describes what it wants to achieve, and the hub picks the relevant tools with vector semantic search.

How it is built

• Configuration. The server list lives in an mcp_settings.json file and is also editable in the dashboard. The config is hot-swappable, so servers can be added while the hub runs.
• Transports. stdio, SSE and streamable HTTP are all supported, which covers local and remote servers.
• Storage. File based by default; PostgreSQL mode is available for production, and the vector search uses the pgvector extension.
• Access. Local accounts with JWT and bcrypt, bearer keys and a built-in OAuth 2.0 server. GitHub and Google login require database mode.
• Per-user credentials. A shared server can be bound to separate credentials per user, with encrypted storage.

Running it

• Logs and observability. Tool call activity, request status and latency are visible in one place.
• Health checks. The hub also watches connection and server health.
• Large responses. Bulky text tool output can be compressed on the way to the client, so less of it reaches the context window.
• Containers. Two official images exist: the default one, and a fuller variant with a Rust toolchain, Docker Engine and Playwright browsers.
• Headless mode. The dashboard can be switched off, leaving only the backend and the MCP endpoints.

What to watch

• Smart routing needs extra components: PostgreSQL with pgvector and an embedding service. That is operational work in itself.
• MCP endpoints require authentication by default. Turning that off only makes sense on a trusted network.
• Self-hosting also means updates, backups and restores are our job.
• The project moves fast, so both the config file and the dashboard options can change between versions.

Where it fits in our stack

MCP provides the standard and MCPHub provides the shared entry point: tools connect here and agents pick them up here. Hermes Agent uses the same hub from the agent side, and we run the hub itself in a Docker container.

That gives us one place to see what each server can do, what each agent may reach, and a broken server no longer has to be fixed client by client.

Further reading

• MCPHub documentation - the official site, the starting point for every setting.
• Smart Routing - how the vector based tool selection works.
• MCPHub on GitHub - source, releases and the Apache 2.0 licence.

At CyberElectro we use MCPHub as the single way in to our local and server side MCP servers.