slack-mcp-server：用 stealth 模式繞過 Slack App 審批的 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 撰寫，讓 MCP 客戶端直接讀取 Slack 訊息，賣點是不需要安裝 App、不需要申請權限範圍。這篇拆解它的兩種認證路徑、工具介面與實際限制。
- 適合誰用？
- 如果你要把 Slack 對話接進 LLM 工具鏈，卻卡在企業 IT 不願意批准一個新的 Slack App，這個專案值得先做概念驗證；如果你需要的是穩定、可稽核、有明確權限邊界的企業整合，stealth 模式反而是風險來源，應該走 OAuth 模式或改用官方 App 路線。動手前先確認三件事：你的 MCP 客戶端支援哪種 transport（Stdio、SSE 或 HTTP）、你要讀的頻道歷史是否落在免費方案 90 天的上限內、以及你是否打算用 bot token（若是，conversations_search_messages 直接不可用）。
- 可以商用嗎？
- 可以。MIT 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 61 天前。
- 用什麼語言寫的？
- 主要是 Go（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它解決的是 Slack App 審批流程，不是 Slack API 本身
Slack 的官方整合路徑要求你建立一個 App、勾選 OAuth scopes、取得管理員同意、安裝到 Workspace。對個人開發者或小團隊，這條路徑的摩擦點不在技術，而在流程：誰有權限安裝、安裝後誰負責稽核。korotovsky/slack-mcp-server 的 README 把這件事講得很直白，它提供兩種模式，一種是 OAuth，另一種被稱為 stealth mode，描述是「no permissions and scopes in Workspace」。
目標讀者因此很清楚：已經在用 Claude Desktop、Cursor 或其他支援 Model Context Protocol 的客戶端，想把 Slack 頻道內容餵進模型，但不打算走 App 審批的人。次要讀者是企業環境的操作者，README 提到 Enterprise Workspaces 與 GovSlack 兩個主題標籤，代表 GovSlack 這種受管制環境也在設計考量內。
要注意的是，README 開頭那段關於每月訪客數與使用人數的敘述，是專案自己的說法，我沒有辦法獨立驗證，也不該當成採用率的證據。真正該看的是工具清單與環境變數，那才是決定你能做什麼與不能做什麼的地方。
兩種認證路徑的取捨：stealth 換到的是便利，不是能力
README 對 OAuth 模式的描述是「secure OAuth tokens for access without needing to refresh or extract tokens from the browser」，意思是走正規授權、token 由伺服器管理，使用者不必手動從瀏覽器開發者工具裡挖 cookie 或 token。stealth 模式則相反，它宣稱不需要額外權限或安裝 bot。
這兩條路徑的差別不只是取得憑證的方式。走 OAuth 意味著你的存取行為掛在一個有名有姓的 App 底下，Workspace 管理員看得到，權限範圍可以被撤銷，稽核軌跡存在。stealth 模式把這層可觀測性拿掉，換來的是部署速度。對個人 Workspace 這是合理交換，對有合規要求的組織則是把風險從「審批流程」搬到「事後發現」。
README 沒有在提供的材料裡說明 stealth 模式具體如何取得憑證，也沒有說明它依賴哪些 Slack 端點。這是評估時必須自己確認的第一個空白：如果一個工具宣稱不需要權限就能讀取訊息，那它到底用了什麼身分在讀，這個問題的答案決定了它能不能進你的環境。
四個工具與 Smart History 的分頁邏輯
伺服器對外暴露的工具是四個：conversations_history、conversations_replies、conversations_add_message、conversations_search_messages。前兩個負責讀取，第三個寫入，第四個搜尋。
讀取工具的參數設計有一個值得注意的地方。channel_id 除了接受標準的 Cxxxxxxxxxx 格式，也接受以 # 或 @ 開頭的名稱，例如 #general 或 @username_dm。這看起來只是便利性，實際上決定了 agent 能不能自己解析使用者口語提到的頻道，而不需要你先做一次 ID 對照。
分頁機制走 cursor。README 的說明是「the last row/column in the response is used as 'cursor' parameter for pagination if not empty」，也就是回應最後一列的值就是下一頁的游標。limit 參數同時接受時間範圍與訊息數量兩種格式：1d、1w、30d、90d 這類時間寫法，或 50 這樣的數字。README 特別註明 90d 是免費方案歷史的預設上限，這是一個硬邊界，不是你調參數就能繞過的。
還有一個細節：cursor 有值的時候，limit 必須留空。這是常見的分頁約定，但對第一次接這個工具的人來說是容易踩的錯誤，因為兩個參數在文件裡是並列描述的。include_activity_messages 預設 false，打開之後 channel_join、channel_leave 這類活動訊息會混進結果，對要分析對話內容的場景通常是雜訊。
搜尋工具在 bot token 下直接消失
conversations_search_messages 是這個專案裡限制最明確的一個工具。README 的註記寫著：使用 bot token（xoxb-*）時這個工具不可用，因為 bot token 無法呼叫 search.messages API。
這不是可以繞過的設定問題，是 Slack 平台層級的限制。如果你打算用 bot token 部署，就必須接受你的 agent 沒有搜尋能力，只能沿著頻道歷史一頁一頁翻。對需要「找出上週提到某個關鍵字的對話」這類需求，這等於功能缺一半。
搜尋工具本身支援的過濾條件包括 filter_in_channel、filter_in_im_or_mpim、日期、使用者與內容。它還接受一個特殊輸入：完整的 Slack 訊息 URL，例如 https://slack.com/archives/C1234567890/p1234567890123456，這時工具會回傳該 URL 對應的單一訊息，其他參數全部忽略。這個設計讓使用者可以直接貼連結給 agent，不必先描述在哪個頻道找什麼。
寫入工具 conversations_add_message 預設關閉。README 的措辭是「disabled by default for safety」，要透過 SLACK_MCP_ADD_MESSAGE_TOOL 環境變數開啟。這個變數支援兩種設定：單純開啟，或填入逗號分隔的頻道 ID 清單，只開放特定頻道。後者是比較合理的使用方式，因為它把「agent 可以發言」的範圍限縮到你能列舉出來的地方。
部署時真正要設定的東西
這個伺服器支援 Stdio、SSE 與 HTTP 三種 transport，README 也提到可以設定 proxy 讓對外請求走代理。這三種 transport 的選擇取決於你的 MCP 客戶端支援哪一種，不是伺服器端的偏好問題。本機執行的客戶端通常走 Stdio，需要跨機器或集中部署的場景才需要 SSE 或 HTTP。
環境變數在材料裡明確出現的有三個：SLACK_MCP_ADD_MESSAGE_TOOL 控制寫入工具是否開啟與開放哪些頻道；其餘與快取、使用者資訊嵌入相關的設定，README 只以功能條目形式列出（Cache support、Embedded user information），沒有在提供的內容裡給出對應的變數名稱。這是文件完整度的問題，不是功能不存在，但你在部署前需要回到 repository 的 Environment Variables 章節把實際鍵名抄下來，不能靠推測。
建置方式是從原始碼編譯，專案是 Go 語言，授權為 MIT。MIT 的意義是你可以修改、再散布、商業使用，只要保留著作權聲明與授權條款。這是寬鬆授權，對內部工具或商業產品的整合都不構成阻礙。這不是法律意見，實際條款請看 repository 內的 LICENSE 檔案。
什麼情況下它會變成錯的工具
第一個失效場景是免費方案的歷史深度。90 天是 Slack 免費方案的預設上限，README 把它寫在 limit 參數的說明裡。如果你的分析需要跨越半年以上的對話，這個工具拿不到資料，換任何 MCP 伺服器也一樣，因為限制在 Slack 那一側。
第二個是搜尋需求與 bot token 的衝突，前面已經說明。第三個比較隱微：這個專案的功能清單裡有 Unread Messages，README 描述它會依 DM、partner channels、internal 的優先順序排序，支援 @mention 過濾與 mark-as-read。mark-as-read 是一個會改變 Workspace 狀態的操作。當你把這個工具交給一個自主性較高的 agent，它讀取未讀訊息的同時可能把狀態清掉，而使用者本人還沒看過。這不是 bug，是能力與風險同時被放進同一個工具介面。
第四個是快取。README 提到會快取 users 與 channels 以加快存取。快取在頻道成員變動頻繁的 Workspace 裡會產生過期資料，而材料裡沒有說明快取的失效策略或手動清除方式。如果你的使用場景對成員名單的正確性敏感，這是一個需要在部署前實測確認的點。
與官方 Slack MCP 伺服器的路線差異
Slack 官方維護的 MCP 伺服器走的是標準 App 路線：建立 App、設定 scopes、安裝到 Workspace、用官方認證的 token 呼叫 API。它的優點是可稽核、權限邊界清楚、管理員能撤銷；缺點是每一個新功能都要經過一次 scope 變更與重新安裝，在流程嚴謹的組織裡這可能要等好幾天。
korotovsky/slack-mcp-server 的差異不在工具數量，而在認證路徑。它把「先取得授權」這個前置步驟拿掉，讓你能在幾分鐘內把 Slack 接上 LLM。代價是這條路徑的可觀測性較低，而且當 Slack 調整 API 或封鎖某些存取方式時，這類繞道方案的修復速度取決於單一維護者的反應。
兩者不是替代關係，是兩個不同的風險預算。個人 Workspace、實驗性質的 agent、暫時不想驚動 IT 的場景，這個專案合理。已經有資安政策、需要向稽核交代資料流向的組織，官方路線才是能長期運作的選擇。中間地帶是這個專案提供的 OAuth 模式，它保留了正規授權，同時仍有 #Name 查詢、Smart History、未讀訊息排序這些官方伺服器不一定提供的工具介面。
編輯結論
如果你要把 Slack 對話接進 LLM 工具鏈，卻卡在企業 IT 不願意批准一個新的 Slack App，這個專案值得先做概念驗證；如果你需要的是穩定、可稽核、有明確權限邊界的企業整合，stealth 模式反而是風險來源，應該走 OAuth 模式或改用官方 App 路線。動手前先確認三件事：你的 MCP 客戶端支援哪種 transport（Stdio、SSE 或 HTTP）、你要讀的頻道歷史是否落在免費方案 90 天的上限內、以及你是否打算用 bot token（若是，conversations_search_messages 直接不可用）。把 conversations_add_message 留在預設關閉狀態，等到你確定要寫入哪些頻道，再用 SLACK_MCP_ADD_MESSAGE_TOOL 逐一開放。
社群筆記