MCPJungle is a self-hosted MCP gateway for developers and teams that need to manage multiple MCP servers, with the goal of solving the problems of scattered client configuration, repeated installation, and inconsistent permission control. It can be used both in a personal local environment to keep MCP configuration tidy, and as shared team infrastructure to provide centralized discovery, access control, and observability.
Purpose and core idea: Rather than connecting each MCP server separately to each AI client, register it once in MCPJungle, and then let Claude, Cursor, Codex, or a custom Agent connect to a unified MCP endpoint. The single control point it provides includes: one MCP endpoint for Claude, Cursor, Copilot, and custom Agents; centralized registration and management of MCP servers; unified discovery of tools, prompts, and resources; optional tool groups that expose only the tools a specific client should see; and simple access control and observability hooks for shared deployments.
Main capabilities: MCP servers with stdio and Streamable HTTP transports (SSE support exists but is not yet mature). You can add Streamable HTTP servers, add STDIO servers, remove MCP servers, and configure custom URLs for servers. Tools are referenced by canonical names in the format <mcp-server-name>__<tool-name>, with a double underscore separating the server name and the tool name. Tools can be globally enabled/disabled, and Prompts can also be enabled/disabled. Tool Groups are supported, used to expose only the tools a client should see. It also provides enterprise features such as access control and OpenTelemetry.
How to use: MCPJungle is released as a standalone binary, downloadable from the Releases page or installable with Homebrew; on macOS, Homebrew must be used because the compiled binary is not yet notarized. It uses a client-server architecture, and the same binary can run both the server and the client. The server is responsible for managing all registered MCP servers and provides a unified MCP gateway; the gateway itself runs on top of the Streamable HTTP transport and can be accessed via the /mcp endpoint. It is recommended to run the server locally with docker compose, which will also start MCPJungle server and a persistent Postgres database container. It can also be run directly on the host machine as a binary, listening on port 8080 by default, and by default it creates an SQLite database file mcpjungle.db in the current working directory; PostgreSQL is also supported, and a DSN or relevant environment variables can be provided. To register a stdio server that depends on npx or uvx, you should use the Docker image with the stdio tag (this image is larger but more convenient); if the stdio server depends on tools other than npx or uvx, you need to build a custom image containing those dependencies and the mcpjungle binary. Adding MCP servers can be done through the CLI or a configuration file. When connecting Claude Desktop, Cursor, and Copilot, simply add the MCP server configuration for MCPJungle to their respective MCP configurations, and afterward the clients will call tools through MCPJungle. By default, each tool call creates a new connection to the upstream MCP server and closes it after the call completes; you can also set session_mode to stateful in the MCP server configuration to reuse connections and avoid the cold-start overhead of stdio servers. Connections are closed after the server stops, the server is deregistered, or an idle timeout occurs. The idle timeout can be configured via SESSION_IDLE_TIMEOUT_SEC (default -1 means no timeout). The official recommendation is to use the default stateless connection whenever possible. The CLI connects by default to http://127.0.0.1:8000，可用 --registry flag or the ~/.mcpjungle.conf configuration file to specify a custom registry address.
Use cases: keeping MCP configuration tidy locally for individuals; a shared gateway for teams, with centralized discovery, access control, and observability; scenarios where multiple AI clients (Claude, Cursor, Copilot, custom agents) should share a set of MCP tools; tool group scenarios where only some tools are exposed per client.
Limitations and notes: SSE support is not yet mature. Running a stdio filesystem server in Docker requires additionally mounting a host directory volume and specifying the mount path; by default the container cannot access the host file system. The standard image does not include a shell, so /mcpjungle must be run directly via docker exec or kubectl exec. Deleting the SQLite file deletes all registered server data and other MCPJungle state. Enterprise mode (formerly production mode) has been renamed, but everything else remains unchanged. Regarding facts about charges, pricing, specific platforms, and effectiveness, the materials do not yet provide them.
