MCP Server Hub / Gateway

- Centralized management of multiple MCP servers and hub-native tools.
- Dynamic configuration reloading without restarting the gateway.
- Namespaced tool exposure (serverId__toolName, hub__toolName).
- WebSocket-based communication between Gateway Client and Server.
- Configurable internal services that react to configuration changes.
- Supports optional SSE interface and configurable log levels.

Node.js (v20+ recommended)
npm
The underlying MCP servers you want to manage must be installed/accessible.

npm install
npm run build

{
  "mcpServers": {
    "thought-server": {
      "command": "node",
      "args": ["D:\\Projects\\mcp-thought-server\\build\\index.js"],
      "env": {},
      "autoRestart": true
    },
    "file-ops": {
      "command": "node",
      "args": ["D:/Projects/mcp-servers/Cline/MCP/file-operations-server/build/index.js"]
    }
    // Add entries for other managed MCP servers here...
  },
  "hubTools": {
    "example": {
      "description": "An example tool provided by the hub itself.",
      "modulePath": "./exampleHubTool.js", // Path relative to dist/tools/
      "handlerExport": "default", // Optional, defaults to 'default'
      "enabled": true // Optional, defaults to true
    }
    // Add entries for other hub-native tools here...
  },
  "exampleService": {
    "featureFlag": false,
    "messagePrefix": "INITIAL"
    // Add other settings specific to ExampleConfigurableService
  },
  "settings": {
    "logLevel": "info", // Optional: 'error', 'warn', 'info', 'debug'
    "wsPort": 8081,     // Port for Gateway Clients (WebSocket)
    "ssePort": null     // SSE interface port (null to disable)
  }
}

mcpServers: Defines external MCP servers managed by the hub.
Key: A unique serverId (used for tool namespacing, e.g., thought-server).
command, args, env, workingDir, autoRestart, maxRestarts: Standard process configuration.
hubTools: Defines tools implemented directly within this hub project (in src/tools/).
Key: The base name for the tool (e.g., example).
description: Tool description.
modulePath: Path to the compiled JS file (relative to dist/tools/).
handlerExport (Optional): Named export containing the tool handler function (defaults to default). The module should also export an inputSchema (Zod schema).
enabled (Optional): true or false (default: true).
exampleService: Configuration specific to the ExampleConfigurableService. Add sections here for other configurable hub services.
settings: General gateway settings.
wsPort: Port for the WebSocket interface used by the gateway-client.
logLevel: Logging verbosity.
ssePort: Port for the Server-Sent Events interface (if enabled).

Changes in mcpServers will cause the corresponding server process to be stopped/started/restarted.
Changes in hubTools will load/unload/reload the specified tool modules.
Changes in settings or service-specific sections (like exampleService) will trigger events that relevant components listen for.

Open a terminal in the project root directory (mcp-server-hub-server) and run:

Your LLM client only needs one MCP server configured: the gateway-client.
Add the following entry to your client's MCP server settings file (e.g., Cline's cline_mcp_settings.json), making sure to use the correct absolute path to this project:

When the LLM client connects to gateway-client, it will automatically start the client process (node dist/client/client.js`), which then connects to the already running Gateway Server via WebSocket.

Once the Gateway Server is running and your LLM Client is connected to the gateway-client:

List tools in your LLM Client. You should see namespaced tool names:
Managed server tools: serverId__toolName (e.g., thought-server__integratedThinking)
Hub-native tools: hub__toolName (e.g., hub__example)
Call tools using these full, namespaced names.

• Note: Due to dynamic configuration, the tool list might change over time. The gateway-client polls for updates periodically (default 5 minutes, configurable via CLIENT_TOOL_REFRESH_INTERVAL_MS env var for the client process). There might be a short delay between a server-side change and the client becoming aware of it. See docs/client-dynamic-tools-guide.md for details.