korotovsky/slack-mcp-server を権限なしで運用するときの実際の判断基準
The most powerful MCP Slack Server with no permission requirements, Apps support, GovSlack, DMs, Group DMs and smart history fetch logic.
ひと目でわかる
- これは何？
- Slack ワークスペースを MCP 経由で LLM クライアントに接続する Go 製サーバー。トークンの種類によって使えるツールが変わる点と、stealth モードの代償を中心に、導入前に確認すべき境界を整理する。
- 誰に向いている？
- 採用すべきなのは、Slack の管理者権限を持たずに自分のアカウントの会話履歴を LLM クライアントから読みたい個人や小規模チームである。逆に、監査ログや権限の一元管理が要件にある組織、複数人でトークンを共有する運用、メッセージ投稿を自動化したいケースには向かない。
- 商用利用できる？
- できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 61 日前です。
- 何の言語で書かれている？
- 主に Go です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
Slack の会話を LLM に読ませるまでに何が詰まるか
Slack のデータを LLM クライアントから扱おうとすると、最初にぶつかるのは認可の壁である。Slack アプリを作るにはワークスペースの管理者承認が要り、必要なスコープを申請して審査を通し、ボットを各チャンネルに招待する。個人が自分の会話履歴を読みたいだけの場合、この手続きは明らかに過剰である。korotovsky/slack-mcp-server はこの手続きを回避する経路を用意している。README の表現を借りれば、complete stealth mode with no permissions and scopes in Workspace で動かせる。対象読者は、Slack の管理者権限を持たない開発者、あるいは承認フローを待たずに検証したいエンジニアである。もう一方で、OAuth トークンを使う正規の経路も同じバイナリで扱えるため、管理者承認が下りた後に設定を切り替えるという使い方もできる。
3つのトランスポートと、トークン種別で変わるツールの可用性
サーバーは Stdio、SSE、HTTP の3種類のトランスポートに対応し、外向きの通信はプロキシ経由にできる。MCP クライアント側がどのトランスポートを話せるかで選ぶ形になる。ツールは conversations_history、conversations_replies、conversations_add_message、conversations_search_messages の4つが README に記載されている。ここで見落とされやすいのが、conversations_search_messages に関する注記である。README は This tool is not available when using bot tokens (xoxb-*) と明記し、理由として Bot tokens cannot use the search.messages API を挙げている。つまり xoxb- で始まるボットトークンで運用すると、検索ツールは事実上存在しないものとして設計しなければならない。逆にユーザートークンや stealth モードのトークンでは検索が使える。ツール一覧だけを見て「4つ使える」と判断すると、本番で気づくことになる。
stealth モードが成立する仕組みと、そこで失うもの
stealth モードは、ブラウザのセッションから取り出した xoxc トークンと xoxd クッキーを組み合わせて Slack の内部 API を叩く方式である。README はこれを no permission requirements と表現している。アプリのインストールもスコープ承認も不要な代わりに、この資格情報は Slack の公式な開発者向けインターフェースではない。したがって、パスワード変更やサインアウト、管理者によるセッション失効でトークンは無効になり、その時点でサーバーは黙って失敗する可能性がある。ここは README が明示的に保証している領域ではなく、私の側でも検証していない。設計上のトレードオフとして、承認コストをゼロにする代わりに、資格情報の寿命を自分で管理する責任を負うことになる。OAuth モードは README いわく secure OAuth tokens for access without needing to refresh or extract tokens from the browser であり、この寿命問題を引き受ける形になる。
Smart History の limit 指定と cursor の排他関係
履歴取得のパラメータ設計は独特である。conversations_history と conversations_replies の limit は、メッセージ件数ではなく時間範囲でも指定できる。README の例では 1d、1w、30d、90d といった形式と、50 のような件数指定の両方が挙げられている。90d については which is a default limit for free tier history と注記されており、無料プランの履歴上限を意識した既定値だと読める。もう一点、limit は Must be empty when 'cursor' is provided と明記されている。ページングを進めるときは limit を送ってはいけない。件数と時間範囲という異なる単位を同じキーに載せ、cursor 併用時は空にするという仕様は、クライアント側の実装を誤りやすくする。ページング処理を書くなら、最初の呼び出しだけ limit を付け、以降は cursor のみを送る分岐を明示的に用意したい。
セットアップで実際に触る環境変数
導入時の設定は環境変数が中心になる。README で名前が確認できるのは SLACK_MCP_ADD_MESSAGE_TOOL である。メッセージ投稿は既定で無効になっており、この変数を設定して初めて conversations_add_message が有効になる。値をカンマ区切りのチャンネル ID リストにすると、those specific channels に限定して投稿を許可できる。つまり全チャンネルに書き込める状態と、特定チャンネルだけに書ける状態を、同じ変数の書式で切り替える設計である。読み取り専用で使うなら、この変数を未設定のままにするのが最も安全な既定と言える。トランスポートの選択とプロキシ設定、stealth モードと OAuth モードの切り替えも環境変数で行うが、README の抜粋には個々のキー名までは現れていない。設定ファイルの雛形や全キーの一覧はリポジトリ本体で確認する必要がある。
投稿ツールを有効にする前に考えること
conversations_add_message が既定で無効なのは、単なる慎重さではなく、LLM に書き込み権限を渡すことの危険性を踏まえた判断だと読める。payload は text/markdown または text/plain で渡し、thread_ts を省略すればチャンネル本体、指定すればスレッドへの返信になる。channel_id は Cxxxxxxxxxx 形式のほか、#general や @username_dm のような名前でも受け付ける。名前で指定できる利便性は、裏を返せばエージェントが意図しないチャンネルに投稿する余地を広げる。SLACK_MCP_ADD_MESSAGE_TOOL にチャンネル ID のリストを入れておけば、名前解決の結果が許可リストの外に出た時点で拒否される。読み取り専用で始め、本当に投稿を自動化したいチャンネルだけを ID で列挙する、という順序が現実的である。
公式の Slack MCP サーバーとの設計差
比較対象として素直なのは Slack 自身が提供する MCP サーバーである。違いは認可の経路にある。公式側は Slack アプリの作成とスコープ承認、ワークスペース管理者の同意を前提とし、その代わりに権限の範囲が Slack 側で管理され、失効も管理者操作で完結する。korotovsky/slack-mcp-server はこの承認を経ずに動く経路を用意し、その代わりに資格情報の取得と更新を利用者側の作業に落とす。どちらが優れているという話ではなく、管理コストを組織側に寄せるか個人側に寄せるかの違いである。加えて GovSlack がトピックに挙がっている点は、公式サーバーが対象としない環境を狙っていることを示す。ただし GovSlack 固有の設定手順は README の抜粋からは読み取れない。
ライセンスと更新の追い方
ライセンスは MIT である。変更を加えた再配布や商用利用の条件は MIT の条文に従う。ここから先は法的助言ではないが、組織で使う場合は自組織のポリシー担当に確認するのが前提になる。保守の面では、リポジトリはアーカイブされておらず、v1.3.0 が 2026-05-14、v1.2.3 が 2026-03-03、v1.2.2 が 2026-02-25 と、短い間隔でリリースが続いている。Slack 側の非公開 API に依存する stealth モードを選ぶ以上、Slack 側の変更でツールが壊れる可能性は常にある。どのリリースで何が変わったかは release notes を確認する必要があり、この記事の材料からは各版の差分までは分からない。バージョンを固定して使い、更新前に release notes を読む運用が、この依存関係の性質には合っている。
編集部の結論
採用すべきなのは、Slack の管理者権限を持たずに自分のアカウントの会話履歴を LLM クライアントから読みたい個人や小規模チームである。逆に、監査ログや権限の一元管理が要件にある組織、複数人でトークンを共有する運用、メッセージ投稿を自動化したいケースには向かない。導入前に確認すべきは3点で、第一に使うトークンの種類で conversations_search_messages が動くかどうか、第二に stealth モードで使う xoxc/xoxd の寿命と失効時の再取得手順、第三に SLACK_MCP_ADD_MESSAGE_TOOL の設定値が空のままであること。このうちどれかが確認できないなら、このサーバーを本番の業務フローに組み込む判断は保留したほうがよい。
コミュニティノート