Skip to main content
Glama
enesjakozh
korotovsky

Slack MCP

by korotovsky
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Go
Hybrid

슬랙 MCP 서버

Slack Workspace용 모델 컨텍스트 프로토콜(MCP) 서버입니다. 이 통합은 Stdio 및 SSE 전송, 프록시 설정을 모두 지원하며 Workspace 관리자가 권한을 부여하거나 봇을 생성하거나 승인할 필요가 없습니다. 😏

기능 데모

ezgif-316311ee04f444

도구

  1. conversations_history

  • 채널ID로 채널에서 메시지 가져오기

  • 필수 입력 사항:

    • channel_id (문자열): Cxxxxxxxxxx 형식의 채널 ID입니다.

    • 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 조회

  • "응용 프로그램" 탭으로 전환하고 왼쪽 탐색 창에서 "쿠키"를 선택하세요.

  • 이름이 d 인 쿠키를 찾으세요. 맞아요, d 라는 글자만 있네요.

  • 이 쿠키의 값을 두 번 클릭합니다.

  • Ctrl+C 또는 Cmd+C를 눌러 값을 클립보드에 복사합니다.

  • 나중에 보려고 저장해 두세요.

2. 설치

다음 설치 방법 중 하나를 선택하세요.

3. 구성 및 사용

명령줄 인수와 환경 변수를 사용하여 MCP 서버를 구성할 수 있습니다.

npx 사용하기

npm이 설치되어 있다면 Claude Desktop에서 slack-mcp-server 를 시작하는 가장 빠른 방법입니다.

claude_desktop_config.json 열고 mcpServers 목록에 mcp 서버를 추가합니다.

지엑스피1

{
  "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 사용합니다.

도커 사용하기

모든 환경 변수에 대한 자세한 내용은 환경 변수를 참조하세요.

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 데이터 필드 세트( xoxc-... )의 인증 데이터 토큰 필드 token

SLACK_MCP_XOXD_TOKEN

예

nil

쿠키 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 라이선스에 따라 배포됩니다. 라이선스 파일을 참조하세요. 이 제품은 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