A
agentic-community/mcp-gateway-registry
MCP gateway and registry with OAuth
在 GitHub 查看 ↗链接已于 2026-11-12 核查 · 自动访问被拒(HTTP 429),状态未能确认
我们没有从该仓库取到可核对的安装命令,也没有公开的远端端点。这两样都没有时,我们不出配置——编一条出来比不给更糟。 各客户端的接法 →
- 来源明细
- 收录自 abordage/awesome-mcp 榜单(我们从中收集的条目之一) · 条目类型:MCP 服务
- 收录与活跃
- 收录于 2026-11-05 · 最近见到 2026-11-14 · 共见到 10 次 · 被 10 个来源列出
- 评分构成
- 综合分 1,003 · 10 个来源 · mcp
常见问题(答案都来自我们的记录)
它适合谁 / 用来做什么?
我们把它归在这些标签下: MCP 服务。标签来自条目自身,不是我们强加的分类。
谁维护它、还在更新吗?
我们收录于 2026-11-05;最近见到 2026-11-14。这里没有"官方认证"或"质量评级"——我们只记录来源与时间。
docs/overview/feature-release-highlights.md (top 3 mirrored here). Structure rat
以下摘录自该仓库的 README(片段) · 在 GitHub 读完整 README →
Unified Agent & MCP Server Registry – Gateway for AI Development Tools
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.
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.
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
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.
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.
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
收录徽章(可选)
想把收录标记放进 README 就复制这行,可选,不影响收录。
[](https://anclum.com/zh/s/agentic-community-mcp-gateway-registry/)
- 来源
- awesome · https://github.com/agentic-community/mcp-gateway-registry
- 按领域浏览
- MCP 服务
- 收录来源
- 10 个独立来源
- 收录于
- 今天
同类推荐
所属领域与标签
每个标签都能点进去看同类的全部条目。数字是当前库里的真实条数。