Jarvis Registry is an open-source, enterprise-grade MCP (Model Context Protocol) and A2A agent gateway and workflow orchestration platform for organisations that need to give AI copilots and autonomous agents governed access to internal tools and data.

What it is

Jarvis Registry is an Apache-2.0 licensed Python project built by ASCENDING Inc. It acts as an MCP and A2A agent gateway, registry, and workflow orchestration platform. MCP stands for Model Context Protocol, and A2A refers to agent-to-agent communication; the project sits in the emerging ecosystem of MCP servers, MCP-compatible copilots, and autonomous agents. It provides a single authenticated entry point for AI clients and agents, speaking MCP over SSE or Streamable HTTP, and it also registers and manages autonomous agents so that orchestrator agents can coordinate worker agents through the same gateway.

The concrete problem it solves is integration and governance sprawl. Without a gateway, every AI copilot and every agent needs its own connection to each internal tool, which produces fragmented integrations and security blind spots. Jarvis Registry replaces that pattern with one authenticated, audited entry point, so access decisions are made centrally rather than inside each integration. It layers identity, access control, discovery, and observability on top of the gateway rather than leaving them to individual tool owners.

Key capabilities

• MCP gateway and reverse proxy exposing a single authenticated entry point for AI clients and agents using MCP over SSE or Streamable HTTP.
• AI copilot integration for Cursor, Claude Desktop, GitHub Copilot, VS Code, and any other MCP-compatible copilot.
• A2A agent orchestration: register and manage autonomous agents, with orchestrator agents coordinating worker agents through the same secure gateway.
• Identity and access management using OAuth 2.0/OIDC with Keycloak, Amazon Cognito, and Microsoft Entra ID, requiring no custom auth code.
• An ACL engine enforcing scope-based and role-based permissions down to the individual tool level.
• Skill and context-based discovery: semantic search over skills, descriptions, and tags so agents and copilots locate the right MCP server or A2A agent at runtime.
• Audit and observability through full request logging, OpenTelemetry tracing, and Prometheus metrics.

Who uses it and how

• Platform and security teams that need one governed entry point instead of per-tool integrations for every AI client in the organisation.
• Enterprises already standardised on an identity provider such as Keycloak, Amazon Cognito, or Microsoft Entra ID, who want existing OAuth 2.0/OIDC credentials to govern agent and copilot access.
• Agent builders running multi-agent workflows, where an orchestrator agent coordinates worker agents registered in the same registry.
• Operations teams deploying cloud-native: documented guides cover AWS EKS, Azure AKS, and GCP GKE, with a Docker Compose path for a full local stack.
• Teams that need tool-level permissions rather than blanket agent access, using the ACL engine to scope which MCP servers and tools each role may reach.

Getting started

Clone https://github.com/ascending-llc/jarvis-registry.git, copy .env.example to .env and add identity provider credentials, run uv sync --all-packages, then start everything with docker compose --profile full up -d and open http://localhost:80. A fuller Get Started guide lives at docs/quick-start.md and on jarvisregistry.com.

How it compares

Jarvis Registry acknowledges and builds upon agentic-community/mcp-gateway-registry, the upstream project whose core MCP gateway patterns it extends. Where the upstream work established those gateway foundations, Jarvis Registry adds A2A agent orchestration, an ACL engine for tool-level permissions, and integration with Keycloak, Amazon Cognito, and Microsoft Entra ID. Both are open source, so the practical difference is scope of the agent and governance layer rather than licence or hosting model.

When to use it — and when not to

A self-hoster must operate the full Docker Compose stack or a Kubernetes cluster on EKS, AKS, or GKE, and must supply and configure an external identity provider with OAuth 2.0/OIDC credentials before the gateway is useful. Teams that want no authentication layer, no audit trail, or no container runtime should not adopt it; the same applies to anyone unwilling to run Keycloak, Cognito, or Entra ID alongside it. The README is largely a pointer to the external documentation site, so expect to read jarvisregistry.com rather than the repository for configuration detail.

# Clone the repository
git clone https://github.com/ascending-llc/jarvis-registry.git
cd jarvis-registry

# Copy and configure environment
cp .env.example .env
# Edit .env with your identity provider credentials

# Setup Python Virtual Environment
uv sync --all-packages
source .venv/bin/activate

# Start all services
docker compose --profile full up -d

# Open the registry UI
open http://localhost:80