AgentStack
MCP verified Apache-2.0 Self-run

Mcp Gateway Registry

mcp-agentic-community-mcp-gateway-registry · by agentic-community

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.

No reviews yet
0 installs
11 views
0.0% view→install

Install

$ agentstack add mcp-agentic-community-mcp-gateway-registry

✓ scanned · ✓ verified — works with Claude Code, Cursor, and more.

Security review

✓ Passed

No issues found. Passed automated security review. · v0.1.0 How review works →

  • Prompt-injection patterns
  • Secret / credential exfiltration
  • Dangerous shell & filesystem operations
  • Untrusted network calls
  • Known-malicious package signatures

What it can access

  • Network access Used
  • Filesystem access No
  • Shell / process execution Used
  • Environment & secrets Used
  • Dynamic code execution No

From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.

Are you the author of Mcp Gateway Registry? Claim this listing to set pricing, connect Stripe payouts, and keep 70% of every sale.
Sign up to claim

About

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

[](https://github.com/agentic-community/mcp-gateway-registry/stargazers) [](https://github.com/agentic-community/mcp-gateway-registry/network) [](https://github.com/agentic-community/mcp-gateway-registry/issues) [](https://github.com/agentic-community/mcp-gateway-registry/blob/main/LICENSE) [](https://github.com/agentic-community/mcp-gateway-registry/releases)

[🚀 Get Running Now](#option-a-pre-built-images-instant-setup) | [macOS Setup Skill](.claude/skills/macos-setup/SKILL.md) | AWS Workshop Studio | [AWS Deployment](terraform/aws-ecs/README.md) | [Quick Start](#quick-start) | [Documentation](docs/) | [Community](#community)

Demo Videos: 📺 [All Demo Videos](docs/demo-videos.md) | 🎥 AWS Show & Tell | ⭐ MCP Registry CLI Demo | Full End-to-End Functionality | OAuth 3-Legged Authentication | Dynamic Tool Discovery | Agent Skills | Virtual MCP Servers | [Slide Deck](docs/slides/mcp-gateway-registry-presentation.pdf)


What is MCP Gateway & Registry?

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 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, while keeping the same gateway, access control, and audit model it started with.

Today it serves these core functions:

  1. Unified MCP Server Gateway – Centralized access point for multiple MCP servers
  2. MCP Servers Registry – Register, discover, and manage access to MCP servers with unified governance
  3. Agent Registry & A2A Communication Hub – Agent registration, discovery, governance, and direct agent-to-agent communication through the A2A (Agent-to-Agent) Protocol
  4. Skills Registry – Register, version, and discover reusable AI skills (SKILL.md) with security scanning
  5. Custom Entity Registry – Administrators define their own entity types with custom schemas, so the registry can hold any AI asset: n8n workflows, policies, prompt templates, model cards, datasets, evaluations, and more

Every asset type, built-in or custom, shares the same control plane: schema-driven registration, semantic and lexical search, discovery APIs, voting, registry cards, and one access-control and audit model. The platform also integrates with external registries such as Anthropic's MCP Registry (and more to come), giving you a single surface for tool access, agent orchestration, and agent-to-agent communication.

Why unified? Instead of managing hundreds of individual MCP server configurations, agent connections, and separate governance systems across your teams, this platform provides secure, governed access to every curated AI asset through one control plane.

Transform this chaos:

❌ AI agents require separate connections to each MCP server
❌ Each developer configures VS Code, Cursor, Claude Code individually
❌ Developers must install and manage MCP servers locally
❌ No standard authentication flow for enterprise tools
❌ Scattered API keys and credentials across tools
❌ No visibility into what tools teams are using
❌ Security risks from unmanaged tool sprawl
❌ No dynamic tool discovery for autonomous agents
❌ No curated tool catalog for multi-tenant environments
❌ A2A provides agent cards but no way for agents to discover other agents
❌ Maintaining separate MCP server and agent registries is a non-starter for governance
❌ Impossible to maintain unified policies across server and agent access

Into this organized approach:

✅ AI agents connect to one gateway, access multiple MCP servers
✅ Single configuration point for VS Code, Cursor, Claude Code
✅ Central IT manages cloud-hosted MCP infrastructure via streamable HTTP
✅ Developers use standard OAuth 2LO/3LO flows for enterprise MCP servers
✅ Centralized credential management with secure vault integration
✅ Complete visibility and audit trail for all tool usage
✅ Security features with governed tool access
✅ Dynamic tool discovery and invocation for autonomous workflows
✅ Registry provides discoverable, curated MCP servers for multi-tenant use
✅ Agents can discover and communicate with other agents through unified Agent Registry
✅ Single control plane for both MCP servers and agent governance
✅ Unified policies and audit trails for both server and agent access
┌─────────────────────────────────────┐     ┌──────────────────────────────────────────────────────┐
│          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        │
└─────────────────────────────────────┘     └──────────────────────────────────────────────────────┘

> Note on Agent-to-Agent Communication: AI Agents discover other AI Agents through the unified Agent Registry and communicate with them directly (peer-to-peer) without routing through the MCP Gateway. The Registry handles discovery, authentication, and access control, while agents maintain direct connections for efficient, low-latency communication.

Unified Agent & Server Registry

This platform serves as a comprehensive, unified registry supporting:

  • MCP Server Registration & Discovery – Register, discover, and manage access to MCP servers
  • AI Agent Registration & Discovery – Register agents and enable them to discover other agents
  • Agent-to-Agent (A2A) Communication – Direct agent-to-agent communication patterns using the A2A protocol
  • Multi-Protocol Support – Support for various agent communication protocols and patterns
  • Unified Governance – Single policy and access control system for both agents and servers
  • Cross-Protocol Agent Discovery – Agents can discover each other regardless of implementation
  • Integrated External Registries – Connect with Anthropic's MCP Registry and other external sources
  • Agent Cards & Metadata – Rich metadata for agent capabilities, skills, and authentication schemes

Key distinction: Unlike separate point solutions, this unified registry eliminates the need to maintain separate MCP server and agent systems, providing a single control plane for agent orchestration, MCP server access, and agent-to-agent communication.

MCP Servers, Agents and Skills Registry

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


MCP Tools in Action

[View MCP Tools Demo](docs/img/MCP_tools.gif)


MCP Registry CLI

Interactive terminal interface for chatting with AI models and discovering MCP tools in natural language. Talk to the registry using a Claude Code-like conversational interface with real-time token status, cost tracking, and AI model selection.

Quick Start: registry --url https://mcpgateway.ddns.net | [Full Guide](docs/mcp-registry-cli.md)


What's New

  • Agentic Resource Discovery (ARD) — full spec support - The registry implements the ARD v1.0 spec end to end as a Publisher, a Registry, and a federating peer, so any ARD-aware client or registry can discover, search, and cross-reference its assets through vendor-neutral interfaces. Publish: a public /.well-known/ai-catalog.json renders every public MCP server, A2A agent, and skill as a conformant ARD catalogEntry (domain-anchored URNs, per-asset IANA media types, https trustManifest). Serve: POST /api/ard/search + GET /api/ard/agents expose hybrid semantic search/browse over the ARD contract — JWT-required, access-scoped, paginated, with the ARD {errorCode, message} envelope. Federate: ingest other registries' ai-catalog.json catalogs (servers, agents, skills) into a unified index and honor federation=none|auto|referrals on search; ingestion is SSRF-guarded (https-only, post-DNS private/metadata-IP block, same-domain recursion, streamed 5 MB cap) with domain-anchored trust that anchors each entry's URN to the configured source. Discovered assets are read-only, never re-published, and link back to the source descriptor ("view at source") in the UI and search results. Off by default; managed via Settings → Federation and the ard-* CLI commands. (#1294, #1295, #1296, #1318, #1336) [ARD Guide](docs/ard.md)
  • Self-Service Asset Lifecycle Workflow - A sample workflow customers can follow so users can self-register MCP servers, agents, and skills while still requiring approval before assets become discoverable. New assets land in draft, a regular user can register but cannot promote, and an admin or an automated CI/CD pipeline approves (human-in-the-loop and/or automation) before an asset goes active. Built from existing primitives (a group scope, an enforced initial status, optional signed webhooks, and the lifecycle status API). [Self-Service Lifecycle Workflow](docs/faq/self-service-asset-lifecycle-workflow.md)
  • File Storage Backend and FAISS Search Removed (Breaking Change) - The legacy file-based storage backend and its in-memory FAISS vector search engine have been removed. DocumentDB / MongoDB is now the only storage backend and the only semantic search engine, which simplifies the codebase (a single storage path, no backend-selection branching) and drops the faiss-cpu native dependency. The legacy scopes.yml authorization file is also removed: scopes now live exclusively in the mcp_scopes collection, seeded from JSON files in scripts/ at init time and managed via the scope API. STORAGE_BACKEND=file is now rejected at startup with a migration message; the default is mongodb-ce. Existing file-backend deployments must move to a MongoDB-compatible backend and run [scripts/migrate-file-to-mongodb.py](scripts/migrate-file-to-mongodb.py) (migrates servers, agents, federation config, and peer state; security scans are regenerable and not migrated). torch and sentence-transformers are retained, as they power the default DocumentDB embeddings provider. (#452, #1285, #1292) [Storage Architecture](docs/design/storage-architecture-mongodb-documentdb.md)
  • A2A Agent Card Sync (Pull Card) - One-click "Pull Card" on owned A2A agents in the UI (and agent-pull-card in the CLI) fetches /.well-known/agent-card.json from the remote, shows a field-by-field diff, and applies only A2A-spec fields — registry-managed metadata (tags, ratings, visibility, trustlevel, syncmetadata) is never overwritten. Dry-run by default, with a 1 MiB remote-read cap and a registrant-only safety check. (#1030, #1263)
  • Custom Entity Types - Define your own schema-driven catalog types at runtime, beyond the built-in servers/agents/skills. A registry admin defines a custom TYPE once (programmatically, via POST /api/custom-types) with a name and a list of typed fields (string, text, number, bool, enum, date, array, each optionally required, semantic, or show_in_list); then any authenticated user creates RECORDS of that type either programmatically (POST /api/custom/{type}) or through a dynamically-rendered UI tab with a schema-driven form. Records get lexical + semantic search (fields marked semantic feed the embedding), star ratings, group-restricted visibility, a Copy-JSON detail view, client-side pagination, and inclusion in unified "search everything" results. Resource-governed with a type cap (MAX_CUSTOM_TYPES, default 50) and per-type record cap (MAX_CUSTOM_RECORDS_PER_TYPE, default 1000). Off by default (CUSTOM_ENTITY_TYPES_ENABLED=true to enable); when off the feature is fully invisible. Wired across Docker Compose, Terraform/ECS, and Helm. CLI: custom-type-create, custom-type-list, custom-record-create, custom-record-list. (#1172, #1173) [Custom Entity Types Guide](docs/custom-entities.md)
  • PingFederate Identity Provider Support - Use PingFederate as the OIDC identity provider for the registry, alongside the existing providers (Keycloak, Entra ID, Cognito, Okta, Auth0). Works across all three deployment surfaces: Docker Compose can optionally run a PingFederate container for local development, while Helm and Terraform/ECS connect to a customer-managed instance. Includes JWT group-claim mapping, an admin-API path for the registry to create OAuth clients and users, and user-to-group fallback. [PingFederate Setup Guide](docs/idp/pingfederate.md)

Source & license

This open-source MCP server is cataloged on AgentStack and links to its original source — we do not rehost the code.

Install and usage instructions live in the source repository linked above.

Reviews

No reviews yet — be the first.

Versions

  • v0.1.0 Imported from the upstream source.