Best MCP Servers for WorkBuddy: Data and Tool AccessWorkBuddy 最佳 MCP Server：数据与工具接入指南
Compare MCP servers for WorkBuddy by capability fit, permissions, data quality, setup effort, and production reliability.
从能力匹配、权限、数据质量、配置成本和生产可靠性，对比适合 WorkBuddy 的 MCP Server。
快速结论：先补齐一项缺失能力
适合 WorkBuddy 的 MCP Server 包括：用于受限本地知识访问的 Filesystem、用于代码仓库协作的 GitHub、用于浏览器操作的 Playwright、用于结构化数据的 PostgreSQL 或 Supabase、用于轻量网页读取的 Fetch、用于日历与文档流程的 Google Workspace、用于团队上下文的 Slack，以及在确实需要持久图谱记忆时使用的 Memory。多数用户只需从两个开始：一个事实来源，加一个执行界面。
这不是虚构测试分数的排行榜。本文所说的“最佳”，是指 Server 在 WorkBuddy 工作流中职责清晰、权限边界可检查、维护方文档可用，并且发生错误后可以恢复。WorkBuddy 本身已通过 MCP 网关提供能力发现与执行，因此只有当外部 Server 能新增数据来源或操作能力时，接入才有价值。
我们如何筛选 WorkBuddy MCP Server
工作流契合度
Server 必须能支持重复出现的检索、检查、转换或执行任务。
权限清晰度
文件根目录、仓库、项目、网页来源和 OAuth 范围应当可见且可收窄。
来源质量
我们优先采用官方或维护方文档，而不是注册表热度与转载配置。
运行控制
实用 Server 应提供可预测的工具、可理解的失败状态和安全的只读起点。
| # | Server | 最适合 | 风险边界 | 何时安装 |
|---|---|---|---|---|
| 1 | Filesystem | 本地文件与知识 | 允许的根目录 | 内置访问无法触达所需目录 |
| 2 | GitHub | Issues, PRs, code | 令牌与仓库范围 | 协作主要在 GitHub |
| 3 | Playwright | 浏览器工作流 | 来源与会话 | 任务必须操作网页界面 |
| 4 | PostgreSQL / Supabase | 结构化数据 | 角色与项目 | 问题需要实时数据库证据 |
| 5 | Fetch | 简单 URL 读取 | 网络目标 | 只需文本而非交互 |
| 6 | Google Workspace | 日历、云端硬盘、文档 | OAuth scopes | WorkBuddy 需要协调办公资料 |
| 7 | Slack | 团队上下文与消息 | 工作区与频道范围 | 决策散落在团队对话中 |
| 8 | Memory | 持久实体关系 | 保留策略与敏感数据 | WorkBuddy 自带知识仍不足 |
适合 WorkBuddy 的 8 个 MCP Server
Filesystem MCP
最佳本地基础Filesystem 让 WorkBuddy 在指定目录内执行读取、写入、搜索、移动和元数据操作。当工作流跨越项目文件夹、导出报告、参考文档或本地知识库时，它是最通用的基础能力。它的优势也是风险：过宽的根目录会让一个聚焦助手变成整台机器的文件操作员。
建议从一个项目目录开始，并尽量只读。参考实现支持 MCP Roots；当客户端支持该协议能力时，可动态替换服务端允许列表。启用写入或删除前，应确认最终生效的目录范围。该仓库属于供评估与加固的参考实现，不等于对生产环境的默认背书。
GitHub MCP Server
最适合软件团队GitHub MCP 把仓库、Issue、Pull Request、代码搜索与协作对象转化为结构化工具。WorkBuddy 因而可以收集 Issue 上下文、检查仓库、拟定变更计划并汇报状态，而不必抓取网页。应使用仓库允许列表或细粒度凭证，并区分读取与修改操作。
当 GitHub 是事实来源时再安装。若只需读取公开 README，Fetch 更轻量。合并、推送、评审和修改 Issue 等动作应始终经过明确授权。
Playwright MCP
最适合浏览器操作当 WorkBuddy 工作流需要导航、填写表单、捕获页面状态或验证端到端流程时，Playwright MCP 是合适选择。它基于结构化可访问性信息执行操作，而不是只依赖截图，因此更容易检查。建议使用独立自动化浏览器配置，并限制哪些来源可以接收凭证。
需要交互时选择它。若只是读取文章或文档，应优先使用 Fetch；若需要深入的性能与网络诊断，则浏览器 DevTools 类 Server 更合适。
PostgreSQL or Supabase MCP
最适合结构化数据数据库 Server 让 WorkBuddy 用实时证据回答运营问题，而不依赖过期导出。若需要范围明确的数据库原生连接，可选择 PostgreSQL；若工作流还需要 Supabase 项目上下文和平台操作，则选择 Supabase MCP。两种情况下都应创建专用最小权限角色，从开发数据开始，并优先只读查询。
数据库文本属于不可信输入。某行数据可能包含试图影响模型的指令，因此检索内容绝不能覆盖工作流策略或工具权限。
Fetch MCP
最佳轻量网页读取Fetch 可读取 URL，并把有用页面内容转换为适合模型处理的文本。它适合检查文档、收集来源和总结公开页面，前提是不需要登录或交互。与完整浏览器自动化相比，它的组件更少、操作面也更小。
返回内容仍须视为不可信输入，同时限制网络目标并阻止内部元数据或私有网络端点。当结果取决于 JavaScript 状态、认证或交互时，Fetch 不能替代浏览器。
Google Workspace MCP servers
最适合日历与文档Google Workspace 为不同 Workspace 产品分别提供远程 MCP Server，可把日历事件、Drive 文件、Docs 等办公资料接入 WorkBuddy 工作流。这适合准备会议简报、定位支持文档，或把已批准的笔记转化为后续日程。由于 WorkBuddy 已具备日历与知识集成，应先找出缺失操作，避免同一账号存在多个平行连接器。
真正的边界是 OAuth 授权。只申请工作流所需的 API 与范围，区分个人和组织账号，并在发送邀请或编辑共享文档前要求确认。
Slack MCP Server
最适合团队上下文当决策、请求和事故上下文散落在频道而非正式文档中时，Slack 官方 MCP Server 很有价值。WorkBuddy 可通过受限连接收集相关对话上下文、生成简报或起草待确认回复。搜索和读取比发消息等修改操作更适合作为起点。
应限制工作区与频道可见范围、保留来源链接、考虑 Slack API 速率限制；不要因为某条消息较新就把它当作权威政策。发送消息属于外部副作用，必须经过授权。
Memory MCP
最适合持久关系记忆Memory 可跨会话保存实体、观察与关系，适合保留稳定的项目词汇或不适合平面笔记的关系。但 WorkBuddy 已有知识库，因此只有在需要独立图谱模型、隔离边界或交换格式时，额外的 Memory Server 才有意义。
写入前应定义保留、删除、纠错和敏感数据规则。不要把整个对话无差别塞入不可见记忆；持久上下文应经过筛选，可追溯、可复核。
按工作流选择 WorkBuddy MCP 组合
研究助手
Fetch + Filesystem。 收集公开来源、保存限定范围内的产物并保留引用。只有交互网站才加 Playwright。
研发协调助手
GitHub + Filesystem。 把 Issue 上下文连接到本地项目产物；需要端到端验证时再加 Playwright。
运营分析助手
PostgreSQL/Supabase + Workspace。 查询受治理数据、生成简报，并安排经批准的后续事项。
团队知识助手
Slack + WorkBuddy 知识库。 将决策提炼成精选知识，而不是永久保留每条消息。
WorkBuddy 的安全配置方法
- 说明缺失能力。 写出一个代表性任务，以及所需输入、动作和输出。
- 检查 WorkBuddy 现有能力。 添加新连接器前先搜索网关和知识库，避免重复。
- 选择最小 Server。 静态文本优先 Fetch 而非浏览器，数据库优先只读访问而非管理 API。
- 限制身份与资源。 收窄根目录、仓库、项目、网页来源、频道、OAuth 范围和网络目标。
- 测试四条路径。 验证成功、拒绝操作、非法输入和服务宕机，并确认重试不会重复产生副作用。
- 观察并精简。 记录工具名、结果状态、延迟、授权和错误类型，但不保存原始密钥；移除无法改善代表性任务的工具。
WorkBuddy 文档说明可通过 wb_search 发现能力，并通过 wb_run 执行。请参考其 手册与 MCP 网关说明，并以此作为当前配置的事实来源。
WorkBuddy MCP 安全检查清单
- 每个连接器使用专用身份，绝不复用管理员凭证。
- 默认采用只读工具与开发数据，修改操作必须明确授权。
- 限制文件根目录、仓库、数据库项目、浏览器来源、频道和出站主机。
- 将网页、Issue、消息、文件和数据库行视为可能携带提示注入的不可信内容。
- 固定或审核包版本，并在执行 MCP 包前核实维护方。
- 密钥保存在环境变量或合规密钥库中，绝不写入提示或共享配置。
- 记录授权与操作影响，但不收集不必要的消息正文、个人数据或凭证。
- 所有产生外部副作用的工具都应定义超时、重试、幂等与回滚策略。
常见问题
WorkBuddy 支持 MCP 吗？
支持。WorkBuddy 将 MCP 网关作为智能体的主要接口；能力可通过网关发现与执行，工作流则提供多步骤依赖顺序和持久状态。
应该先添加哪个 MCP Server？
应先添加能提供缺失事实来源的 Server。本地产物可从受限 Filesystem 开始；若核心任务是仓库协作，则 GitHub 更合适。添加前先检查 WorkBuddy 的现有能力。
WorkBuddy 应使用 Playwright 还是 Fetch？
读取公开文本时用 Fetch；必须与页面状态、表单或认证流程交互时用 Playwright。能力更小的工具通常更容易保护和运维。
自动批准整个 MCP Server 安全吗？
默认不安全。应先批准指定的只读操作；只有在验证输入、影响、错误处理及工作流抵御不可信内容的能力后，才扩大授权范围。
WorkBuddy 应使用多少个 MCP Server？
没有统一数字。每条工作流先使用一到两个。当工具重叠、选择不稳定、授权提示过多，或延迟增加却没有改善结果时，说明数量已经过多。
为 WorkBuddy 配置最小但够用的访问层
先选定一项缺失能力，核对服务商与权限边界，再测试完整工作流，确认有效后再扩展。