Provides tools for listing channels, posting messages, replying to threads, adding reactions, and getting channel history and thread replies in Slack.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@simple-slack-mcp-server post 'Hello' to #general"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A simplified MCP (Model Context Protocol) server for accessing Slack API. This server allows AI assistants to interact with essential Slack messaging and channel operations through a standardized interface.
This server uses stdio transport only for direct integration with MCP clients like Claude Desktop.
Related MCP server: MCP Slack Python
Available tools focused on core messaging and channel operations:
slack_list_channels - List public channels in the workspace with pagination
slack_post_message - Post a new message to a Slack channel
slack_reply_to_thread - Reply to a specific message thread in Slack
slack_add_reaction - Add a reaction emoji to a message
slack_get_channel_history - Get recent messages from a channel
slack_get_thread_replies - Get all replies in a message thread
npm install simple-slack-mcp-serverYou need to set the following environment variable:
SLACK_BOT_TOKEN: Slack Bot User OAuth Token
You can create a .env file to set this environment variable:
SLACK_BOT_TOKEN=xoxb-your-bot-tokennpx simple-slack-mcp-serverYou can also run the installed module with node:
node node_modules/.bin/slack-mcp-serverFor Claude Desktop and other MCP clients:
{
"slack": {
"command": "npx",
"args": [
"simple-slack-mcp-server"
],
"env": {
"SLACK_BOT_TOKEN": "<your-bot-token>"
}
}
}See examples/README.md for detailed client examples.
Your Slack bot needs the following OAuth scopes:
channels:read - To list channels
chat:write - To post messages
chat:write.public - To post in public channels
reactions:write - To add reactions
This server adopts the following implementation pattern:
Define request/response using Zod schemas
Request schema: Define input parameters
Response schema: Define responses limited to necessary fields
Implementation flow:
Validate request with Zod schema
Call Slack WebAPI
Parse response with Zod schema to limit to necessary fields
Return as JSON
For example, the slack_list_channels implementation parses the request with ListChannelsRequestSchema, calls slackClient.conversations.list, and returns the response parsed with ListChannelsResponseSchema.
npm run dev - Start the server in development mode with hot reloading
npm run build - Build the project for production
npm run start - Start the production server
npm run lint - Run linting checks (ESLint and Prettier)
npm run fix - Automatically fix linting issues
npm run examples - Run the example client
Fork the repository
Create your feature branch
Run tests and linting: npm run lint
Commit your changes
Push to the branch
Create a Pull Request
Add a reaction emoji to a message
| Name | Required | Description | Default |
|---|---|---|---|
| reaction | Yes | The name of the emoji reaction (without ::) | |
| timestamp | Yes | The timestamp of the message to react to in the format '1234567890.123456' | |
| channel_id | Yes | The ID of the channel containing the message |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states the action without disclosing behavioral traits such as required permissions (e.g., 'reactions:write' scope), idempotency, rate limits, or error handling. For a mutation tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with the action, no unnecessary words. Every word contributes to clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple action tool with no output schema, the description is minimally complete. However, it does not mention the return value (e.g., success/failure) or potential errors, which would be helpful for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for all three parameters including format constraints for timestamp. The description adds no additional parameter information, but the schema suffices, resulting in a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Add a reaction emoji to a message' clearly states the action (add) and the resource (reaction emoji to a message), distinguishing it from sibling tools like slack_post_message or slack_list_channels.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The context is implied (when you want to react), but no exclusions or prerequisites are mentioned, leaving the agent to infer applicability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get messages from a channel in chronological order. Use this when: 1) You need the latest conversation flow without specific filters, 2) You want ALL messages including bot/automation messages, 3) You need to browse messages sequentially with pagination. Do NOT use if you have specific search criteria (user, keywords, dates) - use slack_search_messages instead.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of messages to retrieve (default 100) | |
| cursor | No | Pagination cursor for next page of results | |
| channel_id | Yes | The ID of the channel. Use this tool for: browsing latest messages without filters, getting ALL messages including bot/automation messages, sequential pagination. If you need to search by user, keywords, or dates, use slack_search_messages instead. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses chronological order, inclusion of bot messages, and pagination support, but omits rate limits, authentication requirements, or any potential side effects. Moderate disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is brief (2 sentences plus a list) and front-loaded with the primary action. The list format aids readability, though the second sentence partially repeats schema info. Very efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple fetch tool with 3 parameters and no output schema, the description covers purpose, usage conditions, and pagination. Does not describe return format, but this is mitigated by the schema descriptions. Adequate for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with detailed parameter descriptions (e.g., channel_id includes usage guidance, limit has default and bounds). The tool description adds no extra semantic value beyond the schema, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool retrieves messages from a channel in chronological order. It distinguishes from sibling tools by specifying use cases and explicitly naming an alternative (slack_search_messages) for filtered searches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use conditions (three numbered points) and a clear when-not-to-use condition (specific search criteria). Directs to an alternative tool, offering actionable guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all replies in a message thread
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of replies to retrieve (default 100) | |
| cursor | No | Pagination cursor for next page of results | |
| thread_ts | Yes | The timestamp of the parent message in the format '1234567890.123456'. Timestamps in the format without the period can be converted by adding the period such that 6 numbers come after it. | |
| channel_id | Yes | The ID of the channel containing the thread |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits but only restates the basic action. It omits pagination behavior, rate limits, or whether the parent message is included.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The single-sentence description is concise and front-loaded with the action, but slightly too sparse to be excellent. It could include more detail without sacrificing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters and no output schema, but the description does not explain return value format, pagination handling, or any constraints. It is incomplete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds no additional meaning beyond what the schema already provides for parameters like cursor and limit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get all replies in a message thread' clearly states the action (get) and the resource (replies in a thread), distinguishing it from sibling tools that handle channels, posting messages, or adding reactions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 slack_get_channel_history. It does not mention prerequisites or context for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List public channels in the workspace with pagination
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of channels to return (default 100) | |
| cursor | No | Pagination cursor for next page of results |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that it lists public channels and supports pagination. However, it does not mention rate limits, required permissions, or whether it returns all public channels or only those the user is a member of. This adds some value but is not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the verb and resource. Every word is purposeful and there is no extraneous information, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with pagination, the description covers the core purpose and pagination mechanism. It does not describe the return format or additional behavior, but given the simplicity, it is nearly complete. A slight gap is the lack of mention that it lists only public channels.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both 'limit' and 'cursor' are already described in the schema parameters. The description adds no additional semantic detail beyond what the schema provides, so it meets the baseline but does not enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List public channels in the workspace with pagination', specifying the verb 'list', resource 'public channels', scope 'workspace', and mentions pagination. This distinguishes it from sibling tools like slack_post_message or slack_get_channel_history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives or when not to use it. It implies a read operation but lacks guidance on context, such as for obtaining a list of channels before posting or searching. Without explicit when/when-not, it is adequate but has gaps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Post a plain text message to a Slack channel or reply to a thread
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The message text to post | |
| thread_ts | No | Optional timestamp of parent message to reply in thread. Format: '1234567890.123456' | |
| channel_id | Yes | The ID of the channel to post to |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states the action without disclosing side effects, required permissions, rate limits, or any behavioral details beyond the obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no filler, front-loaded with key action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple post tool, but lacks mention of limitations (max length, formatting rules) and does not clarify the difference from rich message sibling, leaving some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% as all three parameters have descriptions. The description adds no extra meaning beyond what the schema already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action (post) and resource (Slack channel or thread), and explicitly mentions 'plain text', distinguishing it from siblings like slack_post_rich_message.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied from the description but no explicit when/when-not guidance or mention of alternatives like slack_post_rich_message is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Post a rich structured message to Slack with Block Kit support. Can post to channels or reply to threads. Supports plain text, markdown formatting, and rich Block Kit layouts with sections, images, dividers, headers, and more.
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | Fallback text for notifications and screen readers. Required if blocks is not provided. | |
| parse | No | How to parse text content. "full" enables link and mrkdwn parsing. | |
| blocks | No | Block Kit blocks for structured message layout. Required if text is not provided. | |
| thread_ts | No | Optional timestamp of parent message to reply in thread. Format: '1234567890.123456' | |
| channel_id | Yes | The ID of the channel to post to | |
| unfurl_links | No | Enable automatic link previews | |
| unfurl_media | No | Enable automatic media previews |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description bears full burden. It explains that the tool can post to channels or reply to threads, but does not disclose requirements, limitations, or error behaviors. More detail would be helpful for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action and resource, followed by supported features. No unnecessary words, highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, nested blocks, no output schema), the description covers the main use cases without being verbose. It could mention the required fallback text relationship, but schema handles that. Still, it is adequately complete for an agent to invoke.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds that it supports plain text, markdown, and Block Kit layouts, but this is already evident from the schema. It does not provide new parameter-specific insights beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool posts a rich structured message to Slack with Block Kit support, distinguishing it from simpler siblings like slack_post_message. It also mentions posting to channels or replying to threads, leaving no ambiguity about the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies usage for rich formatting but does not explicitly state when to use this tool versus alternatives (e.g., 'use slack_post_message for plain text'). The guidance is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0slack_add_reactionslack_get_channel_historyslack_get_thread_repliesslack_list_channelsslack_post_messageslack_post_rich_messageMost tools have clearly distinct purposes. The two post message tools (plain and rich) overlap slightly, but their descriptions differentiate them. An agent might misselect if not careful, but overall ambiguity is low.
All tools follow a consistent 'slack_verb_noun' pattern with snake_case. The naming is predictable and uniform across all 6 tools.
6 tools is an appropriate number for a Slack integration focused on core messaging and channel interaction. It covers essential actions without being too sparse or bloated.
Covers basic operations like listing channels, posting messages, and reading history/threads. However, a search functionality is referenced in the get_channel_history description but not provided, and missing common actions like creating channels or deleting messages.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for AI dialogue using various LLM models via AceDataCloud
Hosted MCP server connecting AI assistants to 9,000+ apps and 40,000+ actions via Zapier.
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
MCP server for Sendbird — chat users, channels, members, and messages from your AI client.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/bugzy-ai/slack-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
