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 "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., "@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 provided, the description carries the full burden but only states the purpose, not behavioral details like permissions, rate limits, or side effects.
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 that is concise and front-loaded, with no 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 tool's simplicity (one parameter, no output schema, no annotations), the description is adequate but lacks details about return format or error conditions.
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%, and the description adds no extra meaning beyond what the schema already provides for the single parameter.
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') and the resource ('detailed profile information for a specific user'), and it is distinct from siblings like slack_get_users which lists users.
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, nor does it mention prerequisites or exclusions.
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 provided, so description bears full burden. It states 'basic profile information' but doesn't specify fields, and omits mentions of rate limits, caching, or whether only active users are returned. Behavior is minimally disclosed.
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 with no extraneous information. Direct and efficient for a simple list operation.
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 tool with no output schema and no annotations, the description is adequate but missing details on return value structure and pagination behavior. Given low complexity, it is minimally viable 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% with cursor and limit already described. The description adds no additional meaning beyond the schema, so 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?
Description clearly states the tool gets a list of all users with basic profile info. Verb 'Get' and resource 'list of all users' are specific, and it distinguishes from siblings like slack_get_user_profile and 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 indication of when to use this tool vs alternatives like slack_get_user_profile. No mention of prerequisites or when not to use. Guidance is completely absent.
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?
With no annotations provided, the description must fully disclose behavior. It mentions pagination and the scope (bot's membership) but does not explicitly state it is a read-only operation, nor does it address auth requirements or rate limits. The term 'pre-defined' is vague.
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?
A single, well-structured sentence that front-loads the main action and scope. Every word earns its place with no fluff.
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 simplicity of the tool (2 params, no output schema, no nested objects), the description is largely complete. It covers what is listed and pagination, but could be slightly more explicit about the 'pre-defined' channels concept.
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 both parameters described. The description adds 'pagination' context but does not enhance understanding beyond the schema. Baseline score of 3 is appropriate as no additional semantic value is provided.
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 'list' and the resource 'channels', specifying scope as public/private channels the bot is a member of or pre-defined channels, with pagination. This distinguishes it from sibling tools like slack_add_reaction 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?
There is no explicit guidance on when to use this tool versus alternatives. No exclusions or context about when not to use it are provided, leaving the agent to infer usage from the description alone.
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. Dates show when Glama detected each change.
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_threadEach 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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
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.
Drop-in proxy keeping OpenAI Assistants API calls working past the August 26, 2026 sunset, plus a Th
Real-time chat hub for AI agents — Claude Code, Cursor, Cline, Codex over MCP or REST.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/zencoderai/slack-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
