MCP Gateway & Registry
A governed control plane for enterprise AI assets: consolidating scattered MCP servers, A2A agents, and skills behind one authenticated, auditable entry point.
Docs claim fine-grained scopes, fail-closed registration scanning, per-user egress credential vaulting (hvac dependency corroborates), and opt-out telemetry claimed free of PII; deductions: most security claims are link-only with no implementation code in this file set, user-confirmation mechanics for registration/proxy are asserted not shown; pyproject uses only lower-bound version constraints plus a git-pinned third-party dependency with no lockfile evidence; rollback/upgrade path appears only as an FAQ title; SECURITY.md routes reports to AWS while the repo belongs to agentic-community — attribution is muddled.
pyproject is carefully configured (coverage gate, bandit, mypy, ruff, explanatory pin comments) and CI uses least-privilege permissions with SHA-pinned actions — decent self-consistency; however pyproject says 0.1.0 while README advertises a 1.27–1.31 release cadence, and requires-python >=3.14 conflicts with ruff target py311; prebuilt images depend on ECR Public whose availability cannot be confirmed statically; error messages are only visible in test scripts, not the core service code.
README segments audiences (developer/platform/decision-maker) with clear entry points and covers EKS/ECS/Docker Compose/macOS — full marks justified; new features are consistently flagged off-by-default/opt-in, showing boundary awareness; but trigger semantics (when admin review happens, how scan failures surface) are not expanded in the evidence, and capability boundaries lean on linked assertions.
Information architecture is excellent: layered docs, CI-enforced README budget, explicit structure rationale; install docs (Quick Start, configuration reference, multi-platform guides) are complete; FAQ, demos and examples are rich; Apache-2.0 LICENSE text is present. Deductions: known limitations are barely stated and prose skews marketing; pyproject still reads 0.1.0, out of step with the release-notes system; the maintaining entity is ambiguous (agentic-community vs AWS reporting channel).
The unified gateway+registry+governance story addresses a real MCP tooling pain point with clear marginal value, plus four asset types, federation, and semantic search as differentiators; output usability (OpenAPI, CLI, UI) is documented; deductions: the deployment surface is complex (nginx+FastAPI+MongoDB+Keycloak+multiple images) and dependencies are very heavy (torch, the langchain stack), so cost/benefit for small teams is questionable, and effectiveness has no execution evidence.
Nearly every claim carries an in-repo path or design-doc link, and shipped vs roadmap work is clearly separated; deductions: docs cross-referencing docs is self-corroboration, third-party anchors (AWS workshop, pinned cisco scanner commit) cannot be verified in this file set, and no test results or audit reports substantiate the security/performance claims.
- Publisher identity is unverified; SECURITY.md routes vulnerability reports to AWS while the repository is under agentic-community — confirm the actual maintainer and support responsibility before adoption.
- Security claims (fail-closed gate, egress credential vaulting, audit masking) come from documentation only; no core implementation code or test results appear in this file set, so treat them as unverified.
- pyproject dependencies are almost entirely lower-bound with one git-pinned dependency; review the lockfile and dependency provenance before production use.
- Package version 0.1.0 is inconsistent with the 1.x release narrative in the README; requires-python >=3.14 is a very high floor that may limit deployable environments.
- The multi-service architecture (nginx, FastAPI, MongoDB, Keycloak, public ECR images) carries significant operational and attack surface; evaluate cost and exposure item by item before deploying.
What does this agent do, and when should you use it?
MCP Gateway & Registry (agentic-community/mcp-gateway-registry) is an open-source (Apache-2.0) enterprise MCP gateway and registry that unifies MCP servers, A2A agents, skills, and custom entities on a single governed control plane. Its data plane is an nginx reverse proxy handling TLS, auth validation, and backend routing; the control plane is a FastAPI-based Registry API + UI that owns the asset inventory, access model, and audit trail. An auth server integrates enterprise identity providers (Keycloak, Entra ID, Okta, Auth0, Cognito, PingFederate) for OAuth2/OIDC, and MongoDB/DocumentDB stores configuration, embeddings, sessions, and audit records. It offers semantic and lexical search, REST and MCP-native interfaces, plus security scanning with a fail-closed admission gate at registration. Deployment options include Amazon EKS (Helm), Amazon ECS (Terraform), and Docker Compose on EC2 or locally. It suits mid-to-large organizations that need centralized tool governance, compliance-grade auditing, and cross-team asset discovery.
The platform splits infrastructure into three tiers: an nginx reverse proxy as the data plane (TLS termination, auth_request validation, backend routing), a FastAPI Registry API + UI as the control plane (asset inventory, access model, audit logging), and an auth server integrating enterprise IdPs (Keycloak, Entra ID, Okta, Auth0, Cognito, PingFederate) via OAuth2/OIDC. Users register four built-in asset types: MCP servers, A2A agents (peer-to-peer by default, with an opt-in reverse-proxy mode), versioned SKILL.md skills (security-scanned at registration), and admin-defined schema-driven custom entities. Callers reach all backends with one gateway token; the gateway also acts as a generic AI gateway for any HTTP backend, including model inference (OpenAI, Amazon Bedrock, OpenAI-compatible endpoints), with credentials encrypted at rest and injected at egress (off by default). It provides per-user egress auth (3LO/OBO/PAT) to broker third-party SaaS MCP servers like Slack, Atlassian, and GitHub; virtual MCP servers aggregating multiple backends with per-tool access control; external-registry federation (Anthropic's MCP Registry, AWS Agent Registry); identity/group/target-aware application-level rate limiting with a quarantine kill switch; full audit logging with credential masking; and OpenTelemetry observability.
- A platform engineering team needs a single authenticated MCP entry point for multiple dev teams, eliminating per-laptop credential sprawl and hand-wired point-to-point configs.
- A security and compliance team requires a full attributable audit trail, fine-grained scopes, and an emergency quarantine switch for AI tool access.
- An agent development team wants A2A agents to discover each other by capability, and to register, version, and search SKILL.md skills inside a governed registry.
- An enterprise wants to onboard OAuth-protected third-party SaaS MCP servers (Slack, GitHub, Atlassian) with tokens vaulted centrally instead of scattered on laptops.
- An ops team needs a repeatable self-hosted gateway on EKS (Helm), ECS (Terraform), or Docker Compose, and uses the Terraform setup skill to have a coding assistant run deployments.
- A decision-maker evaluating consolidation of scattered MCP servers into one control plane can validate quickly via the executive brief, demo videos, and the AWS Workshop.
What are this agent's strengths and limitations?
- Separate data/control plane architecture (nginx + FastAPI) with uniform governance, access control, and auditing across four asset types: MCP servers, A2A agents, skills, and custom entities.
- Per-user egress auth (3LO/OBO/PAT) and a generic HTTP gateway: backend credentials stay encrypted in the registry and are injected at egress, giving a single auditable entry for OpenAI/Bedrock inference and SaaS servers.
- Flexible deployment and IdP ecosystem: EKS (Helm), ECS (Terraform), Docker Compose, and Keycloak, Entra ID, Okta, Auth0, Cognito, PingFederate.
- Concrete, verifiable security mechanisms: registration-time security scanning, fail-closed webhook admission gate, identity/group/target-aware rate limiting, quarantine kill switch, and audit logging with credential masking.
- Heavy deployment footprint: it requires MongoDB/DocumentDB, a dedicated auth server, and enterprise IdP integration; even the minimal path needs several secrets configured and Keycloak initialized, so it is not a lightweight trial.
- Key features — generic gateway proxy, rate limiting, A2A reverse-proxy mode — are off by default and require per-feature enablement and reading design docs, creating a large configuration surface.
- Deep AWS ecosystem coupling (EKS/ECS/Fargate/DocumentDB/ECR Public) means extra adaptation and ops effort in non-AWS environments.
- The registry collects anonymous telemetry (version, OS, cloud provider, aggregate asset counts) on by default; compliance-sensitive teams must proactively set MCP_TELEMETRY_DISABLED=1.
How do you install or deploy this agent?
The fastest path is pre-built Docker images:
git clone https://github.com/agentic-community/mcp-gateway-registry.git
cd mcp-gateway-registry
cp .env.example .env
# Edit .env and set required secrets (e.g. KEYCLOAK_ADMIN_PASSWORD, SECRET_KEY); full list in docs/configuration.md
nano .env
./build_and_run.sh --prebuilt
# Open the Registry UI (served by nginx on port 80)
open http://localhost # macOS (Linux: xdg-open http://localhost)Alternative deployments: Amazon ECS via the Terraform stack in terraform/aws-ecs/README.md; Amazon EKS via Helm charts in charts/README.md; the complete install guide (MongoDB and Keycloak initialization, first user and service account, registering a server, testing the gateway) is in docs/installation.md.
How do you use this agent?
After installation, open http://localhost for the Registry UI, then follow docs/installation.md to initialize MongoDB and Keycloak, create the first user and service account, register an MCP server, and test the gateway. Developers get programmatic access via the OpenAPI spec (api/openapi.), the Python registration client registry_client.py, and the CLI registry_management.py; AI coding assistants connect per docs/ai-coding-assistants-setup.md. The repo also ships a macOS setup skill (.claude/skills/macos-setup/SKILL.md) and a Terraform setup skill (.claude/skills/terraform-setup/SKILL.md) so a coding assistant can run setup or deployment end to end. Auth, scopes, and configuration details are in docs/auth.md, docs/scopes.md, and docs/configuration.md.
How does this agent compare with similar options?
The README positions the project as a replacement for the 'no control plane' status quo (per-team hand-wired MCP servers, credential sprawl, no audit) and supports federating external registries including Anthropic's MCP Registry and AWS Agent Registry; however, those appear in the source only as federation sources or problem statements, not as formal competitive comparisons.