MCP Gateway & Registry: one nginx data plane and a FastAPI control plane for MCP servers and agents

The problem: per-developer 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 to one gateway, which fans out to the same set of servers. That is the whole pitch, and it is a real problem rather than a manufactured one. If four teams each register the same Atlassian MCP server with their own tokens, nobody can answer which servers exist, who can call them, or what was called last Tuesday. The registry answers the inventory question; the gateway answers the access question. The audience is platform or infrastructure engineers in organizations that have already accumulated more than a handful of MCP servers and now need a policy layer. A solo developer running one MCP server in a local config file is not the target, and the README does not pretend otherwise.

Two planes: nginx in front, FastAPI deciding what it may route to

The architecture splits cleanly. The gateway is the data plane, described in the README as 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 that decides what the gateway is allowed to route to. A separate auth server integrates the identity provider over OAuth2/OIDC, and MongoDB or DocumentDB stores configuration, embeddings, sessions, and audit records. The request path in the README's flowchart runs users, agents, and coding assistants over HTTPS or MCP into nginx, which calls the auth server via auth_request, and separately reaches the registry API and UI. Validated tokens are checked against the IdP, and nginx routes to backends that can live anywhere: EKS, ECS, Lambda, or a SaaS endpoint. One design decision deserves attention because it is easy to miss. By default the registry handles A2A discovery, authentication, and access control, and then agents talk to each other peer-to-peer instead of routing every call back through the gateway. That keeps the gateway off the hot path for agent-to-agent traffic, but it also means the audit trail covers discovery and authorization, not necessarily the content of every subsequent peer conversation. If your compliance requirement is full payload capture for agent traffic, this default is worth questioning before you build on it.

Per-user egress auth is the feature that changes SaaS onboarding

The most concrete capability in the README is per-user egress authentication, documented in docs/design/egress-auth-design.md. The scenario: an OAuth-protected SaaS MCP server such as Slack, Atlassian, or GitHub. Without the gateway, every user needs network access to that service and a credential on their laptop. With it, each user connects their account once, the gateway runs the OAuth 3LO flow, stores the per-user token in a secrets manager, and injects it on egress. The README frames the benefit as collapsing onboarding to a single auditable choke point. That is a specific mechanism, not a slogan, and it is the part of this project that is hardest to replicate with a plain reverse proxy, because a plain proxy has no notion of per-user upstream credentials. The release history backs the emphasis: 1.29.0 is titled Reusable Egress Hardening and IdP-Authenticated Embeddings, and 1.28.0 covers Egress Auth Hardening, Configurable Token TTL, and Security Follow-ups. Three consecutive releases touching egress auth suggests the area is still being tightened, which is normal for token-handling code and also a signal to read the release notes rather than assume the first version you deploy is the last word.

Getting it running: three deployment targets and what the README actually gives you

The README states the project runs on Kubernetes via Amazon EKS, on fully managed serverless via Amazon ECS, or on Docker Compose on Amazon EC2. It links a quick-start anchor and an AWS Workshop catalog entry as the guided path. The repository topics include terraform, ecs, ecs-fargate, mongodb, and documentdb, which is consistent with infrastructure-as-code being the intended route for the cloud targets rather than hand-built clusters. The README excerpt supplied here does not include the literal command lines, environment variable names, or config keys for the quick start, so I cannot give you exact commands without inventing them. What can be stated from the material: the auth server is configured against one of Keycloak, Entra ID, Okta, Auth0, Cognito, or PingFederate, and MongoDB or DocumentDB is a hard dependency for configuration, embeddings, sessions, and audit records. Those two choices dominate your setup effort. If your organization already runs one of the listed IdPs and has a MongoDB or DocumentDB instance, the integration surface is mostly configuration. If you run something else, the auth server is the piece you would have to extend, and the README does not describe a pluggable interface for arbitrary providers.

Where it stops being the right tool

The first limitation is structural: this is not a lightweight sidecar. You are adopting nginx, a FastAPI service, an auth server, an identity provider integration, and a document database. For a team with three MCP servers and ten developers, that is more moving parts than the problem justifies, and the failure modes multiply accordingly. The second is the peer-to-peer default for A2A traffic described above, which limits how much of the agent-to-agent conversation lands in the audit trail. The third is visible in the project's own history: the README is capped at 350 lines by CI, with feature announcements pushed to docs/overview/feature-release-highlights.md and design rationale to docs/design/theory-of-the-system.md. That is a deliberate documentation strategy, and it means the README alone will not tell you how a component behaves under load or what happens when a backend MCP server is unreachable. I found no statement in the supplied material about gateway behaviour during backend failure, about rate limiting, or about what the registry does when the secrets manager is unavailable. Those are the questions to ask in the issue tracker, not to assume an answer for. The fourth limitation is scope creep by design: the project now registers agents, skills, and any custom asset alongside MCP servers. A general asset registry is more useful than a narrow one, and also more surface area to configure and secure.

Compared with running MCP servers directly or behind plain API infrastructure

The obvious alternative is what most teams do today: point each client at each MCP server with its own token, possibly behind a conventional API gateway such as Kong or an ingress controller. The difference is not authentication, which a standard gateway handles well. It is discovery and inventory. A plain API gateway routes to endpoints you already know about; it has no concept of a searchable catalog of tools, agents, and skills, and no per-user upstream credential vault for third-party OAuth servers. That last point is the sharpest dividing line. If your MCP servers are all internal and all accept a single service token, a conventional gateway plus a wiki page gets you most of the way, and you avoid the database and auth-server dependencies. The moment you need per-user tokens for external SaaS MCP servers, or natural-language discovery across a catalog that changes weekly, the plain-gateway approach pushes that work back onto every developer's machine. The trade is real in both directions: this project buys governance with operational weight.

Maintenance cost, release cadence, and the Apache-2.0 terms

The release cadence is fast. 1.28.0 landed 2026-08-02, 1.29.0 on 2026-08-13, and 1.30.0 on 2026-09-09, with the last push timestamp matching the 1.30.0 release. Three minor releases in roughly five weeks means you should expect to track upgrades rather than pin and forget, particularly given that two of those three releases are explicitly security and hardening work on egress authentication and token TTL. Configurable token TTL appearing in 1.28.0 is the kind of setting that will interact with your IdP session policy, so plan to review it. The licence is Apache-2.0, which permits commercial use, modification, and redistribution provided you retain the licence and notices and comply with its patent and attribution terms. That is a permissive licence with no copyleft obligation on your own code, but I am describing the licence identifier as stated in the repository, not giving legal advice; if you are embedding this in a product, have counsel read the LICENSE file rather than this paragraph. The project is not archived, and the presence of a CI-enforced README budget and a written theory-of-the-system document suggests active, opinionated maintenance rather than a dump-and-run repository.

Editorial conclusion

Adopt it if you already run Keycloak, Entra ID, Okta, Auth0, Cognito or PingFederate and need one audited entry point for MCP servers plus agents, and if you can commit to the MongoDB or DocumentDB dependency. Do not adopt it if you want a single static MCP server behind one token, or if you cannot run the identity provider and database it assumes. Before committing, verify three things in the repository: whether the documented Docker Compose path is still the supported local route, how the auth server maps your IdP's groups and roles onto registry permissions, and what the registry does when a backend MCP server is unreachable, since the README does not describe that failure path.

Official sources

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