Skip to main content
Glama
enesjakozh
korotovsky

Slack MCP

by korotovsky
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Go
Hybrid

Slack MCP サーバー

Slackワークスペース用のモデルコンテキストプロトコル（MCP）サーバー。この統合は、StdioとSSEの両方のトランスポートとプロキシ設定をサポートし、ワークスペース管理者による権限やボットの作成・承認は必要ありません😏。

機能デモ

ezgif-316311ee04f444

ツール

  1. conversations_history

  • チャネルIDでチャネルからメッセージを取得する

  • 必要な入力:

    • channel_id (文字列): チャネルの ID (形式は Cxxxxxxxxxx)。

    • cursor (文字列): ページ区切りのカーソル。レスポンスの最後の行と列の値を、前回のリクエストから返された next_cursor フィールドとして使用します。

    • limit (数値、デフォルト: 28): 取得するメッセージの制限。

  • 戻り値: タイムスタンプ、ユーザーID、テキストコンテンツを含むメッセージのリスト

  1. channels_list

  • チャンネルのリストを取得する

  • 必要な入力:

    • channel_types (配列): 可能なチャネルタイプ。許可される値: 'mpim'、'im'、'public_channel'、'private_channel'。

    • sort (文字列): 並べ替えの種類。使用できる値: 'popularity' - 各チャンネルのメンバー/参加者数で並べ替えます。

  • 戻り値: チャンネルのリスト

Related MCP server: Slack MCP Server

セットアップガイド

1. 認証の設定

ブラウザで Slack を開いてログインします。

SLACK_MCP_XOXC_TOKEN検索

  • ブラウザの開発者コンソールを開きます。

  • Firefoxでは、メニューバーのTools -> Browser Tools -> Web Developer tools

  • Chromeでは、URLバーの右側にある「3つの点」ボタンをクリックし、 More Tools -> Developer Toolsを選択します。

  • コンソールタブに切り替えます。

  • 「貼り付けを許可する」と入力して、Enter キーを押します。

  • 次のスニペットを貼り付けて、ENTER キーを押して実行します: JSON.parse(localStorage.localConfig_v2).teams[document.location.pathname.match(/^\/client\/([A-Z0-9]+)/)[1]].token

トークンの値は実行されたコマンドの直後に印刷されます ( xoxc-で始まります)。とりあえずどこかに保存してください。

SLACK_MCP_XOXD_TOKEN検索

  • 「アプリケーション」タブに切り替えて、左側のナビゲーション ペインで「Cookie」を選択します。

  • dという名前のクッキーを見つけてください。そうです、文字dだけです。

  • この Cookie の値をダブルクリックします。

  • Ctrl+C または Cmd+C を押して、その値をクリップボードにコピーします。

  • 後で使用するために保存します。

2. インストール

次のいずれかのインストール方法を選択します。

3. 設定と使用方法

コマンドライン引数と環境変数を使用して MCP サーバーを構成できます。

npxの使用

npm がインストールされている場合は、これが Claude Desktop でslack-mcp-serverを使い始める最も早い方法です。

claude_desktop_config.jsonを開き、mcp サーバーをmcpServersのリストに追加します。

{
  "mcpServers": {
    "slack": {
      "command": "npx",
      "args": [
        "-y",
        "slack-mcp-server@latest",
        "--transport",
        "stdio"
      ],
      "env": {
        "SLACK_MCP_XOXC_TOKEN": "xoxc-...",
        "SLACK_MCP_XOXD_TOKEN": "xoxd-..."
      }
    }
  }
}
{
  "mcpServers": {
    "slack": {
      "command": "docker",
      "args": [
        "run",
        "-i",
        "--rm",
        "-e",
        "SLACK_MCP_XOXC_TOKEN=$SLACK_MCP_XOXC_TOKEN",
        "-e",
        "SLACK_MCP_XOXD_TOKEN=$SLACK_MCP_XOXD_TOKEN",
        "ghcr.io/korotovsky/slack-mcp-server",
        "mcp-server",
        "--transport",
        "stdio"
      ],
      "env": {
        "SLACK_MCP_XOXC_TOKEN": "xoxc-...",
        "SLACK_MCP_XOXD_TOKEN": "xoxd-..."
      }
    }
  }
}

詳細については、 Docker を参照してください。

sseトランスポートで npx を使用する:

sseモードで実行したい場合は、Claude Desktop のmcp-remoteラッパーを使用し、 ngrokやdocker-composeなどを使用して MCP サーバーをどこかにデプロイ/公開する必要があります。

{
  "mcpServers": {
    "slack": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote",
        "https://x.y.z.q:3001/sse",
        "--header",
        "Authorization: Bearer ${SLACK_MCP_SSE_API_KEY}"
      ],
      "env": {
        "SLACK_MCP_SSE_API_KEY": "my-$$e-$ecret"
      }
    }
  }
}
{
  "mcpServers": {
    "slack": {
      "command": "C:\\Progra~1\\nodejs\\npx.cmd",
      "args": [
        "-y",
        "mcp-remote",
        "https://x.y.z.q:3001/sse",
        "--header",
        "Authorization: Bearer ${SLACK_MCP_SSE_API_KEY}"
      ],
      "env": {
        "SLACK_MCP_SSE_API_KEY": "my-$$e-$ecret"
      }
    }
  }
}

TLSとインターネットへの公開

SSE に HTTPS を設定する必要がある理由はいくつかあります。

  • mcp-remote https スキームのみを処理できます。

  • 一般的に、インターネットに公開されるすべてのサービスに TLS を使用することをお勧めします。

ngrokを使うこともできます:

ngrok http 3001

次に、 mcp-remote引数にエンドポイントhttps://903d-xxx-xxxx-xxxx-10b4.ngrok-free.appを使用します。

Dockerの使用

すべての環境変数の詳細については、 「環境変数」を参照してください。

export SLACK_MCP_XOXC_TOKEN=xoxc-...
export SLACK_MCP_XOXD_TOKEN=xoxd-...

docker pull ghcr.io/korotovsky/slack-mcp-server:latest
docker run -i --rm \
  -e SLACK_MCP_XOXC_TOKEN \
  -e SLACK_MCP_XOXD_TOKEN \
  slack-mcp-server --transport stdio

または、docker-compose の方法:

wget -O docker-compose.yml https://github.com/korotovsky/slack-mcp-server/releases/latest/download/docker-compose.yml
wget -O .env https://github.com/korotovsky/slack-mcp-server/releases/latest/download/default.env.dist
nano .env # Edit .env file with your tokens from step 1 of the setup guide
docker-compose up -d

コンソール引数

口論

必須 ？

説明

--transportまたは-t

はい

MCP サーバーのトランスポートを選択します。可能な値は、 stdio 、 sseです。

環境変数

変数

必須 ？

デフォルト

説明

SLACK_MCP_XOXC_TOKEN

はい

nil

認証データ トークン フィールド、POST データ フィールド セットからのtoken ( xoxc-... )

SLACK_MCP_XOXD_TOKEN

はい

nil

クッキーdからの認証データ トークン ( xoxd-... )

SLACK_MCP_SERVER_PORT

いいえ

3001

MCP サーバーが listen するポート

SLACK_MCP_SERVER_HOST

いいえ

127.0.0.1

MCP サーバーが listen するホスト

SLACK_MCP_SSE_API_KEY

いいえ

nil

transportがsseの場合の認可ベアラートークン

SLACK_MCP_PROXY

いいえ

nil

MCP サーバーが使用するプロキシ URL

SLACK_MCP_SERVER_CA

いいえ

nil

信頼ストアの CA 証明書へのパス

SLACK_MCP_SERVER_CA_INSECURE

いいえ

false

安全でないリクエストはすべて信頼する（非推奨）

デバッグツール

# Run the inspector with stdio transport
npx @modelcontextprotocol/inspector go run mcp/mcp-server.go --transport stdio

# View logs
tail -n 20 -f ~/Library/Logs/Claude/mcp*.log

安全

  • APIトークンを共有しないでください

  • .env ファイルを安全かつプライベートに保つ

ライセンス

MITライセンス（ LICENSEファイル参照）です。これはSlackの公式製品ではありません。

Available Tools

2 tools
channels_listC

Get list of channels

ParametersJSON Schema
NameRequiredDescriptionDefault
channel_typesYesPossible channel types. Allowed values: 'mpim', 'im', 'public_channel', 'private_channel'.
sortNoType of sorting. Allowed values: 'popularity' - sort by number of members/participants in each channel.

TDQS

C2.7/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action ('Get list') without addressing permissions, rate limits, pagination, or what 'list' entails (e.g., format, completeness). This is inadequate for a tool that likely interacts with a chat system, where such details are critical.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise with just three words, front-loaded with the core action. There's no wasted text, making it efficient for quick understanding, though this brevity contributes to gaps in other dimensions.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., safety, performance), output format, and usage context. For a tool with parameters and likely complex interactions in a chat system, this minimal description fails to provide sufficient context for effective agent use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema fully documents both parameters (channel_types and sort). The description adds no parameter-specific information beyond what's in the schema, meeting the baseline score of 3 for high schema coverage without additional value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Get list of channels' clearly states the verb ('Get') and resource ('channels'), but it's vague about scope and doesn't distinguish from the sibling tool 'conversations_history'. It doesn't specify whether this retrieves all channels, user-accessible channels, or some subset, leaving purpose ambiguous beyond the basic action.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives like 'conversations_history'. The description doesn't mention context, prerequisites, or exclusions, leaving the agent to infer usage based solely on the tool name and parameters.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

conversations_historyB

Get messages from the channel by channel_id, the last row/column in the response is used as 'cursor' parameter for pagination if not empty

ParametersJSON Schema
NameRequiredDescriptionDefault
channel_idYesID of the channel in format Cxxxxxxxxxx
cursorNoCursor for pagination. Use the value of the last row and column in the response as next_cursor field returned from the previous request.
limitNoLimit of messages to fetch in format of maximum ranges of time (e.g. 1d - 1 day, 30d - 30 days, 90d - 90 days which is a default limit for free tier history) or number of messages (e.g. 50). Must be empty when 'cursor' is provided.1d

TDQS

B3.4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes pagination behavior and the interaction between 'cursor' and 'limit' parameters, which adds useful context beyond the input schema. However, it doesn't cover other behavioral aspects such as rate limits, authentication requirements, error handling, or what the response format looks like (e.g., structure of returned messages). For a tool with no annotations, this leaves gaps in understanding its full behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that efficiently conveys the core functionality and key behavioral detail (pagination). It is front-loaded with the main purpose and avoids unnecessary words. However, it could be slightly more structured by separating the pagination explanation into a second sentence for clarity, but overall it's concise and to the point.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (3 parameters, no output schema, no annotations), the description is moderately complete. It covers the purpose and pagination behavior but lacks details on response format, error conditions, or broader usage context. Without an output schema, the description doesn't explain what the tool returns (e.g., message structure), which is a significant gap. It's adequate for basic understanding but incomplete for full agent usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, meaning the input schema already documents all parameters thoroughly. The description adds some semantic context by explaining how pagination works with the cursor and the constraint that 'limit' must be empty when 'cursor' is provided, which clarifies parameter interactions. However, it doesn't provide significant additional meaning beyond what's in the schema descriptions, such as examples or edge cases, so it meets the baseline for high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Get messages from the channel by channel_id'. It specifies the resource (messages) and the required parameter (channel_id), making the verb+resource combination explicit. However, it doesn't distinguish this tool from its sibling 'channels_list', which appears to list channels rather than messages, so the differentiation is implied but not explicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides some usage guidance by explaining pagination with the cursor parameter and noting that 'limit' must be empty when 'cursor' is provided. This gives context for when to use certain parameters. However, it doesn't explicitly state when to use this tool versus alternatives like 'channels_list' or other hypothetical tools, nor does it provide broader context on when this tool is appropriate versus other methods for retrieving messages.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 2 tool updatesv1.0.0
    • First observedchannels_list
    • First observedconversations_history
Deploy Server
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

TDQS

B3/5.0

Scored across 2 tools

Disambiguation5/5

The two tools have clearly distinct purposes: channels_list retrieves a list of channels, while conversations_history fetches messages from a specific channel. There is no overlap in functionality, making it easy for an agent to select the correct tool based on the task.

Naming Consistency4/5

Both tools follow a consistent snake_case naming convention, but the patterns differ slightly: channels_list uses a noun_verb format, while conversations_history uses a noun_noun format. This minor deviation prevents a perfect score, but the naming is still readable and mostly consistent.

Tool Count2/5

With only 2 tools, this server feels too thin for a Slack integration, as it lacks essential operations like sending messages, managing users, or updating channel settings. The scope is severely limited, making it difficult for agents to perform comprehensive Slack-related tasks.

Completeness2/5

The tool surface is significantly incomplete for a Slack domain. While it covers listing channels and retrieving message history, it misses critical operations such as posting messages, creating channels, or handling reactions, which are core to Slack workflows and will likely cause agent failures.

Maintenance

ActivityInactive
ResponsivenessSlow

Resources

Related MCP Connectors

Related MCP Servers

  • Slack Notify MCP

    SilasReinagel
    A
    license
    Not graded
    quality
    D
    maintenance
    MCP server for posting messages to Slack channels via webhooks or bot API. Supports configurable usernames, emojis, and both webhook and bot token authentication modes.
    18 npm
    MIT

  • Slack MCP Server

    Themetralla3000
    A
    license
    Not graded
    quality
    D
    maintenance
    A Model Context Protocol (MCP) server for Slack workspace integration. This server allows AI assistants to interact directly with your Slack workspace, providing tools to manage channels, send messages, list users, and upload files.
    32,291 npm
    1
    MIT

  • Slack MCP Server

    kamolc4
    A
    license
    Not graded
    quality
    C
    maintenance
    A production-ready MCP server for the Slack API that enables searching, listing channels, reading history, inspecting users, fetching threads, and sending messages through controlled Slack tools.
    32,291 npm
    MIT

Appeared in Searches