# mcp-hub **Category:** πŸ’» Developer Tools **Repository:** https://github.com/ni-c/mcp-hub **Views:** 0 **Installs:** 0 **Upvotes:** 0 **Directory Page:** https://allmcps.com/mcp/mcp-hub ## Description Many stdio MCP servers from one container, published over HTTPS with OAuth 2.1 for any MCP client ## Claude Desktop Quick Installation Heuristic fallback β€” verify the package name and runner against the repository README before running it. Uses `npx` (confidence: low): ```json "mcpServers": { "mcp-hub": { "command": "npx", "args": ["-y","mcp-hub"] } } ``` ## Documentation & README # mcp-hub [![CI](https://img.shields.io/github/actions/workflow/status/ni-c/mcp-hub/ci.yml?branch=main&label=CI)](https://github.com/ni-c/mcp-hub/actions/workflows/ci.yml) [![OpenSSF Scorecard](https://api.scorecard.dev/projects/github.com/ni-c/mcp-hub/badge)](https://scorecard.dev/viewer/?uri=github.com/ni-c/mcp-hub) Socket supply-chain report [![Glama score](https://glama.ai/mcp/servers/ni-c/mcp-hub/badges/score.svg)](https://glama.ai/mcp/servers/ni-c/mcp-hub)
[![npm version](https://img.shields.io/npm/v/%40ni-c%2Fmcp-hub)](https://www.npmjs.com/package/@ni-c/mcp-hub) [![container image](https://img.shields.io/badge/ghcr.io-ni--c%2Fmcp--hub-4f46e5?logo=docker&logoColor=white)](https://github.com/ni-c/mcp-hub/pkgs/container/mcp-hub)
[![docs](https://img.shields.io/badge/docs-mcp--hub.ni--c.de-4f46e5?logo=readthedocs&logoColor=white)](https://mcp-hub.ni-c.de) [![sponsor](https://img.shields.io/badge/sponsor-ni--c-ea4aaa?logo=githubsponsors&logoColor=white)](https://github.com/sponsors/ni-c) A dual-era [Model Context Protocol](https://modelcontextprotocol.io) (MCP) gateway: it serves many stdio MCP servers from **one container**, published over HTTPS, and speaks **both MCP revisions on every endpoint** β€” `2026-07-28` and `2025-11-25`. The client picks, and cannot tell which one it is on from the answers. On the 2026 revision that includes **elicitation** β€” a child server's question reaches the person at the far end instead of dying at the gateway ([how](https://mcp-hub.ni-c.de/guide/elicitation)) β€” and **subscriptions**: the hub serves `subscriptions/listen` to its clients and subscribes to its children on whichever revision _they_ speak, so a server that has never heard of it still reaches a client that speaks nothing else ([how](https://mcp-hub.ni-c.de/guide/subscriptions)). Lets MCP clients that cannot spawn a local process β€” ChatGPT connectors, Claude on the Web and in Code, Mistral Le Chat, Cursor, LibreChat and any other Streamable-HTTP client β€” reach every server behind it, with a built-in OAuth 2.1 login protected by a single password, plus long-lived API tokens for clients that cannot do OAuth (OpenAI Responses API, xAI API, Gemini API). Per-client recipes: [client compatibility](https://mcp-hub.ni-c.de/guide/client-compatibility). MCP clients connect through a reverse proxy to mcp-hub: one Node process with an OAuth 2.1 authorization server, one path per server plus the /hub aggregate, and a supervisor keeping the stdio children and remote upstreams alive ![Demo: config in, hub up, servers reachable through one endpoint](https://mcp-hub.ni-c.de/demo.gif) **Want to poke at it first?** [`demo/`](https://github.com/ni-c/mcp-hub/blob/HEAD/demo/) is a throwaway hub with three fake servers β€” `docker compose up -d`, then point the [MCP Inspector](https://mcp-hub.ni-c.de/guide/demo#mcp-inspector) or [MCPJam](https://mcp-hub.ni-c.de/guide/demo#mcpjam) at it. Nothing to configure, nothing to clean up but a volume. ## Why Wrapping each stdio MCP server in its own auth-proxy container costs a full image, an OAuth stack, a hostname and a compose stack _per server_. mcp-hub replaces N containers with one process: - **Config is exactly Claude Code's `mcpServers` format** β€” copy entries 1:1. - **Path-based routing**: `https://host/paperless`, `https://host/homeassistant`, … - **`/hub` aggregate**: register a _single_ connector and reach every server through 6 meta-tools (`list_servers`, `list_tools`, `get_tool_schema`, `call_tool`, `wake_server`, `sleep_server`) without flooding the model context with NΓ—tools schemas. - **Per-server tool filtering**: `allowTools` / `denyTools` on any server decide which of its tools the hub exposes β€” exact names or `list_*` prefixes. A filtered tool is hidden from `tools/list` _and_ refused if a client calls it anyway, before the server is even woken, so a client holding a stale schema cannot reach it. - **Also without HTTP**: `mcp-hub --stdio` serves that same aggregate on stdin/stdout for clients that can only spawn a local process (Claude Desktop, Codex, …) β€” same `mcp.json`, no TLS, no reverse proxy, no login. Auth exists for the network endpoints; over stdio the trust boundary is the local user. - **On-demand lifecycle**: stdio and docker servers start when used and sleep after 60 idle minutes, answering `initialize`/`tools/list` from a persistent snapshot meanwhile β€” a dozen servers cost only the memory of the ones in use. `keepAlive: true` exempts a server, `IDLE_TIMEOUT_MINUTES=0` the hub. - **CIMD-first OAuth 2.1**: clients identify themselves with a [Client ID Metadata Document](https://mcp-hub.ni-c.de/guide/client-registration) β€” the registration-free path the MCP spec now prefers β€” including `private_key_jwt` against the keys in their own document (metadata-document clients only). RFC 7591 dynamic registration stays advertised beside it for older clients, `mcp-hub-admin clients add` issues credentials by hand for anything that can do neither, and `CLIENT_REGISTRATION` turns either mechanism off. - **OAuth outwards, too**: a remote server that speaks OAuth gets an `oauth` block instead of a static header. The hub registers itself β€” with credentials the upstream issued, via RFC 7591, or with its own client metadata document β€” then obtains and refreshes the token. `client_credentials` upstreams need no attention at all; where a person must sign in, `mcp-hub-admin upstream login` prints one URL. An upstream that needs re-authorizing shows up as one server `unauthorized`, not as a confusing 401 in your client. - **Supervision**: children are pinged and restarted with exponential backoff when they die. A down server answers 503, not silence; a crash-looping server nobody uses is parked instead of restarted forever. - **Hot reload**: edits to `mcp.json` start/stop/restart only the affected servers. - **Stateless Streamable HTTP**: no session state, so claude.ai's reconnect-without-DELETE behaviour cannot leak processes or memory. - **Dual-era**: every endpoint β€” `/hub`, `//mcp` and `--stdio` β€” answers MCP `2026-07-28` and `2025-11-25` alike; the client picks and cannot tell from the answers which it got. On the 2026 revision that includes **elicitation**: a server asking the user something returns the question rather than pushing it, so it reaches the person at the far end instead of dying at the gateway. The hub attributes it to the server that asked, strips what could lie about that, drops embedded sampling and roots requests, and seals the resumption state against the call it belongs to. `passthrough: "off"` withdraws one server's right to ask; [details](https://mcp-hub.ni-c.de/guide/elicitation). - **Change notifications, in both eras**: a client opens a `subscriptions/listen` stream and hears when a child's tools, prompts or resources change. The hub subscribes to each child the way that child understands β€” `subscriptions/listen` to a 2026 server, `resources/subscribe` to a 2025 one β€” so the era gap is the gateway's problem rather than either end's. The state is the open response, not a session table, so this costs the stateless design nothing. A sleeping server watches nothing and is told to re-read on waking; `subscriptions: "off"` withdraws one server's right to push; [details](https://mcp-hub.ni-c.de/guide/subscriptions). - **Lightweight by design**: one Node process, no database (state is one JSON file plus a signing key under `/data`), six runtime dependencies, and multi-arch images β€” a stated project goal is to run comfortably on a single-board computer like a Raspberry Pi. ## Servers to run behind it The hub is server-agnostic β€” it serves any stdio MCP server whose entry fits Claude Code's `mcpServers` format, which is most of them. These nineteen are built and maintained alongside it, so their documentation carries the hub entry you need and their tool filters line up with the hub's own `allowTools` / `denyTools`: | Server | npm | What it reaches | | ---------------------------------------------------------------------- | --------------------------------- | ------------------------------------------------------------------------------ | | [audiobookshelf-mcp](https://audiobookshelf-mcp.ni-c.de) | `audiobookshelf-mcp` | Audiobookshelf β€” libraries, listening progress, collections and playlists | | [caldav-mcp](https://caldav-mcp.ni-c.de) | `@ni-c/caldav-mcp` | CalDAV β€” events, tasks and journal entries on any server that speaks it | | [calibreweb-mcp](https://calibreweb-mcp.ni-c.de) | `calibreweb-mcp` | Calibre-Web β€” read-only library access through the OPDS feed | | [carddav-mcp](https://carddav-mcp.ni-c.de) | `@ni-c/carddav-mcp` | CardDAV β€” contacts, groups and photos on any server that speaks it | | [freshrss-mcp](https://freshrss-mcp.ni-c.de) | `@ni-c/freshrss-mcp` | FreshRSS β€” feeds, categories and articles as plain text, not stream ids | | [google-search-console-mcp](https://google-search-console-mcp.ni-c.de) | `@ni-c/google-search-console-mcp` | Google Search Console β€” properties, sitemaps, search analytics, URL inspection | | [healthchecks-mcp](https://healthchecks-mcp.ni-c.de) | `healthchecks-mcp` | Healthchecks β€” cron and uptime checks, and why one failed | | [hetzner-dns-mcp](https://hetzner-dns-mcp.ni-c.de) | `hetzner-dns-mcp` | Hetzner Cloud DNS β€” zones, record sets and BIND import/export | | [imap-mcp](https://imap-mcp.ni-c.de) | `@ni-c/imap-mcp` | IMAP mailboxes β€” read, search, organise and draft mail; it cannot send | | [linkwarden-mcp](https://linkwarden-mcp.ni-c.de) | `linkwarden-mcp` | Linkwarden β€” bookmarks, collections and the article text it preserved | | [mealie-mcp](https://mealie-mcp.ni-c.de) | `@ni-c/mealie-mcp` | Mealie β€” recipes, meal plans, shopping lists and cookbooks | | [ntfy-mcp](https://ntfy-mcp.ni-c.de) | `@ni-c/ntfy-mcp` | ntfy β€” publish and update notifications, manage users and topic access | | [opengist-mcp](https://opengist-mcp.ni-c.de) | `opengist-mcp` | Opengist β€” gists, revisions, commit history and raw files | | [osm-mcp](https://osm-mcp.ni-c.de) | `osm-mcp` | OpenStreetMap β€” geocoding, routing, isochrones and POI search | | [rustpad-mcp](https://rustpad-mcp.ni-c.de) | `rustpad-mcp` | Rustpad β€” collaborative pads edited through real OT, not overwrites | | [smtp-mcp](https://smtp-mcp.ni-c.de) | `@ni-c/smtp-mcp` | SMTP β€” sends mail, behind a recipient allowlist and a human confirmation | | [wg-easy-mcp](https://wg-easy-mcp.ni-c.de) | `wg-easy-mcp` | wg-easy v15+ β€” the full WireGuard client lifecycle | | [wikijs-mcp](https://wikijs-mcp.ni-c.de) | `@ni-c/wikijs-mcp` | Wiki.js β€” search, read and edit pages, plus assets, users and groups | | [woodpecker-ci-mcp](https://woodpecker-ci-mcp.ni-c.de) | `@ni-c/woodpecker-ci-mcp` | Woodpecker CI β€” repositories, pipelines, logs, secrets and crons | Each one runs perfectly well on its own over stdio. Put them behind the hub when you want them reachable from a client that cannot spawn a local process, or when you would rather register one connector than nineteen. ## Configuration `/config/mcp.json` β€” identical to Claude Code (`${VAR}` expands from the container environment; unknown fields are ignored by Claude Code, so the file stays interchangeable). Install stdio server binaries at a reviewed, exact version in your image; do not download mutable packages at runtime: ```json { "mcpServers": { "paperless": { "command": "paperless-mcp", "args": [], "env": { "PAPERLESS_API_TOKEN": "${PAPERLESS_API_TOKEN}" } }, "homeassistant": { "type": "http", "url": "http://homeassistant:8123/api/mcp", "headers": { "Authorization": "Bearer ${HA_TOKEN}" } }, "private-thing": { "command": "some-mcp", "args": [], "hub": false }, "paperless-readonly": { "command": "paperless-mcp", "allowTools": ["search_*", "get_document"], "denyTools": ["delete_document"] }, "untrusted": { "type": "docker", "image": "ghcr.io/example/untrusted-mcp@sha256:0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef", "network": "none", "memory": "256m" } } } ``` Stdio servers (`command`/`args`/`env`) are spawned as supervised child processes. Remote servers (`type: "http"` or `"sse"` with `url` and optional `headers`) are connected as MCP clients with the configured headers injected on every request β€” the same supervision (ping, backoff reconnect, hot reload) applies. An upstream that speaks OAuth gets an `oauth` block instead of a header: the hub registers itself (statically, via RFC 7591 or via a client metadata document), obtains the token and refreshes it, with one browser visit started from the admin CLI where the grant needs a person. `"hub": false` hides a server from the `/hub` aggregate; its own path keeps working. `allowTools` / `denyTools` cut finer and apply to every kind of server: a filtered tool is absent from both `tools/list` and `/hub`, and is refused if called anyway β€” before the server is woken. Reserved names: `mcp`, `hub`, `authorize`, `token`, `register`, `login`, `consent`, `health`, `livez`, `revoke`, `upstream`, `.well-known`. All stdio children share the hub's Unix user and can read its mounted files. Only install fully trusted stdio servers. A server with a different trust level belongs in its own container β€” and it does not have to speak HTTP to get there: - `type: "docker"` β€” the hub creates the container and talks **stdio across the container boundary** over the Docker API. No HTTP listener, no bearer token, no bridge process in the image. The hub itself never gets the Docker socket: a separate `mcp-hub-docker-proxy` container holds it and allows only the container operations `mcp.json` describes β€” nothing privileged, no host mounts, no other images. Credentials can live with the proxy (`secretsFrom`) so the hub process never holds them β€” and rotating one is just an edit: the proxy watches the file and recreates the sandbox with the new values. - `type: "unix"` / `"tcp"` β€” you start the container, the hub connects to a socket. Costs the hub no privileges at all, and a Unix socket reaches a sandbox running with `network_mode: none`. Both carry the newline-delimited JSON-RPC the specification asks custom transports to reuse. See [sandboxing](https://mcp-hub.ni-c.de/guide/sandboxing) and [SECURITY.md](https://github.com/ni-c/mcp-hub/blob/HEAD/SECURITY.md). For a custom image, pin every package to an exact version: ```dockerfile FROM ghcr.io/ni-c/mcp-hub:0.10.0 # pin @sha256: in production USER root RUN npm install -g your-mcp-package@1.2.3 USER node ``` ### Environment | Variable | Required | Description | | ------------------------------- | ------------------- | ----------------------------------------------------------------------------------------------------------------------------- | | `EXTERNAL_URL` | yes | Public base URL, e.g. `https://mcp.example.net` (no path) | | `PASSWORD_HASH` | one of | bcrypt hash of the login password (`htpasswd -bnBC 10 "" 'pw' \| tr -d ':\n'`) | | `PASSWORD` | one of | plain-text alternative to `PASSWORD_HASH` | | `TRUSTED_PROXIES` | no | comma-separated IPs/CIDRs allowed to set `X-Forwarded-*` (see below) | | `RESOURCE_BOUND_TOKENS` | no | RFC 8707 tokens bound to `/hub` or one `//mcp`, default `true`; set `false` only to keep pre-0.5 unbound tokens working | | `DEFAULT_RESOURCE` | no | server name (or `hub`) to bind tokens to when a client sends no `resource` parameter; unset β†’ such requests are refused | | `MCP_BODY_LIMIT` | no | authenticated MCP JSON body limit, default `1mb` | | `MCP_REQUESTS_PER_MINUTE` | no | limit per OAuth client, default `120` | | `MCP_MAX_CONCURRENT_REQUESTS` | no | in-flight request limit per OAuth client, default `4` | | `MCP_MAX_CONCURRENT_STREAMS` | no | open SSE listening streams per OAuth client β€” one per connected session, default `32` | | `HTTP_HEADERS_TIMEOUT_MS` | no | Node HTTP header timeout, default `10000` | | `HTTP_REQUEST_TIMEOUT_MS` | no | complete request timeout, default `310000` (slightly above the tool-call timeout) | | `PORT` | no | listen port (default 80 in the image, 3000 outside) | | `CONFIG_PATH` | no | default `/config/mcp.json` | | `DATA_PATH` | no | default `/data` | | `LOG_FILE` | no | additionally mirror all log output into this file, e.g. `/data/mcp-hub.log` (see below) | | `CLIENT_REGISTRATION` | no | which mechanisms a client may use for a `client_id`: `cimd`, `dcr` or both (default) | | `CIMD_ALLOWED_ORIGINS` | no | bare https origins whose metadata documents are accepted; unset β†’ any | | `CIMD_ALLOW_PRIVATE_ADDRESSES` | no | local development only; relaxes the SSRF guard, warns on every start | | `DCR_MAX_CLIENTS` | no | ceiling on stored dynamic registrations, default `500` | | `DCR_PENDING_TTL_HOURS` | no | how long a never-approved registration is kept, default `24` | | `DCR_INACTIVE_DAYS` | no | how long an unused approved registration is kept, default `90` | | `IDLE_TIMEOUT_MINUTES` | no | idle minutes before an on-demand server sleeps, default `60`; `0` disables it | | `TOOL_CACHE_PATH` | no | snapshots of sleeping servers, default `/tool-cache.json` | | `MCP_CALL_TIMEOUT_MS` | no | deadline for one forwarded tool call, default `300000` | | `MCP_RESET_TIMEOUT_ON_PROGRESS` | no | let progress notifications extend that deadline, default `false` | | `DOCKER_HOST` | with docker servers | the **policy proxy's** socket; a direct daemon socket fails closed | The full table, including what applies in stdio mode, is in the [environment reference](https://mcp-hub.ni-c.de/reference/environment). `/data` holds the Ed25519 JWT key, registered OAuth clients, approvals and refresh tokens. **Mount it as a volume** β€” recreating it invalidates every connector authorization. Every access token is bound to one resource. The OAuth client includes the resource advertised by the endpoint's RFC 9728 document β€” no client-side configuration needed β€” and the resulting token is valid only there: a token for `/paperless/mcp` cannot call `/hub`, `/health` or another server. The shorter `/` route is canonicalized to `//mcp`. `RESOURCE_BOUND_TOKENS=false` turns this off and is a migration mode for deployments from 0.4 and earlier, where tokens were issued without a resource and reach every path. The hub logs a warning while it is set. Removing it invalidates those unbound tokens, so every connector authorizes once more. `TRUSTED_PROXIES` decides what `req.ip` is, and therefore what the login rate limiter counts. List **only** your own reverse proxy, and make sure it _overwrites_ `X-Forwarded-For` rather than appending to it β€” otherwise a client can supply its own address and rotate it to sidestep the per-IP limit. If the variable is unset, every request appears to come from the proxy and per-IP limiting degrades to a single global counter (the hub logs a warning at startup). A global cap of 100 failures per 15 minutes applies either way. ## Running ### Option A β€” prebuilt image from GHCR (recommended) Published on every push to `main` and every `vX.Y.Z` release tag, for `linux/amd64` and `linux/arm64`. Browse the versions on the [package page](https://github.com/ni-c/mcp-hub/pkgs/container/mcp-hub). ```sh docker pull ghcr.io/ni-c/mcp-hub:0.10.0 ``` Tags: `latest` (tip of `main`), `X.Y.Z` and `X.Y` (releases), and `sha-` for a specific build. Use a version tag instead of `latest` for controlled updates. For an immutable deployment, record the resolved digest from `docker image inspect` and use `ghcr.io/ni-c/mcp-hub:@sha256:` in Compose. With compose, copy the example and point it at the image instead of building: ```yaml services: mcp-hub: image: ghcr.io/ni-c/mcp-hub:0.10.0 # replaces `build: .`; pin a digest in production # ...rest of docker-compose.example.yml unchanged ``` ```sh cp docker-compose.example.yml docker-compose.yml # adjust, swap build β†’ image mkdir -p config && cp mcp.json.example config/mcp.json # adjust mkdir -p data && sudo chown -R 1000:1000 data # container runs as uid 1000 docker compose up -d ``` Or without compose: ```sh mkdir -p data && sudo chown -R 1000:1000 data # container runs as uid 1000 docker run -d --name mcp-hub \ -p 127.0.0.1:7690:80 \ -e EXTERNAL_URL="https://mcp.example.net" \ -e PASSWORD_HASH="$(htpasswd -bnBC 10 '' 'yourpassword' | tr -d ':\n')" \ -e TRUSTED_PROXIES="192.168.1.0/24" \ -v "$PWD/config:/config:ro" \ -v "$PWD/data:/data" \ ghcr.io/ni-c/mcp-hub:0.10.0 ``` Update to a newer image with `docker compose pull && docker compose up -d` (or `docker pull …`, then recreate the container). ### Option B β€” build from source ```sh cp docker-compose.example.yml docker-compose.yml # adjust mkdir -p config && cp mcp.json.example config/mcp.json # adjust docker compose up -d --build ``` ### Option C β€” npm (without a container) ```sh CONFIG_PATH=./mcp.json DATA_PATH=./data PASSWORD_HASH='...' \ npx @ni-c/mcp-hub ``` Installs as [`@ni-c/mcp-hub`](https://www.npmjs.com/package/@ni-c/mcp-hub) (the unscoped npm name belongs to an unrelated project) and provides the `mcp-hub` and `mcp-hub-admin` binaries. The container remains the recommended deployment β€” it provides the isolation, read-only root filesystem and resource limits that SECURITY.md assumes. Reverse-proxy requirements: TLS termination, WebSockets/SSE allowed (proxy buffering off, a request timeout above 310 seconds, a request-body limit at or below `MCP_BODY_LIMIT`, and pass `X-Forwarded-Proto`/`Host`. Connect a client: add `https:///hub` (or `https:////mcp` for one server) as a custom connector β€” in ChatGPT (developer mode), Claude Web, Mistral Le Chat, Cursor, LibreChat or any other OAuth-capable MCP client β€” and log in once with the password. Claude Code: `claude mcp add -t http name https:////mcp`. API-only clients (OpenAI Responses API, xAI, Gemini API) use an admin-minted token instead β€” see [client compatibility](https://mcp-hub.ni-c.de/guide/client-compatibility). Each client is confirmed once. Entering the password approves the client that asked; while a login session is still valid, a client you have not seen before gets an explicit _Approve / Deny_ page instead of a code. Approved clients reconnect silently from then on. List clients or revoke one. The CLI shares `/data` with the running hub and both sides re-read the state file before they touch it, so this works against a live container β€” a revocation takes effect on the next request: ```sh docker exec mcp-hub node /app/dist/admin.js clients list docker exec mcp-hub node /app/dist/admin.js clients revoke CLIENT_ID docker exec mcp-hub node /app/dist/admin.js clients delete CLIENT_ID docker exec mcp-hub node /app/dist/admin.js clients prune --dry-run ``` Revocation removes the approval and all refresh tokens and immediately rejects already-issued access tokens. The next connection needs explicit approval. `delete` goes further and removes the registration itself, and `prune` applies the [registration lifecycle rules](https://mcp-hub.ni-c.de/guide/client-registration) on demand β€” registrations that were never approved expire after a day, unused ones after 90 days, and a dynamically registered client can also remove its own registration through RFC 7592. For clients that cannot do OAuth at all β€” the OpenAI Responses API, the xAI API, Gemini's `mcp_server` tool, plain-header clients β€” the same CLI mints long-lived, resource-bound API tokens: ```sh docker exec mcp-hub node /app/dist/admin.js tokens create --resource hub --days 90 --label "openai" docker exec mcp-hub node /app/dist/admin.js tokens list docker exec mcp-hub node /app/dist/admin.js tokens revoke TOKEN_ID ``` The token is printed once and never stored; `tokens revoke` takes effect immediately. Per-client recipes: [client compatibility](https://mcp-hub.ni-c.de/guide/client-compatibility). ## Endpoints | Path | Auth | Purpose | | -------------------------------------------------------------------- | -------------------------- | ----------------------------------------------------------------- | | `/`, `//mcp` | Bearer | Streamable HTTP endpoint of one server | | `/hub` | Bearer | aggregate endpoint with the 6 meta-tools | | `/livez` | none | minimal process liveness (`200`) | | `/health` | Bearer | per-server status (`200` all up / `503` degraded) | | `/authorize`, `/token`, `/register`, `/login`, `/consent`, `/revoke` | β€” | OAuth 2.1 Β· CIMD + DCR | | `/register/` | registration token | RFC 7592: a client reads, changes or removes its own registration | | `/upstream/callback` | signed state + hub session | where an upstream returns after `upstream login` | | `/.well-known/mcp-hub-client/.json` | none | the hub's own client metadata document, one per `cimd` upstream | | `/.well-known/oauth-authorization-server[/…]` | none | RFC 8414 metadata | | `/.well-known/oauth-protected-resource[/…]` | none | RFC 9728 metadata (path-scoped) | ## Notes & limitations - Change notifications (`listChanged`, resource updates) are carried on `2026-07-28` via `subscriptions/listen`, whose state is the open response rather than a session table. A `2025-11-25` client is offered neither, because that revision needs a channel the stateless transport does not keep β€” so the capability is withheld instead of announced and dropped. An on-demand server watches nothing while it sleeps; the subscription is re-established on the next wake and the client is told to re-read. - Elicitation travels end to end on `2026-07-28`: it is a result rather than a push. Sampling and log messages are not forwarded. - Access tokens are opaque and last 15 minutes. Revoking a client takes effect on its next request rather than when the token expires β€” the token is a reference to a stored record, so withdrawing it is a deletion. Refresh tokens rotate; replaying one that was already rotated away is treated as a leak and revokes the whole grant, access tokens included. - Upstream auth is fully decoupled from the hub's own OAuth: an expired upstream token just marks that one server `down` (503 on its path, visible in `/health`) β€” clients never see the upstream's 401. - One login can approve multiple connectors, but each token is valid only for its requested server or `/hub`. Registration remains open as the MCP specification intends; a client only receives codes after confirmation and only at the confirmed redirect target. - Failed logins are rate-limited (10/15 min per IP) and logged as `mcp-hub: authentication failure from ` for fail2ban. - Auth pages deny framing and carry a restrictive CSP. MCP bodies are parsed only after bearer verification and are bounded by size, per-client request rate and per-client concurrency. ### Logging to a file for fail2ban `LOG_FILE=/data/mcp-hub.log` mirrors every log line into that file, one line per entry with an ISO-8601 UTC prefix, while leaving the console output alone β€” so `docker logs` keeps working. A jail then reads the file directly: ```ini # /etc/fail2ban/filter.d/mcp-hub-auth.conf [Definition] failregex = mcp-hub: authentication failure from \s*$ mcp-hub: login rate limit exceeded from \s*$ mcp-hub: consent with an invalid CSRF token from \s*$ ignoreregex = ``` Only the hub's own lines are mirrored β€” the stdio children inherit stderr directly, so their output stays in the container log and the file stays small. Rotate it with logrotate (`copytruncate`, since the hub holds the file open). Why not read the container's own logs instead: the Docker `json-file` path contains the container ID and changes on every recreate, and the `journald` driver maps **all** stderr to priority `err` β€” since an MCP server must keep stdout free for the protocol and therefore logs to stderr, every ordinary line would show up as a system error and drown out host monitoring. Bans belong in the `DOCKER-USER` chain (`banaction = iptables-allports`) when the hub is published through a container-based reverse proxy: that traffic arrives via DNAT and `FORWARD`, and never passes `INPUT`. ## Development ```sh npm install npm test # vitest: config, OAuth flow, proxy E2E, hub, hot reload npm run dev # tsx, needs EXTERNAL_URL/PASSWORD/CONFIG_PATH/DATA_PATH ```