MCP Gateway Registry

What it is

MCP Gateway Registry is a control-plane layer for Model Context Protocol (MCP) servers. Instead of every AI agent or coding assistant maintaining its own list of MCP server endpoints, credentials, and trust assumptions, the Gateway sits in front of them: it authenticates requests (via Keycloak or Entra ID), discovers and catalogs available tools dynamically, and gives you a single audit trail for what agents are calling and why. Think of it as an API gateway pattern applied to the MCP ecosystem, addressing the sprawl problem that shows up once an org has more than a handful of MCP servers running across teams.

Who builds it and why

Contributor and founding-org details are not publicly available beyond the GitHub repo itself. What's visible: 54 contributors and a steady commit cadence through mid-2026, which suggests active multi-party development rather than a single-vendor side project. The Keycloak/Entra integration focus and "enterprise-ready" framing point to a project built by people dealing with real IAM and governance requirements in enterprise AI deployments, not a weekend prototype. No CNCF affiliation or foundation backing is publicly documented — this is an independent open-source project.

Production readiness signal

• 758 GitHub stars — moderate traction, not yet a dominant standard in the space.
• 54 contributors — healthy for a project this size, indicates it's not a single-maintainer bottleneck.
• Latest release 1.25.0 — a high minor version number suggests either frequent iterative releases or a versioning scheme that doesn't map cleanly to semver maturity; don't read "1.25" as "25 major iterations of stability."
• Recent commit activity confirms the project is actively maintained, not abandoned.
• No CNCF maturity level, no founding date public — you're evaluating this on repo signals alone, not third-party governance vetting.
• Apache-2.0 license removes legal friction for enterprise adoption.

Net: this looks like a real, actively developed project with enough contributors to survive a bus-factor problem, but it hasn't gone through the kind of external maturity assessment (CNCF sandbox/incubation, security audit disclosure, etc.) that would let you skip your own due diligence.

Who should use this

• Platform teams running multiple MCP servers across teams who need centralized auth instead of each server implementing its own.
• Organizations already standardized on Keycloak or Entra ID for identity, who want MCP tool access folded into existing IAM policy rather than bolted on separately.
• Teams building internal AI agent platforms that need audit logs for compliance — who called what tool, when, with what scope.
• Anyone currently duct-taping API keys and hardcoded endpoints into agent configs and wanting a governance layer before it becomes a security incident.

Who should NOT use this

• Small teams with 1-3 MCP servers and no IAM complexity — the operational overhead of running a gateway, registry, and OAuth integration will exceed the problem it solves.
• Anyone needing FedRAMP/SOC2-audited software today — with no public compliance certifications or CNCF vetting, you'll need to do your own security review from scratch.
• Teams without Keycloak or Entra already in place — standing up an IdP just to use this gateway inverts the cost-benefit.
• Organizations wanting a vendor-supported product with SLAs — this is community open source; support is whatever GitHub issues and contributor bandwidth give you.
• Anyone needing this to be a mature, widely-adopted standard right now — 758 stars is early-stage traction, not category-defining adoption.

Alternatives

• Kong / generic API gateways with custom MCP routing — mature, battle-tested gateway tech, but you build the MCP-specific discovery and tool cataloging yourself.
• Direct MCP server-to-agent connections with a secrets manager (Vault, AWS Secrets Manager) — simpler for small-scale setups, but no centralized audit or dynamic discovery.
• Custom-built internal proxy — many enterprises just write a thin auth proxy in front of MCP servers rather than adopt a dedicated registry project; more control, more maintenance burden.

Pricing

Fully open source under Apache-2.0. No paid tier, hosted offering, or commercial license mentioned in available data — self-host and self-support.