The aggregate endpoint is the interesting part: instead of eight separate MCP servers each demanding their own login, one endpoint returns every backend's tools under prefixed names, with a per-user cache and a discovery timeout you set. The project describes itself as alpha and warns that breaking changes are expected, so pin the image tag and read the config schema rather than trusting the docs to be current.
An authentication gateway that sits between an MCP client and your internal MCP servers. The user signs in once through your identity provider, the gateway checks they belong to your organization, and proxies the connection to the real server inside your network.
- OAuth 2.0 with PKCE against Google, Azure AD, GitHub or any OIDC provider, plus bearer tokens for local development
- A separate isolated subprocess per user for stdio servers, so two people never share state
- Per-service audience claims, so a token minted for your Postgres server will not work against another service
- Per-user service credentials: a user connects Notion or Linear once through a web page, and the gateway injects the token from then on
- An opt-in aggregate endpoint that fans out to several backends and returns one tool list, with names prefixed by service so routing stays unambiguous
- AES-256-GCM encryption for sensitive data at rest, and optional Firestore persistence
Run it with `go install` or the published Docker image, pointing at a config.json that declares the proxy base URL and your `mcpServers` block. Production needs credentials from an identity provider; a local trial can use a static bearer token. Licensed under the Elastic License 2.0 — running it as infrastructure for your own service is permitted, offering it as a hosted product is not.
One command — go install github.com/stainless-api/mcp-front/cmd/mcp-front@main