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 栏右侧的“三个点”按钮，然后选择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

  • 切换到“应用程序”选项卡，然后在左侧导航窗格中选择“Cookies”。

  • 找到名称为d Cookie。没错，就是字母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以了解更多信息。

使用 npx 和sse传输：

如果您想在sse模式下运行它，那么您应该使用 Claude Desktop 的mcp-remote包装器，并在某处部署/公开 MCP 服务器，例如使用ngrok或docker-compose 。

{
  "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

然后使用端点https://903d-xxx-xxxx-xxxx-10b4.ngrok-free.app作为您的mcp-remote参数。

使用 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

来自 cookie d身份验证数据令牌（ xoxd-... ）

SLACK_MCP_SERVER_PORT

不

3001

MCP 服务器监听的端口

SLACK_MCP_SERVER_HOST

不

127.0.0.1

MCP 服务器监听的主机

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