MCP 网关

MCP Gateway 是一个 API 集成网关,通过将 REST/OpenAPI 服务和现有 MCP 服务器转换为安全、聚焦的 MCP 端点,使 AI 应用能够安全访问现有 API 与 MCP 服务。

  • by unrelated-ai
  • Rust
  • 混合部署
  • 26 星标
  • 更新于
在 GitHub 查看 unrelated-ai/mcp-gateway

使用说明

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.

Each profile exposes its own MCP endpoint, authentication mode, and set of tool sources.

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.1/docker-compose.quickstart.yml
curl -fsSL -o mcp-gateway-images.env \
  https://raw.githubusercontent.com/unrelated-ai/mcp-gateway/gateway-v1.0.1/deploy/images.env
  1. Start the Gateway and Web UI:
GATEWAY_VERSION=1.0.1 UI_VERSION=1.0.1 \
  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

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.

Project health

Project meta