slack-mcp-server：用会话 cookie 绕过 Slack 权限体系的 MCP 服务端
The most powerful MCP Slack Server with no permission requirements, Apps support, GovSlack, DMs, Group DMs and smart history fetch logic.
秒懂
- 它是什么？
- korotovsky/slack-mcp-server 用 Go 写了一个 Slack 的 MCP 服务端，卖点是不装 App、不要 scope 也能读消息。本文拆解它的两种认证模式、分页机制、默认关闭的写操作，以及 stealth 模式带来的真实代价。
- 适合谁用？
- 如果你需要让 LLM 助手快速读取一个自己已经登录的 Slack 工作区，又不想走 App 审批流程，stealth 模式是这个项目唯一值得看的理由。如果你需要长期稳定运行、需要写操作、或者工作区有合规审计要求，不要选它，OAuth 模式下的 Slack 官方 App 审批虽然慢，但 token 不会因为一次浏览器登出而失效。
- 能商用吗？
- 可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 61 天前。
- 用什么语言写的？
- 主要是 Go（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它绕开的不是 Slack 的 API，是 Slack 的 App 审批
Slack 的常规集成路径是建 App、申请 scope、等管理员批准、拿 bot token 或 user token。对一个只想让本地 LLM 读几条频道消息的工程师来说，这条路径的成本远高于收益。这个项目给出的替代方案叫 stealth 模式：README 的原话是可以在 no permissions and scopes 的状态下运行，做法是复用你在浏览器里已经登录的会话凭据，而不是走 OAuth 授权流程。另一条路是 OAuth 模式，README 强调它 access without needing to refresh or extract tokens from the browser，也就是不需要你手动从浏览器里抠 token 或者反复刷新。目标用户很明确：已经在 Slack 里、只想把已有访问权限转给一个 MCP 客户端的人。它不是给要发布到整个组织、需要审计日志的团队准备的。
四个工具，参数设计暴露了取舍
服务端暴露的工具是 conversations_history、conversations_replies、conversations_add_message、conversations_search_messages。channel_id 这个参数值得单独说：它接受 Cxxxxxxxxxx 形式的 ID，也接受 #general 或 @username_dm 这种名字写法，README 明确写了 by channel_id 的取值同时支持 ID 和名字。这个设计省掉了先查 channel list 再取 ID 的一步。分页用的是游标，规则很直白：把上一次响应里最后一行的最后一列拿回来当 cursor 传进去；而且 limit 在传了 cursor 的时候必须为空，这是硬约束，不是建议。limit 的取值有两种语义，一种是时间范围（1d、1w、30d、90d），一种是消息条数（比如 50）。README 顺带指出 90d 是免费版历史的默认上限，这句话本身就是在告诉你免费工作区能捞多久。conversations_search_messages 有一条容易踩的说明：bot token（xoxb- 开头）用不了这个工具，因为 bot token 不能调用 search.messages。如果你打算用 bot 身份跑搜索，这条路直接堵死。
写操作默认是关的，这个默认值是对的
conversations_add_message 默认禁用，README 的说法是 disabled by default for safety，要开得设 SLACK_MCP_ADD_MESSAGE_TOOL 环境变量。这个变量的取值有两种：设成逗号分隔的频道 ID 列表，就只对这几个频道开放发消息；不设就完全不能发。把写权限做成白名单而不是开关，是个克制的选择。发消息本身还有 content_type 参数，默认 text/markdown，另一个可选值是 text/plain。对 LLM 来说 markdown 是更自然的输出格式，但把模型生成的 markdown 直接投到 Slack 频道里，格式渲染结果未必是你要的。thread_ts 是可选的，不传就发到频道本身，传了就进对应的线程。这四条参数凑在一起，意味着你可以在一个只读的 MCP 配置里完全不碰写路径，这是可以做到的。
Unread 与缓存：为 LLM 的上下文预算做的设计
README 里有一个不太起眼但值得注意的工具能力：获取所有频道的未读消息，并且做了优先级排序，顺序是 DMs 优先于 partner channels，partner channels 优先于内部频道，同时支持 @mention 过滤和 mark-as-read。这个排序逻辑不是 Slack 提供的，是服务端自己加的。它假设的场景是：LLM 每次被唤醒时上下文有限，应该先看私聊里有没有人找它，再看合作方频道，最后才轮到内部闲聊。缓存方面，README 说会缓存 users 和 channels 以加快访问。这里没有给出缓存失效策略，也没有说 TTL 是多少，材料里查不到。对一个会长时间运行的 MCP 服务端来说，用户改名、频道新增这类变动什么时候反映到缓存里，是需要你自己去代码里确认的事。
stealth 模式的代价，README 没有正面写
整个项目的宣传重心在 no permission requirements，但这句话的另一面是：你的访问能力完全绑在浏览器会话上。会话过期、被管理员强制登出、或者安全策略变更，服务端就失去访问能力，而这不是你能通过改配置修好的。OAuth 模式虽然被描述成更省事，但它同样依赖 token 的有效期管理。材料里没有说明 stealth 模式具体抓取哪些凭据、存放在哪里、是否落盘。这几点在上生产前必须自己确认，因为一个把会话凭据读进内存的进程，和你的浏览器登录态是同一份权限。另外 README 提到支持 Enterprise Workspaces 和 GovSlack，但没有给出 GovSlack 环境下的具体配置差异，只列在 topics 里。如果你的工作区属于这两类，材料不足以让你判断能否直接套用默认配置。
和直接用 Slack API 脚本比，差在哪
不用这个项目也能读 Slack 消息，写个脚本调 conversations.history 就行。差别在于三件事。第一是协议层：MCP 服务端把工具定义、参数 schema、分页游标都按 Model Context Protocol 的规范暴露出来，任何支持 MCP 的客户端可以直接发现并调用这些工具，不需要你为每个客户端写适配。第二是传输层：README 说支持 Stdio、SSE 和 HTTP 三种 transport，还支持配置代理转发出口请求。自己写的脚本通常只解决一种调用方式，要接到不同客户端上得改代码。第三是那些非 API 原生的逻辑：未读消息的优先级排序、按 d/w/m 解析的时间范围、把 #channel 名字解析成 ID、users 和 channels 的缓存，这些都要自己实现。反过来说，如果你的需求只是定时拉一个频道的消息存进数据库，这个服务端带来的抽象层反而是负担，直接用 Slack SDK 更短。
许可证与维护节奏
项目是 MIT 许可证。这意味着你可以修改、分发、商用，义务基本只有保留版权声明和许可文本，具体条款以仓库里的 LICENSE 文件为准，这里不构成法律意见。发布节奏上，材料里能看到 v1.2.2 在 2026-02-25，v1.2.3 在 2026-03-03，v1.3.0 在 2026-05-14，主分支最后一次推送是 2026-07-16。最近一次发布和最后一次推送之间隔了两个月，说明主分支上有未发布到 tag 的改动。升级时要注意的是配置面：SLACK_MCP_ADD_MESSAGE_TOOL 这类环境变量的语义如果在小版本里变化，你的部署脚本会静默失效。README 里那段请求 star 的文字提到每月有超过 30,000 名工程师访问、9,000 多人在用，这是项目方的自述数据，不是可核验的指标，本文不把它当作成熟度证据。
编辑结论
如果你需要让 LLM 助手快速读取一个自己已经登录的 Slack 工作区，又不想走 App 审批流程，stealth 模式是这个项目唯一值得看的理由。如果你需要长期稳定运行、需要写操作、或者工作区有合规审计要求，不要选它，OAuth 模式下的 Slack 官方 App 审批虽然慢，但 token 不会因为一次浏览器登出而失效。上手前先确认三件事：你的 MCP 客户端支持哪种 transport（Stdio、SSE 还是 HTTP），你的工作区是否允许 search.messages（bot token 明确不支持），以及 SLACK_MCP_ADD_MESSAGE_TOOL 到底要不要开，默认它是关的。
社区笔记