mcp server

mcp-gateway

Transform any HTTP endpoint into an MCP server. Aggregate multiple MCP servers, manage configuration profiles, and serve them through a unified gateway with multi-tenant isolation.

unrelated-ai/mcp-gatewaycommunitylistedunreviewednot running here yet

Use tool

Set up

Runs on your computer. Pick your agent and operating system.

This project does not publish an install method we can turn into a config. Follow the README instead.

README

synced Oct 14, 2026

MCP Gateway

Give AI applications safe access to existing APIs and MCP servers.

Turn REST/OpenAPI services and existing MCP servers into focused, secured MCP endpoints—without rebuilding every integration from scratch.

MCP Gateway sits between MCP clients and the systems they need to use:

Connect existing REST APIs, OpenAPI services, and MCP servers.
Combine tools from multiple systems behind one stable endpoint.
Create focused tool surfaces for different teams, environments, or agents.
Control access with API keys or OAuth, tool policies, limits, secrets, and audit logging.
Run locally with Docker or deploy to Kubernetes.

How it works

flowchart LR
  APIs["REST / OpenAPI"] --> Gateway["MCP Gateway"]
  Remote["Remote MCP servers"] --> Gateway
  Stdio["stdio MCP servers"] --> Adapter["Optional Adapter"]
  Adapter --> Gateway
  Gateway --> Profiles["Focused MCP endpoints"]
  Profiles --> Clients["MCP clients and AI applications"]

The Gateway can expose HTTP/OpenAPI tools directly and proxy remote MCP servers. The optional Adapter publishes local stdio MCP servers over streamable HTTP and can aggregate related systems before they reach the Gateway.

Each profile is a virtual MCP server with its own endpoint, tools, authentication, and policy. One deployment can serve a single developer or isolate many teams and environments.

When MCP Gateway is useful

Common uses include:

Give an MCP client access to an existing API without writing a bespoke MCP server.
Publish a local stdio MCP server over streamable HTTP.
Combine tools from several services into one MCP endpoint.
Expose different tools to development, production, or read-only clients.
Put authentication, quotas, timeouts, retries, and audit logging in front of MCP tools.
Isolate teams or projects without deploying a separate gateway for each one.

Version 1.0

Version 1.0 includes OAuth resource-server support, the unrelated client CLI with compact tool discovery, and stateful/sessionless upstream interoperability.

Upgrading from 0.x: The v1 migration guide covers configuration changes, database migration, and rollback for existing installations.

Try it locally

The quickest path uses published Docker images and does not require cloning this repository.

Prerequisite: Docker with Docker Compose.

Download the quickstart Compose file and shared image defaults:

curl -fsSL -o mcp-gateway-compose.yml \
  https://raw.githubusercontent.com/unrelated-ai/mcp-gateway/gateway-v1.0.0/docker-compose.quickstart.yml
curl -fsSL -o mcp-gateway-images.env \
  https://raw.githubusercontent.com/unrelated-ai/mcp-gateway/gateway-v1.0.0/deploy/images.env

Start the Gateway and Web UI:

GATEWAY_VERSION=1.0.0 UI_VERSION=1.0.0 \
  docker compose --env-file mcp-gateway-images.env -f mcp-gateway-compose.yml up -d

Open http://127.0.0.1:27102.

The onboarding flow creates the first tenant and starter profile. From there:

Add an HTTP/OpenAPI or MCP source.
Attach it to a profile.
Create an API key for the profile and save the secret shown once.
Copy the profile endpoint into an MCP client and send the key as Authorization: Bearer <API_KEY_SECRET> on every request.

Each profile is available at:

http://127.0.0.1:27100/<PROFILE_ID>/mcp

The quickstart starts with an empty database. Sources and profiles added through the UI persist across restarts in a named volume.

To stop or reset it:

docker compose --env-file mcp-gateway-images.env -f mcp-gateway-compose.yml down
docker compose --env-file mcp-gateway-images.env -f mcp-gateway-compose.yml down -v # also delete local data

Capabilities

Area	Capabilities
Sources	Manual HTTP tools, OpenAPI discovery, remote MCP, and stdio MCP through the Adapter
Endpoints	Streamable HTTP MCP endpoints with stable profile URLs
Tool control	Allowlists, renaming, defaults, parameter tuning, timeouts, retries, and quotas
Access control	API keys, optional OIDC/JWT, tenant isolation, and encrypted tenant secrets
Operations	Audit events, transport limits, health endpoints, CLI administration, and Web UI
Deployment	Docker Compose for local use and Helm charts for Kubernetes

Core concepts

Concept	Meaning
Gateway	The public-facing service that exposes secured profile endpoints and routes tool calls
Profile	A focused virtual MCP server with its own endpoint, sources, authentication, and policy
Tenant	An isolation boundary for profiles, secrets, and API keys
Source	An HTTP/OpenAPI tool source or upstream MCP server attached to a profile
Adapter	An optional service that exposes HTTP, OpenAPI, or stdio MCP sources as one remote MCP endpoint

Deployment options

Setup	Best for	Shape
Gateway only	A developer or small deployment exposing HTTP/OpenAPI tools	MCP clients → Gateway → APIs
Gateway with tenants	Multiple teams, projects, or environments	MCP clients → tenant profiles → isolated sources
Gateway with Adapters	Larger installations and existing stdio MCP servers	MCP clients → Gateway → private-network Adapters

The Gateway supports HA-friendly session routing through Gateway session tokens (Mcp-Session-Id). Adapters normally run close to the systems they expose, while the Gateway provides the public endpoint and shared policy layer.

Components

Gateway (unrelated-mcp-gateway): tenant/profile-based MCP routing, authentication, policy, limits, and audit logging.
Adapter (unrelated-mcp-adapter): expose HTTP, OpenAPI, or stdio MCP sources through one streamable HTTP MCP endpoint.
Web UI: tenant onboarding and management for sources, profiles, keys, secrets, audit, and settings.
Client CLI (unrelated): named profile contexts, login, tool search/calls, and a compact stdio MCP proxy.
Admin CLI (unrelated-gateway-admin): operator and automation workflows.
Gateway Operator: managed MCP deployment support for Kubernetes and Docker.

Documentation

Develop from source

Start the complete development stack:

make up

This starts Postgres, the migrator, Gateway, Web UI, example adapters, HTTPBin, and Petstore. Open the UI at http://127.0.0.1:27102.

Useful commands:

make help      # list available targets
make down      # stop the stack
make up-reset  # delete demo data; run make up afterward

For component-level development:

Run the Adapter with an example config: make adapter-run
Build the static Adapter binary: make build-release-adapter
Run the admin CLI: make cli-dev CLI_ARGS="--help"
Browse the commented example configurations in tests/fixtures/
See the Adapter testing guide

Images and release artifacts

Published container images:

ghcr.io/unrelated-ai/mcp-gateway
ghcr.io/unrelated-ai/mcp-gateway-migrator
ghcr.io/unrelated-ai/mcp-gateway-operator
ghcr.io/unrelated-ai/mcp-gateway-ui
ghcr.io/unrelated-ai/mcp-adapter

Stable releases use :latest and :X.Y.Z tags. Pre-releases use :X.Y.Z-rc.N. GitHub Releases also include static Linux Adapter and Gateway admin CLI binaries for x86_64-unknown-linux-musl under their respective release tags.

The published Adapter image contains a minimal static binary. For stdio MCP servers that require Node, Python, or other runtimes, copy that binary into a suitable runtime image. See the stdio server documentation.