Provides tools for interacting with Slack workspaces, enabling listing channels, posting messages (with optional markdown formatting), replying to threads, adding reactions, retrieving channel history and thread replies, and managing users (list users, get user profiles).
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-mcp-server post a message to #general: Good morning team!"
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 dudztroyer, 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 (with optional markdown formatting), reply to threads (with optional markdown formatting), add reactions, get channel history, get thread replies, 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
slack_post_markdown_message
Post a new message to a Slack channel with markdown formatting enabled
Required inputs:
channel_id (string): The ID of the channel or user to post to
text (string): The message text with markdown formatting (mrkdwn). Supports bold, italic, code, code blocks, >quotes, <@user_id> mentions, <#channel_id> channel links, and <url|link text> links
Returns: Message posting confirmation and timestamp
slack_reply_to_thread_markdown
Reply to a specific message thread in Slack with markdown formatting enabled
Required inputs:
channel_id (string): The ID of the channel containing the thread
thread_ts (string): 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 (string): The reply text with markdown formatting (mrkdwn). Supports bold, italic, code, code blocks, >quotes, <@user_id> mentions, <#channel_id> channel links, and <url|link text> links
Returns: Reply confirmation and timestamp
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 (plain text and markdown formatting)
Reply to threads (plain text and markdown formatting)
Add reactions
Get channel history
Get thread replies
List users
Get user profiles
npm install
npm run buildnpm install -g dudztroyer/slack-mcp-serverSet 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 httpUse 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 watchThis project includes an automated release workflow that can be triggered manually via GitHub Actions:
Navigate to GitHub Actions: Go to the "Actions" tab in your GitHub repository
Select Release Workflow: Click on "Create Release" workflow
Run Workflow: Click "Run workflow" button
Configure Release:
Version bump type: Choose from patch, minor, or major
The automated release process leverages changelogen to handle most of the release process:
Quality Checks: Ensures all tests pass and code builds successfully
Changelogen Release: Uses changelogen --release --push and changelogen gh release to:
Generate beautiful changelog from Conventional Commits
Bump version in package.json according to your selection
Create and push git tag
Commit and push all changes
Create GitHub release with changelog as release notes
Distribution & Assets: Adds distribution archive to the GitHub release
Trigger Downstream: Automatically triggers:
Package publishing to GitHub Package Registry (publish.yml)
Patch (1.0.0 → 1.0.1): Bug fixes and minor changes
Minor (1.0.0 → 1.1.0): New features that don't break existing functionality
Major (1.0.0 → 2.0.0): Breaking changes
The release workflow uses changelogen which works best with Conventional Commits. To get the most beautiful and informative changelogs, format your commit messages like:
feat: add new slack reaction tool - New features
fix: resolve channel history pagination issue - Bug fixes
docs: update README with Docker instructions - Documentation changes
chore: update dependencies - Maintenance tasks
refactor: simplify error handling logic - Code refactoring
perf: optimize message processing - Performance improvements
This will result in properly categorized and formatted changelog entries.
When 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. Accepts both channel names (#general, general) and channel IDs (C1234567890).
| Name | Required | Description | Default |
|---|---|---|---|
| channel | Yes | The channel name (e.g., #general, general) or channel ID (e.g., C1234567890) 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?
Given no annotations, the description carries full burden. It mentions both channel name and ID acceptance but lacks details on effects (e.g., idempotency, error behavior) which is minimal but acceptable for a simple action.
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 concise sentences with no fluff. Every part adds value, front-loaded with the core purpose.
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 3 required parameters and no output schema, the description covers the purpose and parameter format adequately. Lack of return value or error info is a minor gap.
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 adds no new meaning 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?
The description clearly states the action 'Add a reaction emoji to a message' with a specific verb and resource. It distinguishes from sibling tools which focus on getting channels, messages, or profiles.
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 simply states what it does without context on prerequisites, limitations, or alternative tools.
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. Accepts both channel names (#general, general) and channel IDs (C1234567890).
| Name | Required | Description | Default |
|---|---|---|---|
| channel | Yes | The channel name (e.g., #general, general) or channel ID (e.g., C1234567890) | |
| limit | No | Number of messages to retrieve (default 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It states the basic read operation but does not disclose behavioral traits such as the recency criterion (e.g., latest messages only), pagination, rate limits, or authentication requirements. The description is too minimal to fully inform an agent.
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 two sentences long, front-loaded with purpose, and no extraneous information. Every sentence is essential.
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 two parameters are well-described in the schema, but no output schema exists, the description does not explain the return format (e.g., array of messages) or ordering. It adequately covers purpose and parameter flexibility but leaves some contextual gaps for an 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 description coverage is 100%, so the schema already documents both parameters. The description reiterates the channel parameter's flexibility (names with/without # and IDs), which adds no new meaning beyond the schema. 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 'Get' and resource 'recent messages from a channel'. It distinguishes from siblings like slack_get_thread_replies and slack_list_channels by specifying it retrieves channel history, not replies or channel lists.
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 says what the tool does but does not explicitly state when to use it versus alternatives. It mentions channel format flexibility but lacks guidance on when to prefer this tool over other Slack message retrieval tools.
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. Accepts both channel names (#general, general) and channel IDs (C1234567890).
| Name | Required | Description | Default |
|---|---|---|---|
| channel | Yes | The channel name (e.g., #general, general) or channel ID (e.g., C1234567890) 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?
Without annotations, the description carries the burden. It correctly implies a read operation but does not disclose rate limits, pagination, or whether all replies are returned. Adequate but minimal.
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 concise sentences, front-loaded with purpose and followed by input flexibility. 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?
A simple tool with 2 required parameters and no output schema. Input format is well explained, but absence of output description (e.g., what each reply object contains) leaves room for improvement.
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%, but the description adds value by explaining channel name formats and the thread_ts period conversion, which goes beyond the schema description.
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 tool gets all replies in a message thread, using a specific verb and resource. It distinguishes from sibling tools like slack_reply_to_thread which post 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 on when to use this tool versus alternatives like slack_get_channel_history. No context on 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 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 with markdown formatting enabled. Accepts both channel names (#general, general) and channel IDs (C1234567890). Supports Slack's mrkdwn formatting like bold, italic, code, code blocks, >quotes, and links.
| Name | Required | Description | Default |
|---|---|---|---|
| channel | Yes | The channel name (e.g., #general, general) or channel ID (e.g., C1234567890) to post to. Also accepts user IDs for direct messages. | |
| text | Yes | The message text with markdown formatting (mrkdwn). Supports *bold*, _italic_, `code`, ```code blocks```, >quotes, <@user_id> mentions, <#channel_id> channel links, and <url|link text> links. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. Discloses markdown support and channel formats, but doesn't mention auth, rate limits, or error behavior 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 crisp sentences, front-loaded with purpose, 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?
Covers key aspects: action, input formats, markdown support. Lacks return value info but acceptable for a simple creation tool.
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%, so baseline is 3. Description adds examples of channel formats and markdown syntax, but mostly reiterates schema descriptions.
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 it posts a new Slack message with markdown formatting. Distinguishes from siblings like slack_post_message (likely plain text) and slack_reply_to_thread_markdown (reply).
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 vs alternatives. Implies use when markdown is needed, but does not contrast with slack_post_message or name alternatives.
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. Accepts both channel names (#general, general) and channel IDs (C1234567890).
| Name | Required | Description | Default |
|---|---|---|---|
| channel | Yes | The channel name (e.g., #general, general) or channel ID (e.g., C1234567890) to post to. Also accepts user IDs for direct messages. | |
| text | Yes | The message text to post |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description adds that channel accepts names, IDs, and user IDs. However, it does not disclose response format, failure behavior, or that it posts plain text (especially important given a sibling markdown tool).
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 purpose, no filler. Every word contributes.
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 2-param tool but lacks mention of return value, authentication prerequisites, or plain-text behavior given sibling tools.
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 enhances the 'channel' parameter by explicitly mentioning acceptance of user IDs for DMs, which is not in 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?
The description clearly states the verb 'post' and the resource 'Slack channel or direct message to user', effectively distinguishing it from siblings like reply or markdown-specific tools.
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 vs alternatives (e.g., slack_post_markdown_message, slack_reply_to_thread). The description only mentions channel format input, not usage context.
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. Accepts both channel names (#general, general) and channel IDs (C1234567890).
| Name | Required | Description | Default |
|---|---|---|---|
| channel | Yes | The channel name (e.g., #general, general) or channel ID (e.g., C1234567890) 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?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It explains the input (reply to a thread) but does not describe side effects (e.g., that the reply is appended to the thread, permissions required, or rate limits). For a mutation tool, this is insufficient for the agent to understand the impact.
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 two concise sentences covering purpose and a key detail about channel formats. It is front-loaded and contains no unnecessary words. However, it could be slightly more informative without becoming verbose (e.g., mentioning plain text vs markdown).
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 (3 required params, no output schema), the description is mostly adequate but missing context about the return value (likely the message object), error cases (e.g., invalid thread_ts), or that it requires write permissions. For a well-understood action like replying to a thread, this may be sufficient, but additional context would improve completeness.
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%, so the baseline is 3. The description adds no new information beyond the schema's parameter descriptions; it repeats the channel format flexibility already documented. No additional meaning or context is provided for the thread_ts or text parameters.
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 it replies to a Slack thread, specifying the resource (thread) and the action (reply). It distinguishes from siblings like slack_post_message (which sends a new message, not a reply) and slack_get_thread_replies (read-only). However, it does not differentiate from slack_reply_to_thread_markdown, which may be a markdown variant, so the purpose is slightly ambiguous regarding markdown support.
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 alternative sibling tools such as slack_reply_to_thread_markdown or slack_post_message. It only mentions channel name/ID acceptance, which is a parameter detail rather than usage context. Without exclusions or when-not-to-use guidance, the agent lacks decision support.
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 with markdown formatting enabled. Accepts both channel names (#general, general) and channel IDs (C1234567890). Supports Slack's mrkdwn formatting like bold, italic, code, code blocks, >quotes, and links.
| Name | Required | Description | Default |
|---|---|---|---|
| channel | Yes | The channel name (e.g., #general, general) or channel ID (e.g., C1234567890) 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 with markdown formatting (mrkdwn). Supports *bold*, _italic_, `code`, ```code blocks```, >quotes, <@user_id> mentions, <#channel_id> channel links, and <url|link text> links. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description notes markdown support and parameter formats, but does not disclose authentication needs, rate limits, error behavior, or side effects beyond the obvious reply action.
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 action, no fluff. Every sentence adds meaningful information.
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 rich sibling context, description adequately covers parameter nuances and tool purpose. Could mention return value or error handling, but not critical for a reply tool.
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%, so baseline 3. Description adds value by explaining channel format (name/ID), thread_ts conversion tip, and listing supported markdown syntax, exceeding schema descriptions.
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 it replies to a specific message thread in Slack with markdown formatting enabled. It distinguishes from sibling tools like 'slack_reply_to_thread' (likely without markdown) and 'slack_post_markdown_message' (new message, not reply).
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?
Implies usage for replies needing markdown, but no explicit when-to-use or when-not-to-use guidance. No mention of alternatives or prerequisites beyond parameter tips.
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.0.5slack_add_reactionslack_get_channel_historyslack_get_thread_repliesslack_get_user_profileslack_get_usersslack_list_channelsslack_post_markdown_messageslack_post_messageslack_reply_to_threadslack_reply_to_thread_markdownEach tool targets a distinct Slack operation: reacting, reading history, threads, user info, listing, posting, and replying. The two posting variants (plain vs markdown) are clearly differentiated, and reply tools also follow the same pattern. No ambiguity.
All tools consistently use the 'slack_' prefix followed by a clear verb_noun pattern in snake_case. Verbs like add, get, list, post, reply are used uniformly. Minor variation between 'get' and 'list' is acceptable and common.
With 10 tools, the set covers a broad but focused range of Slack interactions (message reading/writing, reactions, user and channel info) without being overwhelming or sparse. Each tool feels necessary for typical agent tasks.
Core operations are well-covered: reading channels/threads, posting messages, reacting, and retrieving user/channel info. Missing update/delete message capabilities and search, but these are not critical for common use cases, making the surface mostly complete.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Enable interaction with Slack workspaces. Supports subscribing to Slack events through Resources.
Messaging tools for AI agents: send messages, manage chats, groups and channels.
One place to build, share, and govern the skills and tools your AI agents use at work.
Carbon Voice MCP serves as a bridge that connects AI assistants like ChatGPT, Claude, and Cursor to a user's Carbon Voice account, turning voice messages and conversations into a private, on-demand knowledge base. It provides 28 specialized tools for comprehensive voice messaging management, including creating and sending messages, accessing conversation history with instant transcription, running AI actions (summarization, TLDR generation, meeting notes), and managing workspace collaboration through folders, contacts, and team communications.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/dudztroyer/slack-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
