MCPJungle: a self-hosted MCP gateway that puts all your MCP servers behind one endpoint

The problem MCPJungle solves: MCP configuration sprawl

Every MCP client keeps its own list of servers. Claude Desktop has a JSON file, Cursor has another, your own agent has a third. Add a server and you edit all of them. Remove one and you hope you remembered every client. The README lists the symptoms plainly: each client needs its own configuration, tools and prompts are scattered across servers, access control is duplicated or missing, and teams have no shared view of what tools exist.

MCPJungle's answer is a registry plus a gateway. You register an MCP server once, with the CLI or through the dashboard UI, and then point every client at a single MCP endpoint. The README frames the two deployment shapes directly: run it locally to keep a personal setup clean, or run it as shared infrastructure for a team with centralized discovery, access control and observability. The audience is developers who already have several MCP servers and teams who want a shared catalogue rather than a wiki page listing URLs.

How the gateway, registry and CLI fit together

MCPJungle is a client-server system, and the single binary can run either side. The server is the component that holds registered MCP servers and serves the unified gateway; the CLI is what you use to register, deregister and inspect them. The Go module list shows the shape of the server: gin for HTTP, gorm with both SQLite and Postgres drivers for persistence, mcp-go for the protocol, cobra for the CLI, zap for logging, and the OpenTelemetry SDK with a Prometheus exporter for metrics.

Two details in the repository layout matter for anyone evaluating operations. First, persistence is a real database, not a config file: the shipped compose file runs postgres:17 with a named volume, and the gateway receives a DATABASE_URL pointing at it. Second, there are two image flavours. The default Dockerfile is distroless and copies a single binary built by goreleaser, while docker-compose.yaml pulls ghcr.io/mcpjungle/mcpjungle with the tag latest-stdio by default, and stdio.Dockerfile exists separately. That split is worth understanding before you pick an image, because STDIO-based MCP servers need a runtime that can spawn child processes.

The flow is: a client connects to the gateway over streamable HTTP, the gateway looks up which registered servers provide the requested tool, and it proxies the call. Tools from different servers are namespaced, which is why the quickstart's example call is context7__get-library-docs rather than a bare tool name.

Installing MCPJungle and registering your first server

The quickstart runs the server with Docker Compose. Fetch the compose file and start it:

curl -O https://raw.githubusercontent.com/mcpjungle/MCPJungle/refs/heads/main/docker-compose.yaml
docker compose up -d

According to the README, this exposes the streamable HTTP MCP server at http://localhost:8080/mcp. The compose file starts two services, the Postgres database and the gateway, and waits for the database healthcheck before starting the gateway.

Next, install the CLI. Homebrew is the documented route on macOS, and the README notes that macOS users must use Homebrew because the compiled binary is not notarized yet:

brew install mcpjungle/mcpjungle/mcpjungle
mcpjungle version

With the CLI installed, register a remote MCP server. The README uses context7 as the example:

mcpjungle register --name context7 --url https://mcp.context7.com/mcp

The README says you should see output similar to its register-context7 screenshot, which it does not reproduce as text in the README. Then point a client at the gateway. For Claude Desktop the documented configuration bridges the HTTP endpoint through mcp-remote:

{
  "mcpServers": {
    "mcpjungle": {
      "command": "npx",
      "args": [
        "mcp-remote",
        "http://localhost:8080/mcp",
        "--allow-http"
      ]
    }
  }
}

The README's suggested prompt is to ask Claude to use context7 to get the documentation for /lodash/lodash, which should route through the gateway to the context7__get-library-docs tool.

Where MCPJungle is the wrong tool

If you run one MCP server, a gateway adds a Postgres instance, a second container and a network hop for no benefit. The README's own framing assumes you have many servers and multiple clients.

The compose file also carries a constraint that is easy to miss. It mounts the current directory into the container as /host read-only, with the comment that this enables filesystem MCP server access. The commented alternatives show ${HOME}:/host/home:ro and /tmp:/host/tmp:rw. So a filesystem MCP server registered through the gateway sees the container's view of the filesystem, not your host's, and anything registered through the default mount cannot write. Anyone expecting a filesystem server behind the gateway to edit files in their home directory will need to change that volume themselves.

There is also a documentation boundary. The README has been superseded by docs.mcpjungle.com, and it explicitly says to prefer the docs site for the latest guides, reference and operational details. The README's legacy section still carries headings for tool groups, authentication and enterprise features, but the current README does not document them in full. If your decision depends on the exact access-control model or the OpenTelemetry configuration, the README is not where that answer lives.

How MCPJungle differs from MetaMCP, IBM ContextForge and mcpo

The alternatives people search for alongside MCPJungle split into two groups. MetaMCP and IBM ContextForge are the closest comparisons: both are gateways that aggregate MCP servers behind one interface. The practical difference visible here is packaging and state. MCPJungle ships as a single Go binary plus a Postgres container, with the registry in the database and a CLI for registration, and the README describes both a local mode and a shared team mode with access control and observability hooks. If you want a gateway you can run as one compose file next to your existing Postgres, that is the shape MCPJungle offers.

mcpo sits in the other group. It is a proxy that exposes MCP servers as OpenAPI endpoints for clients that speak HTTP rather than MCP. That is protocol translation, not registry management: it does not give you a place to register servers, discover tools across them, or group tools per client. If your problem is "my client cannot speak MCP," mcpo is the relevant tool. If your problem is "I have twelve MCP servers and four clients," you want a gateway like MCPJungle, MetaMCP or ContextForge.

MintMCP is in the search data as well, but nothing in this material describes how it works, so treat it as a name to research separately rather than a documented alternative here.

Maintenance, upgrades and what MPL-2.0 means in practice

The last push to the default branch was on 2026-08-02, the same day release 0.4.6 was published. The two preceding releases, 0.4.5 and 0.4.4, landed in May 2026. The repository is not archived, and releases are versioned and published on a releases page that the README links for direct binary downloads. The upgrade path the README supports is Homebrew for the CLI and a pulled image for the server, with the compose file parameterizing the image tag through MCPJUNGLE_IMAGE_TAG, which defaults to latest-stdio.

That default is the upgrade detail worth flagging. Pinning the tag is a decision you make in your environment, not one the compose file makes for you, and because the gateway sits between your clients and every registered server, an image bump changes the behaviour of all of them at once. The compose file also sets SERVER_MODE to development by default and OTEL_ENABLED to false, with MCP_SERVER_INIT_REQ_TIMEOUT_SEC at 10 seconds. Those three environment variables are the knobs the shipped file exposes.

On licensing: MCPJungle is MPL-2.0, a file-level copyleft licence. Modifying MCPJungle's own source files carries obligations that permissive licences do not, while running it unmodified as a service does not. Whether that matters for your organisation is a question for your legal team, not for this article.

Editorial conclusion

Adopt MCPJungle if you run more than a couple of MCP servers and want one place to register them, one URL to point clients at, and a path to shared team infrastructure with access control and OpenTelemetry. Skip it if you only use one MCP server, or if you need a hosted service with a support contract, since this is a self-hosted binary plus a Postgres container you operate yourself. Before rolling it out, verify three things: that the Postgres and gateway containers come up healthy from the shipped docker-compose.yaml, that your client can reach the streamable HTTP endpoint at http://localhost:8080/mcp (Claude Desktop needs the mcp-remote bridge with --allow-http), and that any STDIO-based servers you register work under the container's mounted /host filesystem, because that mount is read-only by default.

Frequently asked questions

Official sources

1. License: MPL-2.0
2. mcpjungle/MCPJungle on GitHub
3. Project website
4. README
5. Releases