使用说明
MCP编排器
具有健康监测和管理功能的多MCP编排平台
这 MCP编排器 是一个生产就绪平台,使LLM(Claude、Gemini、OpenAI)能够同时与多个模型上下文协议(MCP)服务器交互。它具有自动健康监测、弹性模式和综合管理工具。
🌟 主要特点
多MCP支持
- 多个MCP服务器:同时连接到无限制的MCP服务器
- 工具聚合:自动组合来自所有连接的MCP的工具
- 多个工具调用:顺序批准与并行执行,以实现最佳性能
- 智能命名空间:使用可配置前缀自动解决冲突
- 运输灵活性:支持HTTP、stdio、SSE和Docker传输
健康监测和弹性
- 自动健康检查:定期监测(间隔60秒)
- 自动重新连接:断路器模式的指数回退
- 状态跟踪:实时健康状态(健康/不健康/重新连接/断开连接)
- 事件驱动架构:实时对健康变化做出反应
管理工具
- CLI接口:完成
llmMCP管理的命令行工具 - Web仪表板:可视化监控和管理,实时更新
- 基于Web的MCP创建:通过图形形式添加新的MCP服务器(无需CLI)
- REST API:通过程序访问健康状态、指标和MCP创建
- 互动提示:用户友好的MCP配置(CLI和Web)
多LLM支持
- 谷歌双子座:2.0 Flash、1.5 Flash、1.5 Pro
- 安thropic克劳德:十四行诗4.5,作品4.6,俳句4.5
- 开放人工智能:GPT-4o、GPT-4oMini、GPT-4 Turbo
- 运行时切换:更改型号而不重新启动
安全与隔离
- Docker沙盒:每个MCP的独立容器
- 资源限制:可配置内存(512MB)和CPU(0.5核)
- 循环中的人类:工具审批工作流程
- 会话管理:每个用户的安全、隔离的工作区
✨ 最新动态
多工具调用支持 -LLM现在可以同时请求多个工具!编排器处理:
- 顺序批准:每次展示一个工具,并附有明确的进度指标(1/3、2/3等)
- 并行执行:一旦所有工具都获得批准,它们将同时执行以获得最佳性能
- 智能队列管理:基于结果的后续工具得到正确保存和处理
- 视觉反馈:UI显示队列位置和剩余审批的等待状态
基于Web的MCP创建 -现在,您可以直接通过web界面添加MCP服务器,而无需使用CLI!只需单击MCP管理选项卡中的“+添加MCP”按钮,即可使用支持所有传输类型(HTTP、SSE、Stdio、Sttio Docker)的用户友好图形表单创建新服务器。
HTTP/SSE传输支持 -完全支持基于HTTP和SSE的MCP服务器。使用服务器发送事件或REST API连接到远程MCP服务器。
持久配置 -MCP配置现在通过Docker卷、幸存的容器重启和重建进行持久化。
📚 文档
🚀 快速开始
先决条件
- Docker&Docker编写 安装
- Node.js 22+ (用于地方发展)
- 所选LLM提供商的API密钥
1.配置
创建一个 .env 根目录中的文件:
# LLM Provider Selection
LLM_PROVIDER=claude # choices: gemini, claude, openai
GEMINI_API_KEY=your_key_here
ANTHROPIC_API_KEY=your_key_here
OPENAI_API_KEY=your_key_here
# LLM Response Configuration (Optional)
MAX_OUTPUT_TOKENS=8192 # Max tokens for LLM responses (default: 8192)
MAX_HISTORY_TOKENS=30000 # Max tokens in conversation history (default: 30000)
2.启动系统
docker compose up --build
这将开始:
- MCP编排器(端口3000)
- Redis(会话管理)
- 默认文件系统MCP服务器
3.访问界面
Web仪表板: http://localhost:3000
- 💬 聊天选项卡:使用MCP工具与LLM交互
- 🔧 MCP管理选项卡:监测健康状况并管理MCP
CLI访问:
# Enter the container
docker exec -it mcp-orchestrator-app-1 sh
# Or run commands directly
docker exec mcp-orchestrator-app-1 npm run llm -- mcp list
🛠️ MCP管理命令行界面
用于管理MCP服务器的完整命令行界面:
列出MCP
llm mcp list # Show all registered MCPs
llm mcp list --enabled # Show only enabled MCPs
llm mcp list --format json # Output as JSON
添加MCP服务器
# Interactive mode
llm mcp add
# Non-interactive with flags
llm mcp add filesystem \
--transport stdio-docker \
--image mcp-server:latest \
--description "File system operations"
# HTTP/SSE transport
llm mcp add api-server \
--transport http \
--url http://mcp-api:8080 \
--description "External API MCP"
# Local stdio transport
llm mcp add local-mcp \
--transport stdio \
--command node \
--args "dist/mcp-server.js" \
--description "Local Node.js MCP"
管理MCP
llm mcp enable <name> # Enable an MCP
llm mcp disable <name> # Disable without removing
llm mcp remove <name> # Remove MCP (with confirmation)
llm mcp remove <name> -y # Skip confirmation
健康与检测
llm mcp health # Check health of all MCPs
llm mcp test <name> # Test connection to specific MCP
llm mcp info <name> # Show detailed MCP information
📊 Web仪表板
web界面提供实时监控和管理:
特性
- 总结卡:总计、健康和问题计数
- 添加MCP服务器:通过图形形式创建新的MCP配置
- MCP列表:每台服务器的实时运行状况
- 状态指示灯:
- ✓ 健康的 (绿色):MCP响应正常
- ⚠ 不健康的 (红色):健康检查失败
- ↻ 重新连接 (黄色):正在尝试恢复
- ✗ 断开连接 (灰色):已达到最大重试次数
- 时间戳:上次检查和上次成功次数
- 错误详细信息:失败的MCP的详细错误消息
- 手动刷新:按需更新健康状况
通过Web UI添加MCP
- 打开http://localhost:3000
- 点击“🔧 MCP管理”选项卡
- 点击 “+添加MCP” 按钮(绿色按钮)
- 填写表格:
- 名字:唯一标识符(字母、数字、连字符、下划线)
- 运输类型:选择HTTP、SSE、Stdio或Stdio Docker
- 运输特定领域:基于传输的URL、命令或容器图像
- 描述 (可选):MCP服务器的简要说明
- 附加选项:标头(HTTP/SSE)、参数(stdio)或资源限制(Docker)
- 点击 “添加MCP服务器”
- 新MCP会自动出现在列表中
Web UI中的传输类型
HTTP/SSE:
- URL(必填):
https://example.com/mcp - 自定义标头(可选):添加键值对
工作室:
- 命令(必填):
node - 参数(可选):
server.js --port 3000 - 工作目录(可选):
/app
标准Docker:
- 容器图像(必填):
mcp-server:latest - 内存限制(可选):
512兆字节 - CPU限制(可选):
0.5核心
导航
- 打开http://localhost:3000
- 提示时输入API键
- 点击“🔧 MCP管理”选项卡
- 查看实时健康仪表板或添加新的MCP
🔌 API终点
健康状况
GET /api/mcp/health
退货:
{
"summary": {
"total": 1,
"healthy": 1,
"unhealthy": 0,
"reconnecting": 0,
"disconnected": 0
},
"mcps": [
{
"name": "filesystem",
"status": "healthy",
"lastCheck": 1770827144464,
"lastSuccess": 1770827144464,
"consecutiveFailures": 0
}
]
}
添加MCP服务器
POST /api/mcp/add
Content-Type: application/json
请求正文:
{
"name": "my-mcp",
"config": {
"transport": "http",
"url": "https://example.com/mcp",
"enabled": true,
"description": "My MCP server"
}
}
响应:
- 201:成功-
{"message": "MCP server added successfully", "name": "my-mcp"} - 400:验证错误-
{"error": "Name can only contain letters, numbers, hyphens, and underscores"} - 409:重复-
{"error": "MCP server 'my-mcp' already exists"} - 500:服务器错误-
{"error": "Error message"}
模型检测
GET /api/models/available # Get accessible models
GET /api/models/check # Diagnostic model testing
🎯 可用的MCP工具
默认文件系统MCP提供:
| 工具 | 说明 | 示例使用 |
|---|---|---|
read_file |
读取文件内容 | 查看配置文件 |
write_file |
写入文件 | 创建或更新文件 |
list_files |
列出目录内容 | 浏览工作区 |
execute_command |
运行bash命令 | 安装包,运行脚本 |
⚙️ LLM响应配置
编排器提供可配置的令牌限制,以优化LLM响应并防止上下文窗口溢出:
MAX_OUTPUT_TOKENS
控制LLM响应的最大长度。
- 默认:8192个令牌(约32000个字符)
- 目的:允许无截断的全面响应
- 影响:更高的值增加了API成本,但确保了完整的响应
- 范围:1024-8192个代币(克劳德十四行诗最多4.5个)
示例:设置为4096,以缩短响应时间并降低成本:
MAX_OUTPUT_TOKENS=4096
MAX_HISTORY_TOKENS
控制发送到LLM的对话历史记录大小。
- 默认:30000个代币
- 目的:平衡上下文保留与令牌预算
- 上下文窗口预算 (总计200k):
- 历史:30000个代币
- 工具定义:8-10万个令牌(包含许多MCP)
- 当前提示:5-10k代币
- 响应缓冲区:5k个令牌
- 净空:约55k代币
为什么是30k? 连接多个MCP后,工具定义可能会消耗80-100k+令牌。历史限制必须在Claude的200k上下文窗口内为工具、提示和响应留出空间。
示例:长时间对话时增加(如果您的MCP较少):
MAX_HISTORY_TOKENS=50000
对话管理
系统自动:
- 截断历史 当它超过MAX_HISTORY_TOKENS(保留最新消息)时
- 清除历史记录 如果总输入(历史记录+工具+提示)超过上下文窗口
- 压缩消息 当启用ENABLE_CONVERSION_COMPRESSION时
- 过期会话 24小时不活动后(可通过HISTORY_TTL_SECONDS配置)
令牌错误故障排除
“提示太长”错误:
- 减小MAX_HISTORY_TOKENS(默认值:30000)
- 启用对话压缩:
ENABLE_CONVERSATION_COMPRESSION=true - 禁用未使用的MCP以减少工具定义标记
- 刷新页面以清除对话历史记录
答案在句子中间截断:
- 增加MAX_OUTPUT_TOKENS(默认值:8192)
- 检查API提供程序的输出令牌限制
🔄 多工具调用工作流
当LLM需要使用多种工具(例如,读取多个文件或查询多个API)时,编排器提供了一个优化的审批和执行工作流:
运作原理
- LLM请求:LLM在单个响应中返回多个工具调用
- 队列管理:所有工具调用都存储在具有状态跟踪的队列中
- 顺序批准:一次展示一个工具供用户批准
- 明确的进度指标:“工具批准请求(1/3)”
- 用户可以单独批准或拒绝每个工具
- 并行执行:一旦所有工具都获得批准,它们就会同时执行
- 结果聚合:收集结果并发送回LLM
- 后续处理:如果LLM需要基于结果的其他工具,则循环将继续
示例场景
User: "Read package.json, README.md, and check the git status"
Orchestrator:
├─ Approval Request (1 of 3): read_file(package.json) → ✓ Approved
├─ Approval Request (2 of 3): read_file(README.md) → ✓ Approved
├─ Approval Request (3 of 3): execute_command(git status) → ✓ Approved
│
├─ [Parallel Execution]
│ ├─ read_file(package.json) ✓ Complete
│ ├─ read_file(README.md) ✓ Complete
│ └─ execute_command(git status) ✓ Complete
│
└─ Results sent to LLM → LLM analyzes and responds
好处
- 用户控件:在完整的上下文中单独批准每个工具
- 演出:并行执行最大限度地减少了等待时间
- 可靠性:智能队列管理可防止工具丢失
- 透明度:清晰地了解多工具工作流程
📁 配置文件
MCP配置在 mcp-config.json:
{
"mcpServers": {
"filesystem": {
"transport": "stdio-docker",
"containerImage": "mcp-server:latest",
"enabled": true,
"description": "Local file system operations",
"toolPrefix": "fs"
}
},
"settings": {
"autoConnect": true,
"healthCheckInterval": 60000,
"toolNamespacing": "auto"
}
}
运输类型
stdio docker:
{
"transport": "stdio-docker",
"containerImage": "mcp-server:latest",
"containerEnv": { "VAR": "value" },
"containerMemory": 512,
"containerCpu": 0.5
}
http/sse:
{
"transport": "sse",
"url": "http://mcp-server:8080/sse",
"headers": { "Authorization": "Bearer ${API_KEY}" },
"timeout": 30000
}
备注:基于SSE的MCP服务器通常需要特定的端点路径(例如。, /sse).检查MCP服务器的文档以获取正确的URL。
标准:
{
"transport": "stdio",
"command": "node",
"args": ["dist/server.js"],
"env": { "NODE_ENV": "production" },
"cwd": "/app"
}
命名空间策略
auto(默认):仅当连接了多个MCP时才应用前缀prefix:始终将MCP名称用作前缀(例如。,filesystem_read_file)none:无前缀(如果存在冲突,最后一个MCP获胜)
🏗️ 建筑
┌─────────────────────────────────────────────┐
│ Web UI (Vue 3 + TailwindCSS) │
│ ┌──────────┐ ┌─────────────────────────┐ │
│ │ Chat Tab │ │ MCP Management Dashboard │ │
│ └──────────┘ └─────────────────────────┘ │
└────────────────────┬────────────────────────┘
│
┌────────────────────┴────────────────────────┐
│ HTTP API & Socket.IO Server │
└────────────────────┬────────────────────────┘
│
┌────────────────────┴────────────────────────┐
│ MCPHealthMonitor │
│ (Periodic checks + Auto-reconnection) │
└────────────────────┬────────────────────────┘
│
┌────────────────────┴────────────────────────┐
│ MCPConnectionManager │
│ (Multi-MCP aggregation & routing) │
└────────────────────┬────────────────────────┘
│
┌──────────────┼──────────────┐
│ │ │
┌───┴───┐ ┌───┴───┐ ┌───┴───┐
│ MCP 1 │ │ MCP 2 │ │ MCP 3 │
│Docker │ │Docker │ │ HTTP │
└───────┘ └───────┘ └───────┘
关键组件
MCPConnectionManager
- 管理多个MCP连接
- 使用命名空间聚合工具
- 将工具调用路由到正确的MCP
- 处理连接生命周期
MCPHealthMonitor
- 定期健康检查(间隔60秒)
- 带回退功能的自动重新连接
- 断路器模式(3次故障)
- 事件驱动的状态更新
MCP注册表
- 配置管理
- MCP的CRUD操作
- 启用/禁用功能
- 环境变量插值
运输工厂
- 创建适当的传输实例
- 支持多种传输协议
- 配置驱动初始化
🔐 安全功能
- 集装箱隔离:每个MCP都在隔离的Docker容器中运行
- 资源限制:可配置的内存和CPU限制
- 工具批准:敏感操作的人工参与
- 会话管理:每个用户的独立工作区
- 无网络访问:默认情况下,容器在没有网络的情况下运行
- 环境变量:使用插值进行安全的秘密处理
🧪 发展
本地开发
# Install dependencies
npm install
# Build TypeScript
npm run build
# Development mode with watch
npm run dev
运行测试
npm test
构建MCP服务器映像
docker build -t mcp-server:latest -f Dockerfile.mcp .
📈 监测和可观察性
健康检查
- 每60秒自动定期检查一次
- 通过CLI或API进行手动运行状况检查
- 仪表板中的实时状态更新
- 连续故障跟踪
状态指示灯
- 健康的:所有健康检查均通过
- 不健康的:健康检查失败(<3次失败)
- 重新连接:正在尝试自动恢复
- 断开连接:已达到最大重新连接尝试次数
事件日志记录
[MCPHealthMonitor] Started with interval 60000ms
[MCPConnectionManager] Connected to MCP: filesystem
[Agent session-xyz] Connected to MCPs: [ 'filesystem', 'api-server' ]
[MCPHealthMonitor] MCP 'filesystem' is now healthy
🤝 贡献
欢迎投稿!拜托:
- 分叉存储库
- 创建要素分支
- 进行更改
- 提交拉取请求
📝 许可证
该项目根据MIT许可证获得许可。
🆘 故障排除
MCP未连接
# Check MCP status
llm mcp health
# Test specific MCP
llm mcp test <name>
# View detailed info
llm mcp info <name>
# Check container logs
docker logs mcp-orchestrator-app-1
健康检查失败
- 验证MCP容器是否正在运行:
docker ps - 检查容器日志是否有错误
- 手动测试连接:
llm mcp test <name> - 尝试重新连接:禁用然后启用MCP
工具执行错误
- 检查工具可用:
llm mcp info <name> - 验证MCP是否健康:
llm mcp health - 查看日志中的错误消息
- 检查容器资源限制
MCP工具未出现在聊天中
如果你添加了一个新的MCP,但它的工具没有出现在你的聊天会话中:
- 刷新浏览器页面 -聊天会话在初始化时加载MCP
- 检查MCP是否正常🔧 MCP管理选项卡
- 查找连接错误:
docker logs mcp-orchestrator-app-1 | grep -i "failed" - 对于SSE/HTTP MCP。,
/sse)
🔗 相关项目
建于❤️ 使用TypeScript、Docker和模型上下文协议
