← Discover MCPs and Agents
m
MCPAI & MLGitHub

mcp-gateway-registry

Enterprise-ready MCP Gateway & Registry that centralizes AI development tools with secure OAuth authentication, dynamic tool discovery, and unified access for both autonomous AI agents and AI coding assistants. Transform scattered MCP server chaos into governed, auditable tool access with Keycloak/Entra integration.

Links

Repository

README

From the repo.

MCP Gateway & Registry Logo

Unified Agent & MCP Server Registry – Gateway for AI Development Tools

GitHub stars GitHub forks License GitHub release

Get Running Now | Docs | Executive Brief | Slide Deck | Demo Videos | AWS Workshop | Community

The MCP Gateway & Registry is a single, governed control plane for every AI asset in your organization, from MCP servers and AI agents to skills and any custom asset your teams build. It is open source, licensed under Apache 2.0, and runs on Kubernetes (Amazon EKS), fully managed serverless (Amazon ECS), or Docker Compose (Amazon EC2).

It began as a gateway and registry for the Model Context Protocol (MCP): one secure entry point to many MCP servers, with centralized discovery and governance. As teams started registering agents, skills, and other assets alongside their servers, it grew into a general-purpose AI asset registry on the same gateway, access-control, and audit model it started with.

Why we built this

Without a control plane, every team wires its own MCP servers and agents by hand: separate credentials in every dotfile, no shared inventory, no audit trail, and no way to discover or govern what exists. Agents can't find other agents; servers and agents live in separate registries that can't share policy.

This platform replaces that with one governed entry point for every AI asset. Register a server, agent, skill, or custom entity once; discover it by natural-language search; reach it through a single authenticated gateway that enforces access and records every call. One control plane, one access model, one audit trail, across all asset types.

┌─────────────────────────────────────┐     ┌──────────────────────────────────────────────────────┐
│          BEFORE: Chaos              │     │    AFTER: MCP Gateway & Registry                     │
├─────────────────────────────────────┤     ├──────────────────────────────────────────────────────┤
│                                     │     │                                                      │
│  Developer 1 ──┬──► MCP Server A    │     │  Developer 1 ──┐                  ┌─ MCP Server A    │
│                ├──► MCP Server B    │     │                │                  ├─ MCP Server B    │
│                └──► MCP Server C    │     │  Developer 2 ──┼──► MCP Gateway   │                  │
│                                     │     │                │    & Registry ───┼─ MCP Server C    │
│  Developer 2 ──┬──► MCP Server A    │ ──► │  AI Agent 1 ───┘         │        │                  │
│                ├──► MCP Server D    │     │                          │        ├─ AI Agent 1      │
│                └──► MCP Server E    │     │  AI Agent 2 ──────────────┤        ├─ AI Agent 2     │
│                                     │     │                          │        │                  │
│  AI Agent 1 ───┬──► MCP Server B    │     │  AI Agent 3 ──────────────┘        └─ AI Agent 3     │
│                ├──► MCP Server C    │     │                                                      │
│                └──► MCP Server F    │     │              Single Connection Point                 │
│                                     │     │                                                      │
│  ❌ Multiple connections per user  │     │         ✅ One gateway for all                      │
│  ❌ No centralized control         │     │         ✅ Unified server & agent access            │
│  ❌ Credential sprawl              │     │         ✅ Unified governance & audit trails        │
└─────────────────────────────────────┘     └──────────────────────────────────────────────────────┘

Onboard third-party OAuth MCP servers, the enterprise way. Because the gateway provides per-user egress authentication, you can connect OAuth-protected SaaS MCP servers such as Slack, Atlassian, and GitHub without every user setting up network access to those services or storing credentials on their laptop. Each user connects their account once; the gateway runs the OAuth (3LO) flow, vaults the per-user token in a secrets manager, and injects it on egress. That collapses onboarding to a single, auditable choke point, so a team can adopt a new SaaS MCP server across the enterprise without per-laptop plumbing or scattered long-lived tokens.

How it works

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

flowchart LR
    Users["Human Users"] -->|HTTPS| GW
    Agents["AI Agents"] -->|MCP / auth| GW
    Assistants["Coding Assistants"] -->|MCP / OAuth| GW
    subgraph GWBOX["MCP Gateway & Registry"]
        GW["nginx reverse proxy<br/>(data plane)"] -->|auth_request| Auth["Auth Server"]
        GW --> Reg["Registry API + UI<br/>(control plane)"]
    end
    Auth -.->|validate| IdP["Identity Provider"]
    GW -->|routes to| Servers["MCP Servers, Agents, Skills<br/>(anywhere: EKS / ECS / Lambda / SaaS)"]

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. For the full design and its invariants, read the Theory of the System; for layered diagrams, see Architecture Diagrams.

See it in action

Watch how MCP servers, A2A agents, and external registries work together for dynamic tool discovery:

https://github.com/user-attachments/assets/97c640db-f78b-4a6c-9662-894f975f66e2

More walkthroughs are in the demo videos.

Start here if you are a...

You are a...Start here
DeveloperStart with the Complete Setup Guide; you can also try the macOS setup skill to get it running on your MacBook. Then connect your AI coding assistant with the AI Coding Assistant Integration guide. For programmatic access, see the OpenAPI spec plus a Python registration client (registry_client.py) and CLI (registry_management.py).
Platform / security / ops teamSee the deployment guides for Amazon EKS (Helm), Amazon ECS (Terraform), and Docker Compose; the authentication guide; the configuration reference; and access control & scopes.
Decision-maker evaluating adoptionRead the Executive Brief, watch the demo videos, and try the AWS Workshop.

Quick Start

The fastest path is the pre-built Docker images. Clone, set a few secrets, and run:

git clone https://github.com/agentic-community/mcp-gateway-registry.git
cd mcp-gateway-registry
cp .env.example .env

# Edit .env and set the required secrets (e.g. KEYCLOAK_ADMIN_PASSWORD, SECRET_KEY).
# See docs/configuration.md for the full list.
nano .env

# Deploy with pre-built images (pulled from Amazon ECR Public by default)
./build_and_run.sh --prebuilt

# Open the Registry UI (served by nginx on port 80)
open http://localhost        # macOS  (Linux: xdg-open http://localhost)

The Complete Installation Guide has the full walkthrough for Amazon EC2 (prerequisites, MongoDB and Keycloak initialization, first user and service account, registering a server, and testing the gateway).

Deploying somewhere else?

What's in the box

The registry holds four built-in asset types plus admin-defined custom ones, all on one control plane:

  • MCP servers: register, discover, and govern access to MCP servers behind a single authenticated gateway.
  • Agents (A2A): register agents and let them discover each other by capability; by default agent-to-agent traffic runs peer-to-peer.
  • Skills: register, version, and discover reusable SKILL.md skills, with security scanning at registration.
  • Custom entities: admins define their own schema-driven entity types (n8n workflows, policies, prompt templates, model cards, and more); see Custom Entity Types.

Across all of them you get semantic + lexical search, UI, REST, and MCP-native interfaces, and uniform governance. Key features worth calling out:

  • Use it as an AI gateway for anything HTTP: one authenticated entry point in front of model inference (OpenAI, Amazon Bedrock, any OpenAI-compatible endpoint), MCP servers, A2A agents, and any generic REST endpoint. Callers hold a gateway token; the backend URL and its credential stay in the registry, encrypted at rest and injected at egress, with per-entity streaming and the same scopes, audit, and rate limits as everything else. Off by default. Design · FAQ: OpenAI and Bedrock
  • Single authenticated gateway: one entry point; OAuth against your existing IdP (Keycloak, Entra ID, Okta, Auth0, Cognito, PingFederate) with fine-grained scopes.
  • Dynamic tool discovery: agents and coding assistants find tools at runtime by natural-language semantic search, not hard-coded config.
  • Virtual MCP servers: aggregate tools from many backends behind one endpoint, with per-tool access control.
  • Per-user egress auth (3LO / OBO / PAT): the gateway brokers third-party SaaS credentials so tokens never live on a user's laptop.
  • Security scanning + fail-closed admission gate: every registered server, agent, and skill is scanned; unsafe items are held for review.
  • External-registry federation: pull in Anthropic's MCP Registry, AWS Agent Registry, and peer registries for one unified surface.
  • Audit logging: a full, attributable audit trail of access and admin events, with credential masking, for compliance and incident review.
  • Observability: OpenTelemetry metrics and health monitoring built in.

What's New

  • Backend Identity, Tool-Level Security, and a Faster Hot Path - Onboarding an MCP server that demands OAuth before it answers initialize no longer means parking a static bearer token on the record, where it served health checks, tool discovery, and security scanning alike with no way to scope it to discovery. Those are headless calls with no user behind them, so the registry had nothing else to present. One resolver picks at most one credential from three tiers: a machine client_credentials grant, a per-user OAuth 2.1 identity that an owner consents to once and the registry borrows from the vault, or the gateway's app-only token for obo_exchange servers. A person's own credential and the borrowed identity share a principal, a provider, and a server, so purpose forms part of the vault address and the codec binds it into the AEAD, which keeps the two apart even under a write-capable attacker. A borrowed identity lists tools and never calls one: tools/call never reaches the registry's Python, because nginx proxies it with the caller's own header. A scanner-flagged tool now carries its own block, so one false positive no longer costs the other tools on that server. A block beats admin and wildcard grants, reconciles on rescan so a stale block can clear, and hides the tool from every read projection. Search grades relevance where it used to return a flat 1.0, and in-app latency fell from 641ms to 86ms. Egress calls reuse pooled HTTP clients keyed on the SSRF-validated IP, which keeps pooling rebind-safe. 1.31.0 release notes · Authentication · OBO token exchange
  • Gateway for Any Resource — One AI Gateway for Inference, MCP, A2A, and REST - The gateway now fronts any HTTP backend, not only MCP servers, so a single authenticated entry point covers four kinds of traffic: model inference (OpenAI, Amazon Bedrock, or any OpenAI-compatible endpoint), MCP servers, A2A agents, and any generic REST endpoint registered as a custom entity. Callers hold one gateway token and reach everything through a registry URL; the backend URL and its credential stay in the registry, encrypted at rest and injected on egress, so no provider key ever lands on a laptop. Per record, each caller brings their own key (caller passthrough), which is the default and the right choice whenever a human is behind the request: the provider sees one client per user, so quota and billing stay attributable. A shared operator key is optional and meant for service-to-service traffic, where there is no end user to attribute. Per-entity response streaming carries SSE and AWS event-stream bodies incrementally, with bounded concurrency, byte, and duration ceilings, and every call goes through the same scopes, audit trail, and rate limits as the rest of the registry — a legacy methods: ["all"] grant authorizes no HTTP verb, so nothing gains access by accident. Off by default (GATEWAY_GENERIC_PROXY_ENABLED=false), per-entity opt-in, and no schema migration. Design · Operational Guide · FAQ: call OpenAI or Bedrock through the gateway · FAQ: what an upgrade changes
  • Reusable Egress Hardening & IdP-Authenticated Embeddings - One consolidated fail-closed SSRF/egress guard now governs every outbound fetch, with decrypted credentials bound to the exact validated destination, uniformly token-free response projection across the whole entity family, and AWS_EC2_METADATA_DISABLED=true closing boto3's IMDS credential fallback on the auth-server and registry tasks. Semantic-search embeddings can be served by an OpenAI-compatible endpoint (e.g. LiteLLM) protected by your IdP: set EMBEDDINGS_AUTH_MODE=idp and the registry fetches and caches an OAuth2 client-credentials token per call, with a raw_array adapter for non-envelope endpoints, plus Microsoft Entra v1 api:// scope pass-through. See the 1.29.0 release notes.
  • Configurable MCP Access-Token TTL - MCP access-token lifetimes are no longer hardcoded to 8 hours. Operators set a default via MCP_TOKEN_DEFAULT_TTL_HOURS and a hard ceiling via MCP_TOKEN_MAX_TTL_HOURS; a per-registration expires_in_hours is honored and clamped to the ceiling. The UI mint flows and the API both use the configured default, wired across Docker (including podman and prebuilt-image compose variants), Terraform/ECS, and Helm/EKS. See the 1.28.0 release notes.
  • Application-Level Rate Limiting - Identity/group/target-aware request limits enforced at the auth-server /validate hop, complementary to the coarse per-IP nginx edge limiting. Cap a caller (user or agent, by group membership), a target (MCP server / A2A agent), or each caller independently per target (the caller_target axis), each per time window, with config-time lockout-safeguard floors and a fail-open availability guardrail. A server group target applies the same cap to a named set of servers, each with its own independent bucket (per-member uniform, not pooled) so one definition covers many servers and members can be added or removed without new definitions. Includes quarantine (a kill switch): move a user, agent, or MCP server into an auto-seeded reserved group to drop all of its data-plane traffic instantly (a plain 403, not a throttle) — admin-only, from the Users / M2M rows and the Rate Limits panel, and admin-group users can never be quarantined (enforced server-side, fail-closed). Off by default; limits and quarantine are managed at runtime via the admin API / CLI / UI. Rate Limiting Design · FAQ: Quarantine a caller or target. Older highlights → Feature & Release Highlights · full per-version detail in the release notes and on the GitHub Releases page.

Roadmap

The roadmap is best tracked on the GitHub Milestones page. Per-user egress auth (3LO and OBO) and A2A traffic routing shipped in 1.27.0, the gateway for any HTTP resource in 1.30.0, and backend OAuth identity plus per-tool blocking in 1.31.0. At a high level, the big features we're working on next are:

  • Keycloak RFC 8693 token exchange for OBO (1.32.0): standards-based on-behalf-of exchange for Keycloak deployments, which today cannot use the OBO egress path or backend discovery because Keycloak binds the token audience with a server-side mapper rather than a request scope.
  • Client ID Metadata Documents for coding assistants: the registry publishes its own CIMD as of 1.31.0, currently shipping disabled. Next is the identity-provider side, so an assistant connects with the least friction across providers without a pre-registered client ID.
  • Registry Copilot: an embedded chat and agent-builder experience for discovering assets and composing agents from inside the registry. Tracked as #744; not yet scheduled to a release.

Have a feature request? Please open a GitHub issue, we build in the open.

Documentation

Full documentation is on the documentation site, and every guide also lives in the docs/ folder. Stuck or have a question? Start with the FAQ / Troubleshooting guide: it covers the most common setup, auth, deployment, and registration issues.

High-traffic pages by audience:

Get started

Platform & security

Architecture & development

Design decisions

Telemetry

The registry collects anonymous, non-sensitive usage telemetry (version, OS, cloud provider, aggregate asset counts) to understand adoption. It is opt-out and on by default; no PII, credentials, endpoints, or model names are ever sent. Disable everything with MCP_TELEMETRY_DISABLED=1. Full schema and privacy guarantees: Telemetry Documentation.

Community

Star History

Stars Forks Contributors

View the full interactive star-growth chart at star-history.com.

License

Licensed under the Apache-2.0 License. See LICENSE for details.

Collected info

  • ★ 933 stars
  • ⎇ 239 forks
  • Language: Python
  • Source updated: 9/19/2026

Config for your environment

Replace {MCP_ENDPOINT_URL} with this MCP’s endpoint URL (from its repo or docs above). No API key — you connect directly.

Tool

OS

Config file: ~/.cursor/mcp.json

{
  "mcpServers": {
    "mcp-server": {
      "url": "{MCP_ENDPOINT_URL}"
    }
  }
}

Paste into mcpServers in the config file. Restart Cursor after saving.

If this MCP is also published on mcpchannel.ai, you can subscribe from Browse and use the gateway config there instead.