MCP Gateway & Registry: One Control Plane for MCP Servers, Agents and Skills

The problem: per-team MCP wiring with no shared inventory

The README's own before-and-after diagram is the clearest statement of scope. Before: each developer and each agent opens its own connections to MCP servers A through F, with multiple connections per user, no centralized control and credential sprawl. After: developers and agents connect once to the gateway, which fans out to servers, agents and skills.

The project is aimed at organizations where MCP adoption happened bottom-up. Teams wired their own servers by hand, credentials ended up in dotfiles, and nobody could answer which tools exist or who called what. The registry's answer is to make registration the act that creates visibility: a server, agent, skill or custom entity is registered once, discovered by natural-language search, and reached through the gateway, which enforces access and records calls.

The second problem is third-party OAuth MCP servers. The README describes per-user egress authentication for SaaS servers such as Slack, Atlassian and GitHub: each user connects an account once, the gateway runs the OAuth 3LO flow, vaults the per-user token in a secrets manager and injects it on egress. That removes per-laptop network plumbing, and it also concentrates risk in the gateway, which is the trade-off the design accepts.

Data plane versus control plane: how the request actually flows

The architecture is deliberately split. The gateway is the data plane: a generic nginx reverse proxy handling TLS, auth validation and routing to backends. The registry is the control plane: a FastAPI service that owns the inventory, the access model and the audit trail, and decides what the gateway may route to. An auth server integrates the identity provider (Keycloak, Entra ID, Okta, Auth0, Cognito or PingFederate) for OAuth2/OIDC, and MongoDB or DocumentDB stores configuration, embeddings, sessions and audit records.

The README's flowchart shows the wiring: humans over HTTPS, agents over MCP with auth, coding assistants over MCP with OAuth, all entering nginx, which calls the auth server through auth_request and reaches the registry API and UI. Backends can live anywhere: EKS, ECS, Lambda or SaaS.

One design point deserves attention because it changes what the gateway sees. According to the README, by default the registry handles A2A discovery, authentication and access control, and agents then communicate directly, peer-to-peer, rather than routing every call through the gateway. So the gateway is the front door for discovery and for MCP tool calls, but it is not necessarily in the path of agent-to-agent traffic. If your audit requirement covers every agent message, that default is the thing to read the full design doc about.

The Dockerfile confirms the data plane is not custom proxy code: it installs nginx and nginx-extras with lua-cjson, copies two nginx configurations (HTTP-only and HTTP+HTTPS), and creates /etc/nginx/lua/virtual_mappings. Routing logic lives in nginx configuration and Lua, not in a bespoke Python proxy.

Installing with Docker Compose and registering a first server

The repository ships docker-compose.yml plus docker-compose.prebuilt.yml and docker-compose.podman.yml variants. The compose file is explicit that it is for local development and that DocumentDB is the managed alternative: for an AWS DocumentDB Elastic Cluster you run scripts/init-documentdb.sh, then set STORAGE_BACKEND=documentdb in your environment and restart services.

Start by copying the environment sample. The .env.example file notes that HOST_BIND_IP defaults to 127.0.0.1 so datastores, the vault, admin consoles and backend MCP servers are reachable only from the host, and that only the nginx front door on ports 80 and 443 is always published on all interfaces.

cp .env.example .env
# REGISTRY_URL is the public URL, e.g. http://localhost
# HOST_BIND_IP defaults to 127.0.0.1; set 0.0.0.0 only for deliberate LAN access

The compose file includes a one-shot mongodb-keyfile-init service on alpine:3.21 that generates the replica-set keyfile before MongoDB starts and is idempotent, skipping if /keyfile/replica.key exists. MongoDB authentication is enabled with --auth, and the root user is created on first boot from DOCUMENTDB_USERNAME and DOCUMENTDB_PASSWORD, which the compose comments say must be set and have no default. Set both in .env before the first run.

A build-and-run script exists at the repository root (build_and_run.sh), alongside a Makefile and a Dockerfile based on python:3.14-slim. The README points at a Quick Start section and a published documentation site for the step-by-step flow; the exact command sequence for bringing the stack up is in those docs rather than in the README excerpt here. What you should see after startup is the registry UI behind the nginx front door, with the registry API reachable under the same origin.

Where it stops being the right tool

The heaviest constraint is the dependency set. The registry's pyproject.toml requires Python 3.14 or newer and pulls in torch, sentence-transformers, scikit-learn and huggingface-hub for the search path, plus langchain-core, langgraph, langchain-aws and strands-agents. The compose file notes that vector search is implemented in application code (see search_repository.py), not in MongoDB itself, which is why those libraries are present. This is not a small sidecar you drop next to an existing service; it is a Python application with a machine-learning dependency tree and a database behind it.

State is the second constraint. MongoDB or DocumentDB holds configuration, embeddings, sessions and audit records. That means backup, retention and access to the database become part of your MCP story, and the compose comments are blunt that binding HOST_BIND_IP to 0.0.0.0 exposes unauthenticated Mongo, the OpenBao root token and the auth bypass ports to anyone who can reach the host.

The third is identity. The auth server integrates Keycloak, Entra ID, Okta, Auth0, Cognito or PingFederate. If your organization's identity provider is not in that list, the OAuth path is the wrong assumption to build on, and the repository's pingfederate/ and keycloak/ directories show how much provider-specific configuration exists.

Finally, scope. If you have one MCP server and one user, the gateway adds nginx, an auth server, a database and a FastAPI registry between that user and that server. The README's own framing is about credential sprawl and missing inventory, and neither problem exists at that size.

How it differs from a plain MCP registry or a generic proxy

A registry alone answers "what exists." The MCP Gateway & Registry answers "what exists, who may reach it, and what did they call." The registry API is the control plane that decides what the gateway may route to, so discovery and enforcement are the same system rather than two systems kept in sync by hand. A standalone registry that only serves a catalog leaves the enforcement problem to whatever proxy you put in front of it, and the catalog and the policy can drift.

A generic reverse proxy is the other comparison. nginx with auth_request can front MCP servers, and that is literally half of this project. What nginx does not give you is the inventory, the per-user egress token vaulting for OAuth SaaS servers, or the audit records keyed to registered assets. The project's bet is that the control plane is the part worth building, and that the data plane should stay a generic proxy rather than become custom code. That bet is visible in the Dockerfile: nginx, nginx-extras, lua-cjson, and two configuration files.

The third contrast is asset type. The README states the project began as an MCP gateway and registry and grew into a general-purpose AI asset registry as teams registered agents, skills and custom entities alongside servers. A registry scoped only to MCP servers cannot share policy with agents, which is the exact split the README calls out as the problem it replaces.

Versions, licence and the upgrade surface

The licence is Apache-2.0, with a NOTICE file at the repository root. Apache-2.0 permits commercial use and modification and includes an explicit patent grant; it also requires that you preserve copyright and licence notices and state significant changes. That is the general shape of the licence, not advice about your situation, and the NOTICE file is the one to read if you redistribute.

On maintenance: the repository is not archived, and the last push was on 2026-09-09. Releases are frequent and versioned. Release 1.30.0, dated 2026-09-09, is titled "The Gateway for Any Resource: Inference, MCP, A2A, and REST." Release 1.29.0, dated 2026-08-13, covers "Reusable Egress Hardening & IdP-Authenticated Embeddings." Release 1.28.0, dated 2026-08-02, covers "Egress Auth Hardening, Configurable Token TTL, and Security Follow-ups." Two of the three most recent releases are security and egress hardening, which tells you where the project's attention has been.

The upgrade cost follows from the architecture. The release notes live in release-notes/ and each version has its own entry, so the changelog is the place to check before moving. Because the data plane is nginx configuration and the control plane is a Python service with pinned dependencies in pyproject.toml and uv.lock, upgrades touch both. The compose file pins alpine:3.21 with a comment that images are pinned rather than :latest so rebuilds cannot drift to an untested image; expect the same discipline to apply to the images you build.

Editorial conclusion

Adopt it if you already run more than a handful of MCP servers and need per-user OAuth egress, a shared inventory and an audit record in one place; the Docker Compose path and the .env.example loopback default make a local evaluation cheap. Skip it if you have one MCP server and one user, because you would be operating nginx, an auth server, MongoDB or DocumentDB, and a FastAPI registry to replace a single config file. Before committing, verify which identity provider you will integrate and that it appears in the auth server's supported list, confirm whether your deployment target is EKS, ECS or Compose, and check the registry's documented behavior for A2A discovery, since the README states agents then communicate peer-to-peer rather than through the gateway.

Frequently asked questions

Official sources

1. agentic-community/mcp-gateway-registry on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases