自动化与运维 mcp-gatewaymcp-registryself-hostingaccess-controltool-discoveryopentelemetrydockerpostgresql

MCPJungle

通过一个自托管端点统一管理和连接多个 MCP 服务器。

FollowAgents 评估 · FARS-2.1
谨慎使用
65/ 100 五分制 3.3 / 5
1 2 3 4 5 6
1信任安全13 / 29 · 2.2/5

工具组、全局禁用以及容器默认不访问宿主文件系统体现了适度的最小权限设计,但新注册服务器的工具和提示默认全部启用。材料未显示调用具有外部副作用的工具前存在用户确认机制,因此该项为零。README较清楚地说明客户端、网关、上游MCP服务器、数据库和环境变量之间的数据流,但没有完整说明遥测字段、日志内容或数据保留策略。支持环境变量占位符、令牌字段及密码文件,算是基本敏感数据处理;不过未说明静态加密、日志脱敏、密钥轮换或令牌存储保护。go.mod固定了依赖版本,但没有依赖审计、漏洞扫描、更新策略或供应链控制证据。注册、调用及STDIO命令能够产生网络、进程和下游工具副作用,而确认和效果预览不足。禁用、注销及持久化状态说明提供有限恢复手段,但没有工具调用回滚或备份恢复流程。服务器命名和规范工具名可保留上游来源,模块路径也明确,但发布者身份未经验证,材料没有更完整的维护者归属。

2可靠稳定8 / 14 · 2.9/5

文档提供健康检查、优雅关闭、状态连接生命周期以及环境变量缺失时的错误行为;同时建议通过stderr和服务器日志诊断故障。扣分主要来自README中服务端默认端口8080与CLI默认注册表地址8000之间的显著不一致,以及主要文档与折叠的旧版参考并存。二进制、Homebrew、容器和直接运行提供多种依赖获取路径,并明确stdio镜像仅内含npx和uvx、其他工具需自定义镜像;但没有离线或依赖故障恢复说明。失败信息有若干具体入口,却未展示系统化错误目录、结构化错误契约或面向用户的修复指导覆盖。

3适用触发16 / 18 · 4.4/5

材料完整区分个人本地使用、团队共享基础设施、开发模式和企业模式,并覆盖Claude、Cursor、Copilot及自定义Agent,因此受众和场景充分。它明确界定stdio、Streamable HTTP和不成熟的SSE支持,说明无默认宿主文件访问、镜像依赖范围、无超时状态会话及数据库选择,能力边界较强。双下划线规范名、工具组以及启用/禁用提高了工具选择精度;但所有新工具默认启用,且未展示冲突消解、危险工具分类或调用级策略,因此未满分。Docker、宿主机、macOS、Kubernetes、SQLite、PostgreSQL及远程部署均有具体适配说明,环境覆盖充分。

4规范维护12 / 18 · 3.3/5

README具有快速开始、目录、场景化章节和命令示例,但核心内容被标为旧版参考,最新运维细节又转移到未提供的外部文档,降低了仓库内信息架构的完整性。安装、验证、启动、连接和平台注意事项十分具体,安装说明可给满分。产品名大小写偶有不一致,enterprise由production改名,且8080与8000地址不一致,所以命名稳定性仅为适度。示例丰富并含预期调用过程,但没有真正的FAQ或完整故障排查矩阵。材料明确记录SSE不成熟、macOS未公证、容器文件访问、额外STDIO依赖和冷启动权衡,但未呈现集中且完整的限制清单。LICENSE完整提供MPL-2.0文本,与元数据一致。仅见Releases入口和一次模式改名说明,没有版本政策或变更日志。文档站、路线图、Discord及贡献入口暗示维护渠道,但未明确责任人、响应承诺或安全更新路径;发布者身份保持未知,不据此作额外推断。

5有效结果12 / 13 · 4.6/5

统一端点、规范工具名、工具发现、提示支持、工具组和多客户端配置构成可直接使用的输出,示例也展示了从注册到调用的完整操作路径。相较于在每个客户端重复配置多个服务器,集中注册、访问控制与可观测性具有清晰的边际价值。文档承认冷启动、状态连接资源占用、stdio镜像体积及生产数据库选择等成本,但没有容量指标、性能数据、运维成本、迁移成本或安全代价量化,因此成本收益只算充分但不彻底。

6证据核验4 / 8 · 2.5/5

多数操作性主张对应具体命令、配置结构、端点和go.mod依赖版本,具备一定可追溯性;但所给材料没有实现代码、测试或配置文件来静态核对访问控制、会话管理、观测性等核心声明。LICENSE与许可元数据、模块路径与仓库身份可以交叉印证,功能声明却主要来自单一README,跨来源佐证较弱。文档通常区分默认值、建议、限制和示例,并明确标注SSE不成熟等事实;不过集中化、安全性和生产适用性等宣传性结论缺少随附证据,事实与推断分离尚未达到完整程度。

证据充分度: 评估于 2026年8月14日 审查版本 12648be5edc7
源码中未见的安全控制:执行前用户确认
使用前请注意
  • 新注册服务器的全部工具和提示默认启用;共享部署前应使用工具组或显式禁用来缩小暴露面。
  • 材料未显示高影响工具调用前的用户确认、效果预览或调用级回滚机制。
  • README同时出现服务端默认端口8080和CLI默认注册表端口8000,部署时必须核实实际配置。
  • 令牌、请求数据、遥测和日志的存储、脱敏、保留及加密策略未在所给文件中说明。
  • 依赖虽固定版本,但没有提供漏洞扫描、供应链校验或安全更新流程的证据。
  • STDIO服务器可启动任意配置命令,文件系统访问又取决于挂载范围;只应注册可信服务器并使用最小化挂载。
  • 本评估仅基于所给README、LICENSE和go.mod,未执行软件,也未核验外部文档或发布产物。
评估证据 [1][2][3]
查看完整评分方法 →

这个 Agent 能做什么,适合哪些场景?

MCPJungle 是面向个人开发者和团队的自托管 MCP 网关与注册中心。它由服务器和 CLI 组成:服务器登记上游 MCP 服务器并通过 `/mcp` 提供统一的 Streamable HTTP 端点,CLI 用于注册、移除、发现和调用工具及提示。它支持 Streamable HTTP 与 stdio 上游,并对 SSE 提供尚不成熟的支持;上游工具会以 `<服务器名>__<工具名>` 的规范名称呈现。默认的无状态模式为每次调用新建并关闭上游连接,也可启用有状态会话来复用连接、降低冷启动延迟。它可以使用本地 SQLite,也能配合 PostgreSQL、Docker Compose、访问控制、工具组和 OpenTelemetry 构成共享团队基础设施。

管理员通过 mcpjungle register 或 JSON 配置登记远程 Streamable HTTP 服务器或本地 stdio 进程;配置可包含 URL、命令、参数、环境变量、Bearer Token 和自定义 HTTP 头。MCPJungle 读取上游提供的工具和提示,将工具规范化为 <mcp-server-name>__<tool-name>,并让 CLI 通过 mcpjungle list toolsmcpjungle usagemcpjungle invoke 查询或调用它们。AI 客户端连接统一的 /mcp 端点后,工具调用由网关转发至相应上游,并将结果返回客户端。管理员还能全局启停服务器、工具和提示,或创建带独立 MCP 端点的 Tool Group,仅暴露指定服务器或工具。企业模式增加管理员初始化、用户与 MCP Client Token、服务器级访问许可及默认启用的 OpenTelemetry 指标。

  1. 个人开发者同时在 Claude Desktop、Cursor 或 Codex 中使用多个 MCP 服务,希望只维护一个本地网关配置。
  2. 平台团队为多人部署共享 MCP 基础设施,需要集中登记服务器、发现工具并统一查看可用能力。
  3. 安全负责人希望为不同 MCP 客户端签发 Token,并限制每个客户端可以访问的上游服务器。
  4. 拥有大量 MCP 工具的团队希望用 Tool Group 为特定客户端缩小工具集合,避免一次暴露数百个工具。
  5. 运维团队希望以 Docker 和 PostgreSQL 部署网关,并通过 /metrics 获取 Prometheus 兼容的 OpenTelemetry 指标。
  6. 使用启动较慢的 stdio MCP 服务器的开发者,希望通过 session_mode: "stateful" 复用连接以减少冷启动。

这个 Agent 有哪些优点和局限?

优点
  • 把多个上游 MCP 服务器汇聚到单一 Streamable HTTP 端点,减少每个 AI 客户端重复配置。
  • 同时支持 Streamable HTTP 和 stdio,并提供无状态与有状态连接模式以权衡资源清理和冷启动延迟。
  • Tool Group 可生成独立端点,按工具、服务器及排除规则控制客户端可见范围。
  • 企业模式提供 MCP Client Token、服务器级许可、用户角色和 OpenTelemetry 指标。
  • 既能以 SQLite 轻量本地运行,也能使用 Docker、PostgreSQL 扩展到共享部署。
局限
  • 尚不支持 OAuth 流程;远程服务认证目前依赖静态 Bearer Token 或自定义请求头。
  • SSE 支持被明确标注为不成熟,依赖该传输方式的服务存在采用风险。
  • Tool Group 不支持提示,且现有组不能原地更新,只能删除后重新创建。
  • 使用 stdio 服务时,网关运行环境必须包含对应命令和依赖;标准容器镜像不含 npxuvx
  • Docker 中的文件系统 MCP 服务器无法默认访问宿主机文件,必须显式挂载目录并正确配置容器路径。
  • 网关成为所有 MCP 调用的集中依赖,需要额外维护数据库、凭据、网络可达性和可观测性。

如何安装或部署这个 Agent?

文档化的本地快速启动需要 Docker 与 Docker Compose:

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

默认 MCP 端点为 http://localhost:8080/mcp。CLI 可通过 Homebrew 安装:

brew install mcpjungle/mcpjungle/mcpjungle
mcpjungle version

也可以从 Releases 下载独立二进制,或拉取镜像:

docker pull ghcr.io/mcpjungle/mcpjungle

直接运行二进制可使用 mcpjungle start;未配置数据库时会在当前目录创建 mcpjungle.db。共享部署可设置 DATABASE_URL 指向 PostgreSQL。使用依赖 npxuvx 的 stdio 服务时,应选择 latest-stdio 镜像;其他运行时依赖需要自行制作镜像。

如何使用这个 Agent?

先登记一个可工作的上游 MCP 服务器:

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

随后把 Claude Desktop 配置为连接统一端点;该方式需要 Node.js 环境中的 npxmcp-remote

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

完成后可要求 Claude 使用 Context7 获取 /lodash/lodash 文档。也可直接测试工具,例如:

mcpjungle invoke calculator__multiply --input '{"a": 100, "b": 50}'

远程网关可通过 mcpjungle --registry http://my-server:9000 list tools 指定地址。在企业模式下先运行 mcpjungle init-server,再用 mcpjungle create mcp-client <名称> --allow "server1,server2" 创建客户端,并在请求中发送生成的 Authorization: Bearer <token>

这个 Agent 与同类方案有什么区别?

与把每个 MCP 服务器分别配置到每个 AI 客户端相比,MCPJungle 将注册、发现、访问控制和调用入口集中到一个网关。代价是引入一个需要部署和维护的中间层;直接连接配置更分散,但不依赖额外网关。

常见问题

本地试用必须部署 PostgreSQL 吗?
不需要。直接启动时默认使用当前目录中的 mcpjungle.db SQLite 文件;PostgreSQL 面向更严肃或共享的部署。删除 SQLite 文件会清除其中保存的注册信息和其他状态。
能否连接需要 OAuth 的 MCP 服务?
目前不能完成 OAuth 流程。Streamable HTTP 上游可以使用静态 Bearer Token、自定义 Authorization 值或其他自定义 HTTP 头。
开发模式和企业模式有什么权限差异?
开发模式下,MCP 客户端可以访问全部已登记服务器。企业模式默认不授予客户端服务器访问权,必须创建 MCP Client 并显式设置允许访问的服务器。
如何处理 stdio 服务器的启动延迟?
默认无状态模式每次调用都会新建并关闭连接。可把服务器配置的 session_mode 设为 stateful,首次调用后复用连接,并可用 SESSION_IDLE_TIMEOUT_SEC 设置全局空闲超时。
Tool Group 会绕过被禁用工具的限制吗?
不会。全局禁用或删除的工具不会出现在组端点;之后重新启用或重新添加时,它会自动恢复到包含它的组中。

相关 Agents