# Jarvis Registry: an MCP gateway with identity, ACLs and tracing built in

> Jarvis Registry puts an authenticated MCP and A2A gateway in front of enterprise tools, with OAuth identity, tool-level ACLs and OpenTelemetry tracing. It is a Docker Compose stack, not a library you import.

**ascending-llc/jarvis-registry** — Connect any AI copilot or autonomous agent to your enterprise tools — through a single, secure MCP/Agent gateway with built-in identity, access control, and full observability.

- Repository: https://github.com/ascending-llc/jarvis-registry
- Website: https://jarvisregistry.com
- Stars: 3,218 · Forks: 485
- Language: Python
- License: Apache-2.0
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/ascending-llc-jarvis-registry

## The problem Jarvis Registry targets: many copilots, many tools, no single door

Every MCP-compatible client you adopt (Cursor, Claude Desktop, GitHub Copilot, VS Code) needs its own connection to each internal tool. The README frames the result as "fragmented integrations or security blind spots", and that is a fair description of the usual setup: credentials copied into per-client config files, no shared record of which agent called which tool, and no way to revoke one tool from one team without editing every client.

Jarvis Registry is aimed at platform and security engineers in organizations large enough to have an identity provider and a compliance question about agent traffic. It is not aimed at an individual developer who wants a local MCP server. The distinction matters because the whole product is a gateway: it assumes there is something behind it worth governing, and someone who needs to prove who called what.

The README also positions it as an evolution of agentic-community/mcp-gateway-registry, which it credits for "the core MCP gateway patterns". If you have evaluated that project, the delta here is the enterprise layer: OIDC identity, the ACL engine, and the observability stack.

## How the gateway sits between clients and MCP servers

The architecture visible in the repository is a set of services rather than a single process. The registry service is described in docker-compose.yml as including "nginx, SSL, FAISS, models", which tells you the search and TLS termination live inside that image. The auth-server is a separate workspace member with its own internal URL (http://auth-server:8888) and an external public URL, so token issuance is isolated from the registry that consumes tokens.

Clients connect to the gateway over MCP using SSE or Streamable HTTP, according to the README's capability table. The gateway is the only authenticated entry point; behind it, MCP servers and A2A agents are registered as entries. Discovery is semantic rather than a static list: the README describes "semantic search over skills, descriptions, and tags", and the registry image bundling FAISS and models is consistent with embeddings being computed and stored inside that container rather than in a separate vector service.

Access control is evaluated at request time by an ACL engine that the README says enforces "scope-based, role-based permissions down to the individual tool level". That granularity is the interesting design decision. Most gateways authorize at the server level, which means granting a client access to a server grants every tool it exposes. Here the unit of permission is the tool, so a copilot can be allowed to read a ticket and blocked from closing one, even though both are tools on the same MCP server.

Observability is a first-class part of the stack. docker-compose.yml wires an OpenTelemetry Collector that receives OTLP on 4318 (HTTP) and 4317 (gRPC), forwards traces to Tempo on 3200, and exposes Prometheus metrics on 8889. The collector also reads LANGFUSE_OTLP_AUTHORIZATION from the environment, so traces can be shipped to Langfuse instead of, or alongside, the local Tempo instance.

## Installing Jarvis Registry and reaching the UI for the first time

The Quick Start in the README is a clone, an environment file, a uv sync, and a Compose profile. The repository requires Python >=3.12,<3.13 according to pyproject.toml, so a newer interpreter will not satisfy the workspace constraint.

Clone the repository and create your environment file from the sample. The README notes that you should then edit .env with your identity provider credentials, which is the step that actually determines whether the stack comes up usefully.

```bash
git clone https://github.com/ascending-llc/jarvis-registry.git
cd jarvis-registry
cp .env.example .env
```

The workspace uses uv, and the README installs all workspace members at once. The members listed in pyproject.toml are registry-pkgs, registry, auth-server and workflow-worker.

```bash
uv sync --all-packages
source .venv/bin/activate
```

Start the full profile. The profile name matters: otel-collector and tempo in docker-compose.yml are both gated behind profiles: [full], so a plain docker compose up will not start the tracing stack.

```bash
docker compose --profile full up -d
```

The README then opens the registry UI on port 80. The registry service itself defaults to port 7860 via REGISTRY_URL in .env.example, with nginx in front on 80, which is why the UI URL and the internal URL differ.

```bash
open http://localhost:80
```

Before the first real request, expect to fill in more of .env than the quick start shows. .env.example defines ADMIN_USER and ADMIN_PASSWORD for the registry, AUTH_SERVER_URL and AUTH_SERVER_EXTERNAL_URL for the auth server, REGISTRY_APP_NAME (registry-client) and REGISTRY_CLIENT_SECRET for the registry acting as an OAuth client, plus GitHub client credentials and several integration tokens in docker-compose.yml. The auth server supports OAuth 2.0/OIDC with Keycloak, Amazon Cognito and Microsoft Entra ID per the README, so pick one of those three and point the auth server at it.

## Where Jarvis Registry is the wrong tool

The heaviest constraint is operational. This is a multi-service deployment: a registry image that embeds nginx, SSL, FAISS and models, a separate auth server, and an optional tracing stack of collector plus Tempo. The README's own deployment section lists AWS EKS, Azure AKS, GCP GKE and Docker Compose, and describes the Compose path as "Full local stack in under 5 minutes", but that estimate assumes a working identity provider and a populated .env. If you have neither, the five minutes is not the part that costs you.

There is also a hard dependency on an external identity provider. The README names Keycloak, Amazon Cognito and Microsoft Entra ID. If your organization runs something else, the README does not document a path for you, and the auth server is a workspace member you would be modifying rather than configuring.

Granularity cuts the other way too. Tool-level ACLs are only as good as the tool boundaries your MCP servers expose. A server that wraps a broad internal API as one tool named something like execute_query cannot be meaningfully restricted by this gateway, because the permission unit is coarser than the operation. The gateway enforces what the server advertises; it does not decompose a tool.

The README is silent on rollback and on upgrading between CLI releases. Three CLI releases landed in September 2026 (cli-v0.3.0, cli-v0.3.1, cli-v0.4.0), which is a fast cadence, and the repository does not document a downgrade procedure or a state migration path. Treat the registry's persisted state as something to back up before you move versions.

Finally, if you only need one MCP client talking to one MCP server on your own machine, this is several containers of overhead for a problem you do not have.

## How it differs from running mcp-gateway-registry directly

The README is explicit that Jarvis Registry "builds upon the excellent foundational work of the agentic-community/mcp-gateway-registry project", crediting those contributors with "the core MCP gateway patterns". That is the closest real alternative, and the difference is not a rewrite of the gateway idea but the layer around it.

mcp-gateway-registry, as described in that acknowledgement, established the gateway pattern itself. Jarvis Registry adds an auth server as a separate service with named OIDC integrations, an ACL engine that the README says reaches the individual tool level, A2A agent registration and orchestration alongside MCP servers, semantic discovery over skills and tags, and an observability stack wired into docker-compose.yml with OpenTelemetry, Tempo and Prometheus. The deployment surface grows accordingly: three workspace members plus a workflow-worker in pyproject.toml, and a Compose file with an optional full profile.

The practical difference is who operates it. The lighter project is a reasonable fit for a team that wants a gateway and already has auth handled elsewhere. Jarvis Registry is for the team that wants the identity, the per-tool policy and the traces to arrive as part of the same deployment, and is willing to run and upgrade that deployment.

## Maintenance, release cadence and what Apache-2.0 means here

The repository is not archived and the last push was on 2026-09-10, so the codebase is being changed. The release history supports that: cli-v0.3.0 on 2026-09-04, cli-v0.3.1 on 2026-09-05, and cli-v0.4.0 on 2026-09-08. Three CLI releases inside a week is a cadence that rewards pinning a version and reading release notes before moving.

The upgrade cost is not just the CLI. The registry image is pulled as ghcr.io/ascending-llc/jarvis/registry:latest in docker-compose.yml, which is a floating tag. A deployment that follows latest will change underneath you on the next pull. Pinning a digest or a specific tag is the only way to make a rollout reproducible, and the Compose file as written does not do that for you.

Licensing is Apache-2.0, per both the README and the LICENSE file in the repository root. Apache-2.0 permits commercial use, modification and redistribution, and includes an express patent grant. It also requires that you preserve copyright and licence notices, and that modified files carry prominent notices of change. The repository also contains a NOTICE file, which Apache-2.0 treats as part of the attribution obligation. This is a description of the licence text, not legal advice; if you are redistributing a modified registry, get your own counsel to review the NOTICE handling.

The README asks that security vulnerabilities go to support@ascendingdc.com rather than a public issue, which is worth noting if your process routes everything through GitHub.

## Conclusion

Adopt Jarvis Registry if you already run an OIDC provider and need one authenticated entry point for several MCP clients and agents, with per-tool permissions and traces you can query. Do not adopt it if you want a single-user MCP server on a laptop, or if you cannot run Docker Compose and a MongoDB-backed registry. Before committing, verify three things: that your identity provider is one of the three the auth server names, that the tool-level ACL model covers how your MCP servers expose tools, and that the .env.example keys match what your deployment actually needs, because the README does not document rollback or an upgrade path between CLI versions.

## FAQ

### What is Jarvis Registry used for?

It is an MCP and A2A gateway that gives AI copilots and autonomous agents one authenticated entry point to enterprise tools, with OAuth identity, tool-level access control and request logging. The README lists copilot integration with Cursor, Claude Desktop, GitHub Copilot and VS Code among its uses.

### Is Jarvis Registry free?

It is licensed under Apache-2.0, so the source is free to use, modify and redistribute under that licence's terms, including its attribution requirements. The README does not describe a paid tier or a hosted offering.

### What is Jarvis Registry software used for?

It registers MCP servers and A2A agents behind a single gateway, lets agents discover them by semantic search over skills and tags, and enforces scope-based and role-based permissions down to the individual tool. It also emits OpenTelemetry traces and Prometheus metrics for that traffic.

### Who owns Jarvis Registry?

The repository is ascending-llc/jarvis-registry and the README states it is built by ASCENDING Inc, with a link to ascendingdc.com. The Apache-2.0 licence means ownership of the code does not restrict your use of it.

## Sources

- [ascending-llc/jarvis-registry on GitHub](https://github.com/ascending-llc/jarvis-registry)
- [License: Apache-2.0](https://github.com/ascending-llc/jarvis-registry/blob/main/LICENSE)
- [Project website](https://jarvisregistry.com)
- [README](https://github.com/ascending-llc/jarvis-registry/blob/main/README.md)
- [Releases](https://github.com/ascending-llc/jarvis-registry/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/ascending-llc-jarvis-registry