Slack MCP 服务器

要解决的问题

AI Agent 要真正参与团队协作，就不能只停留在「读文档、写代码」这一步。当需求来自 Slack 频道里的一条讨论、一次工单跟进，或一个跨频道的审批流时，Agent 需要能直接触及工作区里的会话与流程。难点在于：Slack 有自己的 API 体系、权限模型和事件机制，Agent 侧又有 MCP 客户端/宿主环境的约束，两者之间需要一层稳定的桥接。

这个技能要填的正是这个位置：让 Agent 以统一接口访问 Slack 的会话内容和工作区工作流，而不是针对每个场景手写一套集成。

它是如何工作的

技能以 MCP 服务器的形式运行，核心链路可以拆成三步：

• 能力暴露：把 Slack 的会话读取与工作流操作封装为 MCP 可调用的能力，MCP 宿主在运行时按需发现和调用。
• 身份与鉴权：上游实现基于 Python MCP SDK，并通过 MCP Plexus 这类多租户框架提供 OAuth 2.1 授权，让外部服务的接入带上租户隔离和可扩展的认证边界。mxcp 等框架则允许用 YAML、SQL 加 Python 的方式描述服务，内置认证、监控与策略执行。
• 客户端接入：运行时只需要一个 MCP 客户端/宿主，配合 Slack 工作区或应用凭证即可完成对接。

需要注意，这些服务器本质上是参考实现：它们演示 MCP 特性和 SDK 的用法，面向的是想自己搭建 MCP 服务器的开发者，而不是开箱即用的生产组件。

适用边界与注意点

• 它解决的是「Agent 到 Slack 的通道」，不替代 Slack 自身的权限体系，频道可见性仍取决于应用被授予的范围。
• 上游文档强调其教育属性，代码和配置需要自己审阅、改造后再用于真实工作区。
• 多租户、策略执行、监控等能力依赖所选的框架实现，选型时要看清这些组件各自的成熟度。
• 会话类能力涉及敏感内容，建议先在小范围测试，确认日志、缓存和权限边界符合团队要求。