MCPJungle
Put multiple MCP servers behind one self-hosted endpoint.
- Source repo
- mcpjungle/MCPJungle
- Stars
- ★ 1.3k
- Last updated
- 2mo ago
- License
- MPL-2.0
- Primary language
- Go
- FA score
- 65/100 · Some gaps
At a glance
- How it runs
- Works with
- Universal · cross-platformCodex · Claude.ai
- Cost
- Free, no paid service needed
- Setup effort
- Medium · a few setup steps
- You'll need
- Typical use
- An individual developer using Claude Desktop, Cursor, or Codex who wants one MCP configuration instead of repeating every server in every client.
- Not a fit if
- Teams that need OAuth flows; only static bearer tokens or custom headers work today.
- Users who want prompts in Tool Groups or in-place group edits; groups must be deleted and recreated.
- Individuals unwilling to manage a database, containers, and session lifecycles.
- Source review
- 65/100 · Some gaps 1 safety controls not found
What does this agent do, and when should you use it?
MCPJungle is a self-hosted MCP gateway and registry that consolidates multiple MCP servers behind one Streamable HTTP endpoint. It includes a server, CLI client, HTTP API, and dashboard for registering, discovering, invoking, enabling, and disabling tools and prompts. Upstream servers may use stdio or Streamable HTTP, while consumers call tools under canonical <server>__<tool> names; Tool Groups can publish narrower endpoints for selected clients. Individuals can run development mode with SQLite, while Docker, PostgreSQL, and enterprise mode support shared deployments. Enterprise mode adds client tokens, server-level access controls, and OpenTelemetry metrics, although OAuth and parts of Tool Group administration remain limited.
An administrator uses mcpjungle register to submit a remote MCP URL or a stdio definition containing command, args, and env; the server connects to that upstream and loads its tools and prompts. Claude Desktop, Cursor, Copilot, Codex, or custom agents then connect to /mcp to discover and call the combined capabilities. The CLI exposes operations such as list tools, usage, invoke, enable, disable, and deregister, with tool calls addressed as <mcp-server-name>__<tool-name>. Tool Groups create separate MCP endpoints from included_tools, included_servers, and excluded_tools. Stateless mode opens and closes an upstream connection for every call, while optional stateful mode reuses it to reduce cold starts for process-based stdio servers. Registry state is stored in SQLite or PostgreSQL, and enabled telemetry is served from /metrics.
- An individual developer using Claude Desktop, Cursor, or Codex who wants one MCP configuration instead of repeating every server in every client.
- A platform team that needs a shared catalog where users can discover MCP tools registered by the organization.
- An enterprise administrator who must issue client tokens and restrict each MCP client to approved servers.
- A team with hundreds of available tools that wants client-specific Tool Groups exposing only a controlled subset.
- An operations team that wants to self-host its MCP infrastructure and monitor it through Prometheus-compatible OpenTelemetry metrics.
- A developer using slow-starting stdio servers who wants persistent upstream sessions to avoid repeated process startup.
How do you install or deploy this agent?
The shortest documented local path requires Docker and Docker Compose; development mode does not require an MCPJungle access token:
curl -O https://raw.githubusercontent.com/mcpjungle/MCPJungle/refs/heads/main/docker-compose.yaml
docker compose up -dThis exposes the MCP endpoint at http://localhost:8080/mcp. Alternatively, install the standalone binary with Homebrew and start it directly:
brew install mcpjungle/mcpjungle/mcpjungle
mcpjungle version
mcpjungle startA direct start creates mcpjungle.db in the working directory unless PostgreSQL or a custom SQLite path is configured. Production deployments can provide PostgreSQL through DATABASE_URL. Docker users whose stdio servers require npx or uvx need the stdio image variant; the documented local compose file already uses it by default.
How do you use this agent?
First register a remote Streamable HTTP server. This example does not require credentials:
mcpjungle register --name context7 --url https://mcp.context7.com/mcpInspect the aggregated tools from the CLI:
mcpjungle list tools
mcpjungle usage context7__get-library-docsThe documented Claude Desktop setup requires npx and mcp-remote:
{
"mcpServers": {
"mcpjungle": {
"command": "npx",
"args": [
"mcp-remote",
"http://localhost:8080/mcp",
"--allow-http"
]
}
}
}A first client request can then be:
Use context7 to get the documentation for `/lodash/lodash`For authenticated upstreams, pass --bearer-token or set bearer_token, headers, and ${VAR_NAME} placeholders in a JSON registration file. Enterprise deployments must also run mcpjungle init-server, create an MCP client with an allowed-server list, and configure that client to send the generated Bearer token.
What are this agent's strengths and limitations?
- A single
/mcpendpoint aggregates both stdio and Streamable HTTP servers, reducing duplicated configuration across clients. - Tool Groups publish dedicated endpoints assembled from selected tools or whole servers, with exclusions applied last.
- SQLite and PostgreSQL storage plus binary and Docker deployment paths cover personal and shared installations.
- Enterprise mode provides MCP client tokens, server-level ACLs, and Prometheus-compatible OpenTelemetry metrics.
- Optional stateful sessions reuse upstream connections and address cold-start overhead from process-based stdio servers.
- OAuth is not supported yet; authenticated HTTP upstreams currently rely on static Bearer tokens or custom headers.
- Tool Groups cannot contain prompts or be updated in place; changing one requires deletion and recreation.
- Containerized stdio servers require the relevant runtimes, and dependencies beyond
npxoruvxmay require a custom image. - Containers cannot access the host filesystem by default, so filesystem MCP servers require explicit volume mounts.
- Stateful sessions remain open until shutdown, deregistration, or an idle timeout, adding connection-lifecycle management.
How does this agent compare with similar options?
Compared with configuring every MCP server separately in every AI client, MCPJungle centralizes registration, discovery, access control, and observability behind one gateway. The tradeoff is another self-hosted service, database, and network hop; direct configuration may remain simpler for one client with only a few servers.
Key facts side by side with the most closely related agents.
| Agent | Source review | Form / cost | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|---|
| MCPJungle This agent | 65 · Some gaps | Self-hosted serviceFree | ★ 1.3k | 2mo ago | Go | Codex · Claude.ai |
| Metorial: Identity & Access Layer for AI Agents | 50 · Major gaps | Library / SDKFreemium | ★ 3.4k | today | TypeScript | ChatGPT · Codex · Claude Code · Claude.ai |
| Jarvis Registry | 40 · Major gaps | Self-hosted serviceFree | ★ 3.7k | today | Python | — |
| Archestra | 71 · Some gaps | Self-hosted serviceFreemium | ★ 4.4k | today | TypeScript | Codex · Claude Code · OpenAI API · Claude API |
How does FollowAgents rate this agent?
Why each dimension lost points
Tool groups, global disable controls, and the container's lack of host-filesystem access by default provide reasonable least-privilege measures, but every tool and prompt from a newly registered server is enabled by default. No user-confirmation mechanism is shown before tools with external effects are invoked, so that criterion receives zero. The README explains the flow among clients, gateway, upstream MCP servers, databases, and environment variables fairly clearly, but does not fully describe telemetry fields, log contents, or retention. Environment placeholders, bearer-token fields, and password files provide basic secret handling; encryption at rest, redaction, rotation, and protected token storage are not documented. go.mod pins dependency versions, but there is no evidence of vulnerability scanning, dependency review, update policy, or supply-chain controls. Registration, invocation, and STDIO execution can cause network, process, and downstream-tool effects without documented confirmation or effect previews. Disable, deregistration, and persistence warnings offer limited recovery, but tool-call rollback and backup restoration are absent. Canonical server-qualified tool names preserve useful upstream attribution and the module path is clear, although publisher identity is unverified and no fuller maintainer attribution is supplied.
The material documents a health check, graceful shutdown, stateful-connection lifecycle, failure on missing environment variables, and troubleshooting through stderr and server logs. The main deduction is a material inconsistency between the server's documented default port 8080 and the CLI's documented default registry address on port 8000, compounded by current guidance coexisting with a legacy reference. Binaries, Homebrew, containers, and host execution provide several availability paths, and the limits of the STDIO image are stated; offline operation and dependency-failure recovery are not covered. Failure guidance is concrete in several places but lacks a systematic error catalog, structured error contract, or comprehensive remediation guidance.
The documentation thoroughly distinguishes personal local use, shared team infrastructure, development mode, and enterprise mode, and covers Claude, Cursor, Copilot, and custom agents. Capability boundaries are unusually explicit: supported transports, immature SSE, container filesystem isolation, included STDIO runtimes, session behavior, and database options are all described. Canonical double-underscore names, tool groups, and enable/disable controls improve trigger precision, but default enablement and the absence of conflict resolution, hazardous-tool classification, or per-call policy prevent full marks. Docker, host, macOS, Kubernetes, SQLite, PostgreSQL, and remote deployments receive concrete environment-specific guidance.
The README has a quickstart, table of contents, scenario-based sections, and command examples, but much of the detail is labeled legacy while the latest operational material is moved to an external documentation site not included in evidence. Installation, verification, startup, connection, and platform notes are thorough. Product capitalization varies, production was renamed enterprise, and the 8080/8000 address mismatch weakens naming and configuration stability. Examples are extensive and show an end-to-end call, but there is no real FAQ or comprehensive troubleshooting matrix. Several limitations are explicit, including immature SSE, macOS notarization, container filesystem access, extra STDIO dependencies, and cold-start tradeoffs, though no complete centralized limitation inventory is provided. The full MPL-2.0 license is present and matches metadata. A Releases reference and one rename note exist, but no changelog or versioning policy is supplied. Documentation, roadmap, Discord, and contributing references imply update channels, yet no accountable maintainer, response commitment, or security-update path is identified; the unknown publisher identity is not otherwise penalized.
The unified endpoint, canonical tool names, discovery, prompt support, tool groups, and client-specific configurations produce directly usable outcomes, with a complete registration-to-invocation example. Central registration, access control, and observability offer clear marginal value over duplicating multiple server configurations in every client. The documentation acknowledges cold-start latency, persistent-session resource use, larger STDIO images, and production database choices, but provides no capacity measurements, performance evidence, operating-cost estimates, migration cost, or quantified security tradeoffs, so cost-benefit treatment is adequate rather than thorough.
Many operational claims map to concrete commands, configuration schemas, endpoints, and pinned go.mod versions, giving moderate traceability. However, no implementation code, tests, or deployment configuration is supplied to statically verify central claims about access control, session management, or observability. The license agrees with metadata and the module path agrees with repository identity, but most functional claims are corroborated only by the README. Defaults, recommendations, limitations, and examples are generally distinguished, including an explicit maturity warning for SSE; broader claims about centralization, security, and production suitability are not accompanied by enough evidence for complete fact-versus-inference separation.
- Not found in source: confirmation before actingTurn on (or add) a confirmation step before it acts, and try it in a sandbox or test environment before real data.
- All tools and prompts from a newly registered server are enabled by default; shared deployments should narrow exposure with tool groups or explicit disabling.
- The supplied material shows no user confirmation, effect preview, or per-call rollback mechanism for high-impact tool invocations.
- The README gives port 8080 as the server default but port 8000 as the CLI's default registry address; verify the actual deployment configuration.
- Storage, redaction, retention, and encryption policies for tokens, request data, telemetry, and logs are not documented in the supplied files.
- Dependencies are version-pinned, but no vulnerability scanning, supply-chain verification, or security-update process is evidenced.
- STDIO servers can launch configured commands, and filesystem reach depends on mounted paths; register only trusted servers and use narrowly scoped mounts.
- This assessment is limited to the supplied README, LICENSE, and go.mod; the software was not executed, and external documentation or release artifacts were not verified.
Recent releases
Latest entries from the project's GitHub Releases. Notes are quoted from upstream as written, not rewritten or tested by FollowAgents.
-
Release notes excerpt
What's Changed * feat(server): add --host / MCPJUNGLE_BIND_HOST to choose the bind interface by @goodmai in https://github.com/mcpjungle/MCPJungle/pull/287 New Contributors * @goodmai made their first contribution in https://github.com/mcpjungle/MCPJungle/pull/287 Full Changelog: https://github.com/mcpjungle/MCPJungle/compare/0.4.5...0.4.6View on GitHub ↗ -
Release notes excerpt
What's Changed * Allow configuring sqlite db file path by @duaraghav8 in https://github.com/mcpjungle/MCPJungle/pull/264 Full Changelog: https://github.com/mcpjungle/MCPJungle/compare/0.4.4...0.4.5View on GitHub ↗ -
Release notes excerpt
What's Changed * Add Dashboard UI for development mode by @duaraghav8 in https://github.com/mcpjungle/MCPJungle/pull/256 * fix: tie proxy MCP server versions to mcpjungle server version by @mvanhorn in https://github.com/mcpjungle/MCPJungle/pull/251 * docs: add config examples of popular MCP servers by @duaraghav8 in https://github.com/mcpjungle/MCPJungle/pull/255 New Contributors * @mvanhorn made their first contribution in https://github.com/mcpjungle/MCPJungle/pull/251 Full Changelog: https://github.com/mcpjungle/MCPJungle/compare/0.4.3...0.4.4View on GitHub ↗
FAQ
Is PostgreSQL required for local use?
./mcpjungle.db. PostgreSQL is available for more serious deployments through DATABASE_URL or PostgreSQL-specific settings.What credentials are needed for upstream MCP servers?
How do development and enterprise modes differ?
Can a Docker deployment run filesystem and other stdio servers?
/host; other dependencies may require a custom image.What can I do about a slow-starting upstream server?
"session_mode": "stateful" in its registration to reuse the connection. The default stateless mode creates and closes a connection for every call, which is simpler but can repeat startup latency.