Skip to main content

概述

MCPHub 的分组管理功能允许您根据功能、用例或访问要求将 MCP 服务器组织成逻辑集合。这使您能够对不同的 AI 客户端和用户可用的工具进行精细控制。

核心概念

什么是分组?

分组是可通过专用端点访问的 MCP 服务器的命名集合。AI 客户端可以连接到特定分组以仅访问相关工具,而不是一次性连接到所有服务器。

分组的优势

  • 聚焦工具访问: AI 客户端只看到与其用例相关的工具
  • 更好的性能: 减少工具发现开销
  • 增强安全性: 限制对敏感工具的访问
  • 改进组织: 功能的逻辑分离
  • 简化管理: 更容易一起管理相关服务器

创建分组

通过仪表板

  1. 导航到分组部分: 在主导航中点击”分组”
  2. 点击”创建分组”: 开始分组创建流程
  3. 填写分组详细信息:
    • 名称: 分组的唯一标识符
  4. 添加服务器: 选择要包含在分组中的服务器

通过 API

以编程方式创建分组:

分组类型和用例

用途: 浏览器自动化和网页抓取服务器:
  • playwright: 浏览器自动化
  • fetch: HTTP 请求和网页抓取
  • selenium: 替代浏览器自动化
用例:
  • 自动化测试
  • 数据收集
  • 网页监控
  • 内容分析
端点: http://localhost:3000/mcp/web-automation
用途: 数据操作和分析服务器:
  • sqlite: 数据库操作
  • filesystem: 文件操作
  • spreadsheet: Excel/CSV 处理
用例:
  • 数据分析
  • 报告生成
  • 文件处理
  • 数据库查询
端点: http://localhost:3000/mcp/data-processing
用途: 消息传递和协作服务器:
  • slack: Slack 集成
  • discord: Discord 机器人
  • email: 邮件发送
  • sms: 短信通知
用例:
  • 团队通知
  • 客户沟通
  • 警报系统
  • 社交媒体管理
端点: http://localhost:3000/mcp/communication
用途: 软件开发工具服务器:
  • github: GitHub 操作
  • gitlab: GitLab 集成
  • docker: 容器管理
  • kubernetes: K8s 操作
用例:
  • 代码部署
  • 仓库管理
  • CI/CD 操作
  • 基础设施管理
端点: http://localhost:3000/mcp/development
用途: 机器学习和 AI 工具服务器:
  • openai: OpenAI API 集成
  • huggingface: Hugging Face 模型
  • vector-db: 向量数据库操作
用例:
  • 模型推理
  • 数据嵌入
  • 自然语言处理
  • 计算机视觉
端点: http://localhost:3000/mcp/ai-ml

分组端点

访问分组

每个分组都有自己的 MCP 端点:
示例:
  • http://localhost:3000/mcp/web-tools
  • http://localhost:3000/mcp/data-processing
  • http://localhost:3000/mcp/communication

分组工具发现

当连接到分组端点时,AI 客户端将只看到该分组内服务器的工具:
响应将只包含来自 fetch 和 playwright 服务器的工具。

动态分组管理

向分组添加服务器

  1. 在仪表板中导航到分组
  2. 点击”管理服务器”
  3. 选择要添加的其他服务器
  4. 点击”保存更改”

从分组中移除服务器

  1. 在仪表板中导航到分组
  2. 点击”管理服务器”
  3. 取消选择要移除的服务器
  4. 点击”保存更改”

最佳实践

分组组织

按用例组织: 根据用户想要完成的任务来组织服务器分组,而不仅仅是技术相似性。
保持分组聚焦: 避免创建包含太多不同工具的分组。更小、更聚焦的分组更有用。
使用描述性名称: 选择能清楚表明分组目的和内容的名称。

性能优化

平衡分组大小: 非常大的分组可能导致工具发现较慢。考虑拆分为更小的分组。
监控使用情况: 使用分析来识别哪些分组被大量使用并相应优化。

故障排除

检查:
  • 用户具有适当权限
  • 分组存在且处于活跃状态
  • 分组中的服务器正在运行
  • 网络连接
解决方案:
  1. 验证用户分组成员身份
  2. 检查分组配置
  3. 测试单个服务器连接
  4. 查看访问日志
可能原因:
  • 服务器未正确添加到分组
  • 服务器未运行
  • 工具发现失败
  • 缓存问题
调试步骤:
  1. 验证服务器在分组配置中
  2. 检查服务器状态
  3. 强制刷新工具发现
  4. 清除分组缓存
常见问题:
  • 分组中服务器过多
  • 服务器响应慢
  • 网络延迟
  • 资源约束
优化方案:
  1. 拆分大型分组
  2. 监控服务器性能
  3. 实施请求缓存
  4. 使用连接池

下一步

智能路由

跨分组的 AI 驱动工具发现

身份认证

用户管理和访问控制

API 参考

完整的分组管理 API

配置

高级分组配置选项

可见性与共享

新建组默认使用 private。visibility 支持 private(所有者和管理员)、 group(所有者、管理员及 sharedWithUsers 中指定的用户名)和 public(所有用户)。 界面将 group 显示为共享;请先保存组,再在编辑界面选择用户。 只有所有者和管理员可以修改、删除组及其服务器配置。 以用户身份访问 MCP 时,必须同时满足组和服务器的可见性要求,历史组按下文的兼容规则处理。 共享组不会赋予用户原本无权访问的服务器的访问权。SSE 和 $smart/<group> 路由也遵循 这些检查,已有会话的后续请求会重新检查组权限。 用户密钥(kind: 'user')继承所属用户的实时权限,不支持独立的密钥范围。 API 创建用户密钥时固定使用 accessType: 'all',并清空 allowedGroups/allowedServers; 运行时这些范围字段不会限制用户密钥。这里的 all 指用户有权访问的资源,不代表系统级无限制访问。 系统密钥(kind: 'system')按配置的操作员权限范围访问,不应用基于用户的组或服务器可见性限制。 因此,accessType: 'all' 的系统密钥可以访问私有组和私有服务器;限定范围的系统密钥仍受其 配置范围约束。系统密钥不会建立用户身份或提供个人凭证。 组列表、详情和服务器配置响应会隐藏调用者无权访问的服务器,包括名称、别名及能力选择。 所有者保存可见服务器列表时,已有的隐藏条目会保留;管理员可以管理完整配置。

历史组升级

未设置可见性的组保留旧端点规则:知道端点的用户可以使用其中有权限的服务器, 目录仍仅对所有者和管理员可见。界面会提示设置可见性;仅保存其他字段不会将历史组 自动改为私有或公开。 数据库模式为组名添加唯一约束。启动时会在同步结构前检查重复组名,发现重复时停止升级, 报告名称和数量。请手动处理冲突后重启;系统不会自动重命名或删除组。 私有组同样占用全局组名,无法自行解决的冲突需联系管理员。