Cherry Mcp

核心用法

Cherry MCP 是一个 HTTP 桥接服务，解决 MCP 服务器依赖持久 STDIO 连接、无法在无原生支持的环境中运行的问题。它通过子进程启动 MCP 服务器，维持连接保活，并将工具调用转换为 RESTful HTTP 端点。

主要功能

• 服务器管理：通过 CLI 添加/删除/列出 MCP 服务器，配置启动命令与环境变量
• HTTP 暴露：每个服务器映射到独立端点，支持工具列表查询和工具调用
• 自动保活：进程崩溃后自动重启，确保服务持续可用
• 安全控制：可选速率限制、IP 白名单、审计日志，默认仅绑定 localhost

架构特点

• 单文件架构，依赖极简（Node.js 原生模块）
• 配置持久化到 JSON 文件
• 支持 PM2 进程管理，适合生产部署

显著优点

• 填补生态空白：专为 OpenClaw 等无 MCP 原生支持的环境设计
• 零侵入改造：无需修改原 MCP 服务器代码
• 运维友好：自动重启、日志审计、PM2 集成
• 轻量部署：单文件实现，启动快速

潜在局限

• 环境变量安全风险：set-env 以明文存储于 config.json，需配合 .gitignore 或改用 shell 环境变量
• 单点故障：桥接器本身成为依赖，崩溃则所有 MCP 服务中断
• 性能瓶颈：所有请求经 Node.js 转发，高并发场景需评估
• 协议适配局限：仅支持 STDIO 转 HTTP，SSE 等传输模式未提及
• 网络隔离默认绑定 127.0.0.1，跨主机调用需额外配置（但文档明确不建议）

适合人群

• 使用 OpenClaw、Autogen 或其他无原生 MCP 支持的 Agent 框架的开发者
• 需要将现有 MCP 工具集成到已有 HTTP/REST 工作流的团队
• 希望快速验证 MCP 工具链、不愿投入复杂基础设施的实验者

常规风险

• 配置泄露：明文存储的 API 密钥可能意外提交到版本控制
• 本地权限提升：绑定 localhost 但仍需防范本地恶意进程访问
• 依赖注入：虽 HTTP 层不接受任意命令，但配置中的命令执行仍需谨慎审计
• 资源耗尽：自动重启机制在持续崩溃场景下可能消耗系统资源

使用建议

1. 优先使用 shell 环境变量注入敏感信息，避免 set-env
2. 配置 .gitignore 排除 config.json
3. 生产环境启用审计日志与速率限制
4. 监控桥接器进程健康状态，避免单点故障

核心用法

Cherry MCP是一个HTTP桥接服务，专为解决MCP（Model Context Protocol）服务器的stdio生命周期限制而设计。其核心工作流程包括：通过CLI工具将MCP服务器（如GitHub、Slack等官方MCP服务）注册为子进程，由桥接服务持续保持进程存活，并将MCP工具暴露为本地HTTP REST端点。

具体使用分为三步：注册服务器（add-server命令配置服务器名称、启动命令及参数）、配置环境变量（通过set-env设置API密钥等敏感信息，或直接注入shell环境变量）、启动桥接服务（建议使用pm2等进程管理器保持服务常驻）。启动后，用户可通过标准HTTP请求完成工具发现（GET /<server>/tools）和工具调用（POST /<server>/call），实现与原生MCP客户端等效的功能体验。

显著优点

架构简洁可靠：零外部依赖设计，完全基于Node.js原生模块（http、child_process、fs、path），彻底规避供应链攻击风险，安装部署轻量快速。

进程管理智能：内置自动重启机制（崩溃后最多5次重试），解决stdio型MCP服务"无客户端即死亡"的根本痛点；支持通过HTTP接口手动重启特定服务器，运维友好。

安全防护多层：默认绑定127.0.0.1拒绝外部网络访问；提供可选的速率限制、IP白名单、审计日志三重防护；1MB请求体上限防止DoS攻击。

生态兼容广泛：任何支持HTTP请求的Agent平台（如OpenClaw）均可接入，无需等待官方MCP原生支持，大幅扩展MCP生态的可用场景。

潜在缺点与局限性

配置安全依赖用户自律：环境变量以明文形式存储于config.json，需用户自行设置文件权限和.gitignore；虽支持shell环境变量注入方案，但文档引导不足易致误操作。

CORS配置宽松：当前允许所有来源跨域访问（*），虽因本地绑定降低实际风险，但在复杂代理环境下仍存在CSRF攻击隐患。

输入验证机制薄弱：HTTP API端点缺乏严格的JSON Schema校验，工具名称和参数未实施白名单过滤，可能引发意外错误或信息泄露。

平台绑定限制：专为Node.js运行时设计，非Node生态用户需额外部署环境；Windows系统下的进程管理行为未经充分验证。

错误信息暴露风险：部分异常场景直接返回原始错误消息，可能泄露内部实现细节或系统路径，生产环境需额外脱敏处理。

适合的目标群体

OpenClaw等新兴Agent平台用户：急需MCP工具能力但平台暂未原生支持的早期采用者，可通过HTTP桥接快速验证MCP工作流。

微服务架构开发者：需要将MCP能力集成至现有REST/gRPC服务体系的团队，桥接模式比原生MCP客户端更易于与既有基础设施融合。

自动化运维工程师：依赖pm2等进程管理工具维持服务稳定性的场景，自动重启机制和CLI管理界面符合DevOps实践习惯。

安全敏感型个人开发者：对第三方依赖持谨慎态度，偏好纯原生模块实现以降低攻击面，愿意承担T3来源风险的自托管用户。

常规使用风险

性能层面：每个MCP服务器作为独立子进程运行，高并发场景下进程间通信开销显著；1MB请求体限制不适用于大规模文件传输场景；缺乏内置负载均衡机制，单实例存在瓶颈。

依赖项风险：虽本体零依赖，但注册的MCP服务器本身可能引入大量npm包，需独立审计各服务器的供应链安全；pm2等外部进程管理器成为隐性依赖，其版本漏洞可能影响服务可用性。

运维复杂性：配置文件持久化存储敏感信息，备份和迁移时易泄露；审计日志缺乏自动轮转机制，长期运行可能导致磁盘耗尽；多服务器场景下故障隔离和监控需自行实现。

兼容性风险：MCP协议处于快速迭代期，桥接层对协议变更的适应能力取决于维护者更新频率；T3级别来源意味着长期维护承诺存在不确定性，关键业务场景建议fork后自主维护。