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.

1. 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

1. 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

1. Open http://127.0.0.1:27102.

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

1. Add an HTTP/OpenAPI or MCP source.
2. Attach it to a profile.
3. Create an API key for the profile and save the secret shown once.
4. 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

Core concepts

Deployment options

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

• Documentation index
• Gateway
  • MCP proxying and aggregation
  • Data-plane authentication
  • MCP settings and trust controls
  • Audit logging
• Adapter
  • Manual HTTP tools
  • OpenAPI tools
  • stdio MCP servers
• Web UI
• Client CLI and compact proxy
• Gateway admin CLI
• Helm deployment
• CI/CD and releases
• Workspace layout

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.

Project health

Project meta

• Changelog
• Contributing
• Security policy
• Licensed under the MIT License