Agentbrisk
communication TypeScript

Slack MCP Server

Connect AI agents to Slack channels for reading, posting, and search


The Slack MCP server connects AI agents to your Slack workspace through the Model Context Protocol. It exposes eight tools covering channel listing, message history, thread replies, posting, and emoji reactions. Auth runs through a Slack Bot Token. The original reference implementation from modelcontextprotocol/servers has been archived; the actively maintained version is now the Zencoder fork, installable via npm or Docker.

If your team lives in Slack, there is a real case for giving your AI agent access to the same feed of information. The Slack MCP server does exactly that: it connects any MCP-compatible client to your Slack workspace, letting agents read channel history, post updates, fetch thread replies, and look up users. It is one of the more-installed MCP servers precisely because team communication is where so much context lives, and most agents currently have no way to reach it.

What it does

The Slack MCP server sits between your AI agent and the Slack Web API. When you ask an agent a question that involves your team's conversations, the agent calls one of the server's eight tools, the server makes the corresponding API call using your Bot Token, and the result comes back as structured data the agent can reason over.

The practical effect is that an agent can do things like pull the last 50 messages from a channel, summarize a long thread without you having to copy-paste anything, or post a standup update to #engineering on your behalf. It does not give the agent access to your entire Slack history by default: you scope it to specific channels using the SLACK_CHANNEL_IDS environment variable, and the Bot Token limits what it can read or write based on the scopes you assign.

Worth being clear about what it does not do. The server does not search messages across channels in the way the Slack UI search does. There is no search tool in the current implementation. If search is central to your use case, that is a gap you will notice quickly. It also does not handle private channels unless you explicitly invite the bot, and it has no file or attachment handling.

The original implementation was part of the modelcontextprotocol/servers reference repo. That code has since been archived and the repo points users to the Zencoder-maintained fork at github.com/zencoderai/slack-mcp-server, which is the version you should install in 2026.

Capabilities and tools

The server exposes eight tools. Here is what each one actually does in practice:

slack_list_channels returns public channels in your workspace with optional pagination. It respects the SLACK_CHANNEL_IDS filter if you set one, which is useful for keeping an agent focused on a few channels rather than surfing everything.

slack_get_channel_history fetches recent messages from a specific channel. You pass a channel ID and an optional limit. This is the core read tool: most use cases that involve understanding what has been discussed start here.

slack_get_thread_replies retrieves all replies within a message thread. Threads are where detailed technical discussions happen in most teams, so this one ends up being essential if you want the agent to actually understand context rather than just seeing the top-level message.

slack_post_message posts a new message to a channel. This is the write tool most people want. It requires a channel ID and the message text. Formatting is plain text; you can include Slack's mrkdwn syntax manually if needed.

slack_reply_to_thread posts a reply to an existing thread rather than a top-level message. You pass the channel, the thread's timestamp, and your text. Good for having the agent participate in an ongoing conversation without starting a new one.

slack_add_reaction adds an emoji reaction to a specific message. It needs the channel ID, the message timestamp, and the emoji name without colons. Useful for acknowledgment workflows: an agent that marks a request as seen or in-progress.

slack_get_users returns a list of workspace users with basic profile information. Handy for translating user IDs in message history into readable names.

slack_get_user_profile fetches detailed profile data for a specific user ID. Timezone, display name, title, and whatever else the user has filled in.

One tool that is notably absent is any form of message search. The Slack search API exists and works well, but the server does not expose it. If you need cross-channel search you will have to extend the server or use a different approach.

Setup and authentication

You need two things: a Slack app with the right scopes, and the npm package installed and wired into your MCP client config.

Start at api.slack.com/apps. Create a new app from scratch, choose "OAuth and Permissions" in the sidebar, and add these six bot token scopes: channels:history, channels:read, chat:write, reactions:write, users:read, users.profile:read. If you do not need reactions or user lookups, leave those out. Then install the app to your workspace and copy the Bot Token that starts with xoxb-. Also grab your Team ID from the workspace URL or workspace settings; it starts with T.

Install the server:

npm install -g @zencoderai/slack-mcp-server

Then add it to your MCP client config. For Claude Desktop:

{
  "mcpServers": {
    "slack": {
      "command": "slack-mcp",
      "env": {
        "SLACK_BOT_TOKEN": "xoxb-your-token-here",
        "SLACK_TEAM_ID": "T0123456789",
        "SLACK_CHANNEL_IDS": "C0123,C0456"
      }
    }
  }
}

For Claude Code or Cline, the pattern is the same: add the server entry to whichever config file your client reads, set the env vars, and restart. The eight Slack tools should appear in your client's tool list.

Docker is also available if you prefer: docker pull zencoderai/slack-mcp:latest. This is more relevant for running the server as a shared resource on a team server rather than on each developer's machine.

Common use cases

Standup automation. An agent can call slack_get_channel_history on your standup channel each morning, summarize what each person posted, and generate a digest. This works well when the team has a consistent standup format. The agent does not need to search, just read recent messages from one channel.

Summarizing long threads. When a thread has 40 replies and you need to catch up fast, you can ask the agent to fetch the thread with slack_get_thread_replies and summarize the key decisions or blockers. This is one of the cleaner use cases because the agent is doing a real cognitive task rather than just piping data around.

Customer feedback triage. Teams that route inbound feedback to a Slack channel can use an agent to read new messages, classify them by type or urgency, and either reply with an acknowledgment or post a structured summary to a separate internal channel. The combination of slack_get_channel_history, some classification logic, and slack_post_message covers this workflow without much custom code.

Automated notifications. If you have an agent running a longer pipeline (a build monitor, a data quality check, a deploy watcher), it can call slack_post_message to report results to a channel. This pairs well with any agent that already runs on a schedule.

These use cases all share a common trait: they work best on focused, predictable channels where the format is consistent. Open-ended use across an entire workspace tends to produce noisier results.

Security considerations

A Slack Bot Token is a long-lived credential that gives persistent write access to your workspace. Treat it the same way you would a database password: do not put it in a config file that gets committed to version control, and do not share it across environments.

The practical minimum for a read-only workflow is channels:history and channels:read. Add chat:write only if the agent needs to post. Add reactions:write and user scopes only if you have a specific reason. Every scope you add is an additional capability an attacker gets if the token leaks.

Use SLACK_CHANNEL_IDS to restrict the agent to the channels it actually needs. An agent scoped to three channels is much less damaging if something goes wrong than one with workspace-wide read access.

Audit what your agent posts. Agents can and do produce incorrect or confidential information. Having the agent post to a private internal channel first, rather than a public one, gives you a review step before anything reaches a broader audience.

For compliance-sensitive organizations: messages the agent reads and posts are processed by whatever AI model you have connected. If your Slack workspace contains data subject to GDPR, HIPAA, or similar regulations, you need to verify that your AI model's data handling policies are compatible before using this server.

Alternatives and complements

The Zencoder fork is the de-facto standard Slack MCP server right now, but it is not your only option.

The SecretiveShell/MCP-Slack repo on GitHub is an older community implementation. It takes a similar approach but has seen less maintenance activity than the Zencoder fork. If you need a feature the Zencoder server lacks, checking that repo's issues or forking it yourself is a reasonable path.

The modelcontextprotocol/servers-archived repo still has the original reference implementation at src/slack. It still runs, but it is not receiving updates. Useful if you want to understand how the original worked or if you need to audit the code for a specific reason.

If your requirements go significantly beyond what the current eight tools offer, consider Slack Bolt (the official Slack SDK for Node.js and Python). You can wrap Bolt in a simple MCP server of your own, which gives you access to the full Slack Web API rather than eight pre-defined tools. The tradeoff is more code to maintain.

For teams already using Claude Code or looking at Cline as their primary coding agent, the Slack MCP server works alongside coding-focused servers without conflict. You can have both the Filesystem MCP server and the Slack server active simultaneously, which opens up patterns like having an agent read a bug report from Slack and then look at the relevant code.

The bottom line

The Slack MCP server solves a genuine problem: your AI agent knows nothing about your team's conversations unless you build a bridge. This server is that bridge. The Zencoder fork is actively maintained, installs in minutes, and covers the most common read and write operations.

The real-world limitations are worth being honest about. No search, no private channel access by default, no file handling, and a token model that requires careful credential management. It is not a full Slack API wrapper and does not try to be.

For teams that want an agent to monitor a handful of channels, summarize discussions, and post structured output, this server does the job. Start with read-only scopes, test on a non-critical channel, and expand from there. Check the MCP servers directory for servers that pair well with it, and see how other agents like those reviewed in the best AI agent for coding roundup handle multi-tool workflows.

Features

  • List public channels with pagination
  • Read channel history and thread replies
  • Post messages and reply to threads
  • Add emoji reactions to messages
  • Fetch workspace users and user profiles
  • HTTP or stdio transport support
  • Docker image available for server deployments

How to set up the Slack MCP Server MCP server

  1. Create a Slack app at api.slack.com/apps and install it to your workspace
  2. Add six bot scopes: channels:history, channels:read, chat:write, reactions:write, users:read, users.profile:read
  3. Copy the Bot Token (xoxb-...) and your workspace Team ID (starts with T)
  4. Install via npm: npm install -g @zencoderai/slack-mcp-server
  5. Add the server to your MCP client config with SLACK_BOT_TOKEN and SLACK_TEAM_ID env vars
  6. Restart your MCP client and verify the eight Slack tools appear

Frequently Asked Questions

What is the Slack MCP server?
The Slack MCP server is a Model Context Protocol server that gives AI agents access to your Slack workspace. Through eight tool calls, an agent can list channels, read message history, fetch thread replies, post messages, reply to threads, add emoji reactions, and retrieve user profiles. It authenticates with a Slack Bot Token, so the agent operates under whatever permissions you grant the bot.
Is the Slack MCP server official?
No. The original reference implementation was part of modelcontextprotocol/servers but has been archived. The actively maintained version is the Zencoder fork at github.com/zencoderai/slack-mcp-server. There is no Slack-published MCP server as of May 2026.
How do I set up the Slack MCP server?
Create a Slack app at api.slack.com/apps, add the required bot scopes, install the app to your workspace, and copy the Bot Token and Team ID. Then install the npm package globally and add a server entry to your MCP client config with those two environment variables. The whole process takes about ten minutes.
What permissions does the Slack MCP server need?
Six bot token scopes are required: channels:history and channels:read to read messages, chat:write to post, reactions:write to add emoji, and users:read plus users.profile:read to look up people. You can omit reactions:write or users scopes if your use case does not need them, which is a good way to reduce the bot's footprint.
Can the Slack MCP server post DMs?
Not directly with the current tool set. The slack_post_message tool targets channel IDs, not user IDs. To post a DM you would need to open a DM channel via the Slack API and use that channel ID, which is not something the server handles automatically. For DM use cases you are better off with a custom Slack bot built on the Bolt SDK.
Is Slack MCP safe for production use?
It depends on how you configure it. The server itself is straightforward code with no known security issues, but the Bot Token grants persistent write access to your workspace. In production you should restrict the token to the minimum scopes, store it in a secret manager rather than a config file, and limit SLACK_CHANNEL_IDS to the channels the agent actually needs. For read-only workflows, consider a User Token with limited scope instead.
Search