Name: MCP Front
Author: stainless-api

LABSCO SUMMARY

It solves the problem of authenticating eight times to prove you are the same person.

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.

What it is

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.

What you get

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

Requirements

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.

Setup effort

Build from source

See installation options

USE CASES

01

Letting a team use an internal database from Claude

Put the database's MCP server behind the gateway; each teammate signs in with their work account and gets their own subprocess.

02

Cutting eight logins down to one

Declare an aggregate server that fans out to your existing backends, and connect the client to that single endpoint.

03

Giving each person their own Notion or Linear token

Users connect the service once through a web page, and the gateway injects their token on every call after that.

04

Keeping a dangerous tool out of reach

Add it to the aggregate endpoint's block list so it never appears in the tool list the client sees.

BEFORE YOU INSTALL

What to know first

Requires

Go, to install mcp-front
npx on PATH, for the example filesystem server in config.json

INSTALLATION

Connect your client

MCP Clients

Claude Code

Save this as config.json

FILE · config.json

{
  "version": "v0.0.1-DEV_EDITION_EXPECT_CHANGES",
  "proxy": {
    "baseURL": "http://localhost:8080",
    "addr": ":8080"
  },
  "mcpServers": {
    "filesystem": {
      "transportType": "stdio",
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "/tmp"
      ],
      "serviceAuths": [
        {
          "type": "bearer",
          "tokens": [
            "dev-token-123"
          ]
        }
      ]
    }
  }
}

Start the gateway, then register it with Claude Code

In the folder with config.json, run go install github.com/stainless-api/mcp-front/cmd/mcp-front@main and then mcp-front -config config.json, and keep it running. The example backend runs through npx, so Node.js must be on the same machine (the Docker image has no Node.js in it). dev-token-123 is the bearer token from config.json; use your own string in both places.

CLAUDE CODE · TERMINAL

claude mcp add --transport sse --header "Authorization: Bearer dev-token-123" filesystem http://localhost:8080/filesystem/sse

MCP Front