Enables interaction with Slack workspaces, providing tools to list channels, post messages, reply to threads, add emoji reactions, retrieve channel history, get thread replies, list workspace users, and access user profile information.
Click on "Deploy 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., "@Slack post a message to the general channel reminding everyone about the 2pm meeting"
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.
This project includes code originally developed by Anthropic and released under the MIT License. Substantial modifications and new functionality have been added by For Good AI Inc. (dba Zencoder Inc.), and are licensed under the Apache License, Version 2.0.
Related MCP server: Slack MCP Server
A Model Context Protocol (MCP) server for interacting with Slack workspaces. This server provides tools to list channels, post messages, reply to threads, add reactions, get channel history, and manage users.
slack_list_channels
List public or pre-defined channels in the workspace
Optional inputs:
limit (number, default: 100, max: 200): Maximum number of channels to return
cursor (string): Pagination cursor for next page
Returns: List of channels with their IDs and information
slack_post_message
Post a new message to a Slack channel
Required inputs:
channel_id (string): The ID of the channel to post to
text (string): The message text to post
Returns: Message posting confirmation and timestamp
slack_reply_to_thread
Reply to a specific message thread
Required inputs:
channel_id (string): The channel containing the thread
thread_ts (string): Timestamp of the parent message
text (string): The reply text
Returns: Reply confirmation and timestamp
slack_add_reaction
Add an emoji reaction to a message
Required inputs:
channel_id (string): The channel containing the message
timestamp (string): Message timestamp to react to
reaction (string): Emoji name without colons
Returns: Reaction confirmation
slack_get_channel_history
Get recent messages from a channel
Required inputs:
channel_id (string): The channel ID
Optional inputs:
limit (number, default: 10): Number of messages to retrieve
Returns: List of messages with their content and metadata
slack_get_thread_replies
Get all replies in a message thread
Required inputs:
channel_id (string): The channel containing the thread
thread_ts (string): Timestamp of the parent message
Returns: List of replies with their content and metadata
slack_get_users
Get list of workspace users with basic profile information
Optional inputs:
cursor (string): Pagination cursor for next page
limit (number, default: 100, max: 200): Maximum users to return
Returns: List of users with their basic profiles
slack_get_user_profile
Get detailed profile information for a specific user
Required inputs:
user_id (string): The user's ID
Returns: Detailed user profile information
To use this MCP server, you need to create a Slack app and configure it with the necessary permissions:
Visit the Slack Apps page
Click "Create New App"
Choose "From scratch"
Name your app and select your workspace
Navigate to "OAuth & Permissions" and add these scopes:
channels:history - View messages and other content in public channels
channels:read - View basic channel information
chat:write - Send messages as the app
reactions:write - Add emoji reactions to messages
users:read - View users and their basic information
users.profile:read - View detailed profiles about users
Click "Install to Workspace" and authorize the app
Save the "Bot User OAuth Token" that starts with xoxb-
Get your Team ID (starts with a T) by following this guidance
For the bot to access private channels or to post messages, you may need to invite it to specific channels using /invite @your-bot-name
Multiple Transport Support: Supports both stdio and Streamable HTTP transports
Modern MCP SDK: Updated to use the latest MCP SDK (v1.13.2) with modern APIs
Comprehensive Slack Integration: Full set of Slack operations including:
List channels (with predefined channel support)
Post messages
Reply to threads
Add reactions
Get channel history
Get thread replies
List users
Get user profiles
npm install
npm run buildnpm install -g @zencoderai/slack-mcp-server# Build the Docker image locally
docker build -t slack-mcp-server .
# Or pull from Docker Hub
docker pull zencoderai/slack-mcp:latest
# Or pull a specific version
docker pull zencoderai/slack-mcp:1.0.0Set the following environment variables:
export SLACK_BOT_TOKEN="xoxb-your-bot-token"
export SLACK_TEAM_ID="your-team-id"
export SLACK_CHANNEL_IDS="channel1,channel2,channel3" # Optional: predefined channels
export AUTH_TOKEN="your-auth-token" # Optional: Bearer token for HTTP authorization (Streamable HTTP transport only)slack-mcp [options]
Options:
--transport <type> Transport type: 'stdio' or 'http' (default: stdio)
--port <number> Port for HTTP server when using Streamable HTTP transport (default: 3000)
--token <token> Bearer token for HTTP authorization (optional, can also use AUTH_TOKEN env var)
--help, -h Show this help message# Use stdio transport (default)
slack-mcp
# Use stdio transport explicitly
slack-mcp --transport stdio
# Use Streamable HTTP transport on default port 3000
slack-mcp --transport http
# Use Streamable HTTP transport on custom port
slack-mcp --transport http --port 8080
# Use Streamable HTTP transport with custom auth token
slack-mcp --transport http --token mytoken
# Use Streamable HTTP transport with auth token from environment variable
AUTH_TOKEN=mytoken slack-mcp --transport http# Use stdio transport (default)
node dist/index.js
# Use stdio transport explicitly
node dist/index.js --transport stdio
# Use Streamable HTTP transport on default port 3000
node dist/index.js --transport http
# Use Streamable HTTP transport on custom port
node dist/index.js --transport http --port 8080
# Use Streamable HTTP transport with custom auth token
node dist/index.js --transport http --token mytoken
# Use Streamable HTTP transport with auth token from environment variable
AUTH_TOKEN=mytoken node dist/index.js --transport http# Run with stdio transport (default)
docker run --rm \
-e SLACK_BOT_TOKEN="xoxb-your-bot-token" \
-e SLACK_TEAM_ID="your-team-id" \
zencoderai/slack-mcp:latest
# Run with HTTP transport on port 3000
docker run --rm -p 3000:3000 \
-e SLACK_BOT_TOKEN="xoxb-your-bot-token" \
-e SLACK_TEAM_ID="your-team-id" \
zencoderai/slack-mcp:latest --transport http
# Run with HTTP transport on custom port
docker run --rm -p 8080:8080 \
-e SLACK_BOT_TOKEN="xoxb-your-bot-token" \
-e SLACK_TEAM_ID="your-team-id" \
zencoderai/slack-mcp:latest --transport http --port 8080
# Run with custom auth token
docker run --rm -p 3000:3000 \
-e SLACK_BOT_TOKEN="xoxb-your-bot-token" \
-e SLACK_TEAM_ID="your-team-id" \
-e AUTH_TOKEN="mytoken" \
zencoderai/slack-mcp:latest --transport httpCreate a docker-compose.yml file:
version: '3.8'
services:
slack-mcp:
# Use published image:
image: zencoderai/slack-mcp:latest
# Or build locally:
# build: .
environment:
- SLACK_BOT_TOKEN=xoxb-your-bot-token
- SLACK_TEAM_ID=your-team-id
- SLACK_CHANNEL_IDS=channel1,channel2,channel3 # Optional
- AUTH_TOKEN=your-auth-token # Optional for HTTP transport
ports:
- "3000:3000" # Only needed for HTTP transport
command: ["--transport", "http"] # Optional: specify transport type
restart: unless-stoppedThen run:
# Start the service
docker compose up -d
# View logs
docker compose logs -f slack-mcp
# Stop the service
docker compose downUse case: Command-line tools and direct integrations
Communication: Standard input/output streams
Default: Yes
Use case: Remote servers and web-based integrations
Communication: HTTP POST requests with optional Server-Sent Events streams
Features:
Session management
Bidirectional communication
Resumable connections
RESTful API endpoints
Bearer token authentication
When using Streamable HTTP transport, the server supports Bearer token authentication:
Command Line: Use --token <token> to specify a custom token
Environment Variable: Set AUTH_TOKEN=<token> as a fallback
Auto-generated: If neither is provided, a random token is generated
The command line option takes precedence over the environment variable. Include the token in HTTP requests using the Authorization: Bearer <token> header.
If you encounter permission errors, verify that:
All required scopes are added to your Slack app
The app is properly installed to your workspace
The tokens and workspace ID are correctly copied to your configuration
The app has been added to the channels it needs to access
npm run buildnpm run watchWhen using Streamable HTTP transport, the server exposes the following endpoints:
POST /mcp - Client-to-server communication
GET /mcp - Server-to-client notifications (Server-Sent Events streams)
DELETE /mcp - Session termination
Updated MCP SDK: Upgraded from v1.0.1 to v1.13.2
Modern API: Migrated from low-level Server class to high-level McpServer class
Zod Validation: Added proper schema validation using Zod
Transport Flexibility: Added support for Streamable HTTP transport
Command Line Interface: Added CLI arguments for transport selection
Session Management: Implemented proper session handling for HTTP transport
Better Error Handling: Improved error handling and logging
Add a reaction emoji to a message
| Name | Required | Description | Default |
|---|---|---|---|
| channel_id | Yes | The ID of the channel containing the message | |
| timestamp | Yes | The timestamp of the message to react to | |
| reaction | Yes | The name of the emoji reaction (without ::) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must cover behavioral traits. It only states the action without disclosing idempotency, error handling, or what happens if the reaction already exists.
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 clear sentence, front-loaded and to the point. Could be slightly more informative without harming conciseness.
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 tool with no output schema, the description provides basic understanding but lacks details on return values or error states.
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% and the description adds no additional meaning beyond the schema. Baseline is 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?
Description clearly states the action (Add) and resource (reaction emoji to a message). It is distinct from sibling tools, which involve reading channels or posting messages.
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 on when to use this tool versus alternatives. The description does not specify prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get recent messages from a channel
| Name | Required | Description | Default |
|---|---|---|---|
| channel_id | Yes | The ID of the channel | |
| limit | No | Number of messages to retrieve (default 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description merely says 'get recent messages', which implies a read-only operation but does not explicitly confirm that no state is changed. It lacks details about return format, ordering (e.g., chronological or reverse), pagination, or metadata included. With no annotations, the description carries full burden but fails to disclose important behavioral traits.
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 consists of a single, short sentence that is front-loaded and to the point. However, it may be overly terse, missing an opportunity to add value without significant length. Still, it avoids redundancy and wasted words.
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 absence of an output schema, the description should explain what 'recent messages' means (e.g., time window, ordering) and whether pagination is supported. It does not address these aspects, leaving the agent without sufficient context to use the tool effectively. Sibling tools suggest more detailed descriptions might be needed.
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?
Input schema has 100% description coverage, so the schema already explains both parameters. The description adds no additional meaning for the parameters beyond what they already have. Therefore, the baseline score of 3 is appropriate, as it neither improves nor degrades parameter 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 that the tool retrieves recent messages from a channel, which matches the name and title. It distinguishes from sibling tools like 'slack_get_thread_replies' or 'slack_add_reaction', as it explicitly targets channel history. However, it could be more specific about the resource (e.g., 'get messages' instead of '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?
No guidance is provided on when to use this tool versus alternatives. For example, it doesn't specify that this tool should be used for channel messages rather than thread replies (handled by 'slack_get_thread_replies'). There are no context conditions or exclusions mentioned.
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 |
|---|---|---|---|
| channel_id | Yes | The ID of the channel containing the thread | |
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description accurately describes a read operation but does not disclose any behavioral traits such as rate limits, pagination, or permissions needed. It is minimal but correct.
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, clear sentence with no redundant information. It is appropriately sized and front-loaded.
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?
With no output schema, the description does not explain the return format. For such a simple tool, it is adequate but could be improved by noting what is returned (e.g., array of replies).
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?
Both parameters are fully described in the input schema (100% coverage). The description adds no extra meaning beyond the schema, so the baseline score of 3 applies.
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 directly states 'Get all replies in a message thread', which is a specific verb and resource. It clearly distinguishes from sibling tools like slack_reply_to_thread which is for posting replies.
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 provides no guidance on when to use this tool versus alternatives. There is no mention of prerequisites or scenarios where this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed profile information for a specific user
| Name | Required | Description | Default |
|---|---|---|---|
| user_id | Yes | The ID of the user |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only says 'get detailed profile information' without mentioning authentication, rate limits, or what constitutes 'detailed profile'. This is insufficient for an agent to understand implications.
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 with no wasted words. However, it lacks depth and could be more informative while remaining concise.
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 no output schema and no annotations, the description is insufficiently complete. It doesn't explain what fields the profile contains, any limitations, or the return format, leaving the agent uninformed.
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 one parameter described as 'The ID of the user'. The tool description adds no additional meaning beyond the schema, so it meets the baseline 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 clearly states the verb 'Get' and the resource 'detailed profile information for a specific user', distinguishing it from sibling tools like 'slack_get_users' (which lists users) and messaging tools. It is specific and unambiguous.
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 provides no guidance on when to use this tool versus alternatives, such as 'slack_get_users' for a list of users. There is no mention of context, prerequisites, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a list of all users in the workspace with their basic profile information
| Name | Required | Description | Default |
|---|---|---|---|
| cursor | No | Pagination cursor for next page of results | |
| limit | No | Maximum number of users to return (default 100, max 200) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It states 'Get' which is read-only, but it does not mention pagination (evident from schema), rate limits, or data freshness. For a list tool, this is minimal 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?
One sentence with no redundant information. It is front-loaded with the action and resource, making it 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 no output schema, the description could explain what 'basic profile information' includes. It does not, leaving some ambiguity. Additionally, without annotations, it should mention authentication requirements, but that is standard. Overall adequate but not complete.
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 the description does not need to add parameter details beyond what the schema provides. However, it adds no additional context about how to use cursor or limit effectively.
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 the action 'Get', the resource 'a list of all users', and the scope 'in the workspace with their basic profile information'. This is specific and distinguishes it from siblings like slack_get_user_profile.
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 vs alternatives (e.g., slack_get_user_profile for a single user). Usage context is implied but not guided, and there are no exclusions or when-not-to-use hints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List public and private channels that the bot is a member of, or pre-defined channels in the workspace with pagination
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of channels to return (default 100, max 200) | |
| cursor | No | Pagination cursor for next page of results |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that it lists channels the bot is a member of or pre-defined channels, and mentions pagination. However, no annotations exist, and the description does not state side effects, required permissions, or rate limits. As a read operation, it should explicitly note it does not modify state.
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 redundancy, efficiently packs core information: what is listed and pagination support. Front-loaded with verb 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?
For a simple list tool with 2 parameters and no output schema, the description covers key scope and pagination. Missing details about return fields, but this is not critical given the tool's straightforward nature.
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 limit and cursor. The description adds 'pre-defined channels' context but does not enhance understanding of parameters beyond what the schema already provides. Baseline of 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?
Clearly states it lists public and private channels with pagination, specifying scope (bot member or pre-defined). Does not explicitly differentiate from siblings but the verb 'list' and resource 'channels' are distinct from other tools like posting messages or getting 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?
No guidance on when to use this tool versus alternatives. For example, if an agent needs to find a channel by name or get all channels in workspace, this description does not clarify limitations or suggest other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Post a new message to a Slack channel or direct message to user
| Name | Required | Description | Default |
|---|---|---|---|
| channel_id | Yes | The ID of the channel or user to post to | |
| text | Yes | The message text to post |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only states the basic action and target, failing to disclose behavioral traits like required permissions, message formatting, character limits, or whether the operation is reversible. With no annotations, the description carries the full burden and does not provide sufficient transparency.
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, clear sentence with no unnecessary words or repetition. It is appropriately concise.
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 simple nature of the tool and no output schema, the description is minimally adequate but does not explain return values, error handling, or any side effects. For a tool with no annotations, more context would be beneficial.
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 descriptions for both channel_id and text in the schema. The description adds no additional meaning beyond the schema, 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?
The description clearly states the verb 'post', resource 'message', and target 'Slack channel or direct message to user'. It distinguishes the action from other tools like slack_reply_to_thread but does not explicitly differentiate.
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 such as slack_reply_to_thread for thread replies or slack_add_reaction for adding reactions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reply to a specific message thread in Slack
| Name | Required | Description | Default |
|---|---|---|---|
| channel_id | Yes | The ID of the channel containing the thread | |
| 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. | |
| text | Yes | The reply text |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No behavioral traits beyond the action are disclosed. Without annotations, the description should mention permissions, rate limits, or error behavior, but it does not. The description adds no value beyond the input schema.
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, front-loaded sentence that efficiently states the purpose. It could be slightly more informative without losing conciseness.
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 description does not mention return values or error handling. Since there is no output schema, the user/agent lacks context on what the tool returns (e.g., reply timestamp). Missing completeness for a write operation.
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?
The input schema covers all three parameters with descriptions (100% coverage). The description adds no new meaning; the baseline of 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?
The description clearly states the verb 'Reply' and the resource 'message thread', distinguishing it from siblings like slack_post_message (new message) and slack_get_thread_replies (reading replies).
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 (e.g., slack_post_message for new messages or slack_get_thread_replies for reading replies). The description lacks any usage context.
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.
v1.0.0slack_add_reaction2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falseslack_get_channel_history2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falseslack_get_thread_replies2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falseslack_get_user_profile2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falseslack_get_users2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falseslack_list_channels2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falseslack_post_message2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falseslack_reply_to_thread2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falseslack_add_reactionslack_get_channel_historyslack_get_thread_repliesslack_get_user_profileslack_get_usersslack_list_channelsslack_post_messageslack_reply_to_threadScored across 8 tools
Each tool has a clearly distinct purpose: reacting, reading history, threads, user info, channels, posting, and replying. No overlap or ambiguity.
All tools follow a consistent verb_noun pattern with a 'slack_' prefix (e.g., slack_post_message, slack_list_channels). No mixing of styles.
8 tools is well-scoped for a Slack MCP server, covering essential operations without being too many or too few.
Core CRUD for messaging and user info is covered. Minor gaps exist (e.g., editing/deleting messages, creating channels), but the surface is sufficient for typical workflow.
Enable interaction with Slack workspaces. Supports subscribing to Slack events through Resources.
Talk to your public-facing AI from any MCP client — Claude, ChatGPT, Cursor, Cline, Windsurf.
MCP server for Sendbird — chat users, channels, members, and messages from your AI client.
Central Slack/Telegram router with jobs, memory, approvals, and A2A delegation
