The Slack MCP Server enables AI assistants to interact with Slack's API through a standardized interface, providing tools for:
Message Management: Post messages to channels, reply to threads, add emoji reactions
Channel Operations: List public channels, get channel message history
User Information: Retrieve basic and detailed user profile information
Search Functionality: Find messages across the workspace with customizable filters
These capabilities allow AI assistants to effectively communicate and gather information within Slack workspaces.
Supports environment variable configuration through .env files for storing Slack tokens and other configuration settings.
Integrated for code linting during development to maintain code quality and consistency.
Hosts the package in GitHub Registry, requiring a Personal Access Token (PAT) for installation and access to the MCP server package.
Used as the package manager for installing and running the MCP server package.
Used for code formatting to ensure consistent code style across the project.
Provides tools for interacting with Slack API, including listing channels, posting messages, replying to threads, adding reactions, retrieving channel history, getting thread replies, retrieving user information, and searching messages in a Slack workspace.
Used for defining and validating request/response schemas, ensuring proper data structure for API interactions and limiting response fields to necessary data.
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 MCP Server post a message to the #general channel saying 'Team meeting starts in 5 minutes'"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A MCP(Model Context Protocol) server for accessing Slack API. This server allows AI assistants to interact with the Slack API through a standardized interface.
This server supports both traditional and modern MCP transport methods:
Stdio Transport (default): Process-based communication for local integration
Streamable HTTP Transport: HTTP-based communication for web applications and remote clients
Related MCP server: Slack MCP Server
Available tools:
slack_list_channels - List public channels in the workspace with pagination
slack_post_message - Post a new message to a Slack channel
slack_reply_to_thread - Reply to a specific message thread in Slack
slack_add_reaction - Add a reaction emoji to a message
slack_get_channel_history - Get recent messages from a channel
slack_get_thread_replies - Get all replies in a message thread
slack_get_users - Retrieve basic profile information of all users in the workspace
slack_get_user_profiles - Get multiple users' profile information in bulk (efficient for batch operations)
slack_search_messages - Search for messages in the workspace with powerful filters:
Basic query search
Location filters: in_channel
User filters: from_user, with
Date filters: before (YYYY-MM-DD), after (YYYY-MM-DD), on (YYYY-MM-DD), during (e.g., "July", "2023")
Content filters: has (emoji reactions), is (saved/thread)
Sorting options by relevance score or timestamp
npm install @ubie-oss/slack-mcp-serverNOTE: Its now hosted in GitHub Registry so you need your PAT.
You need to set the following environment variables:
SLACK_BOT_TOKEN: Slack Bot User OAuth Token
SLACK_USER_TOKEN: Slack User OAuth Token (required for some features like message search)
SLACK_SAFE_SEARCH (optional): When set to true, automatically excludes private channels, DMs, and group DMs from search results. This is enforced server-side and cannot be overridden by clients.
You can also create a .env file to set these environment variables:
SLACK_BOT_TOKEN=xoxb-your-bot-token
SLACK_USER_TOKEN=xoxp-your-user-token
SLACK_SAFE_SEARCH=true # Optional: Enable safe search modeStdio Transport (default):
npx @ubie-oss/slack-mcp-serverStreamable HTTP Transport:
npx @ubie-oss/slack-mcp-server -port 3000You can also run the installed module with node:
# Stdio transport
node node_modules/.bin/slack-mcp-server
# HTTP transport
node node_modules/.bin/slack-mcp-server -port 3000Command Line Options:
-port <number>: Start with Streamable HTTP transport on specified port
-h, --help: Show help message
For Stdio Transport (Claude Desktop, etc.):
{
"slack": {
"command": "npx",
"args": [
"-y",
"@ubie-oss/slack-mcp-server"
],
"env": {
"NPM_CONFIG_//npm.pkg.github.com/:_authToken": "<your-github-pat>",
"SLACK_BOT_TOKEN": "<your-bot-token>",
"SLACK_USER_TOKEN": "<your-user-token>",
"SLACK_SAFE_SEARCH": "true"
}
}
}For Streamable HTTP Transport (Web applications):
Start the server:
SLACK_BOT_TOKEN=<your-bot-token> SLACK_USER_TOKEN=<your-user-token> npx @ubie-oss/slack-mcp-server -port 3000Connect to: http://localhost:3000/mcp
See examples/README.md for detailed client examples.
This server adopts the following implementation pattern:
Define request/response using Zod schemas
Request schema: Define input parameters
Response schema: Define responses limited to necessary fields
Implementation flow:
Validate request with Zod schema
Call Slack WebAPI
Parse response with Zod schema to limit to necessary fields
Return as JSON
For example, the slack_list_channels implementation parses the request with ListChannelsRequestSchema, calls slackClient.conversations.list, and returns the response parsed with ListChannelsResponseSchema.
npm run dev - Start the server in development mode with hot reloading
npm run build - Build the project for production
npm run start - Start the production server
npm run lint - Run linting checks (ESLint and Prettier)
npm run fix - Automatically fix linting issues
Fork the repository
Create your feature branch
Run tests and linting: npm run lint
Commit your changes
Push to the branch
Create a Pull Request
Add a reaction emoji to a message
| Name | Required | Description | Default |
|---|---|---|---|
| channel_id | Yes | The ID of the channel containing the message | |
| reaction | Yes | The name of the emoji reaction (without ::) | |
| timestamp | Yes | The timestamp of the message to react to in the format '1234567890.123456' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states the action without disclosing behavioral traits such as required permissions (e.g., 'reactions:write' scope), idempotency, rate limits, or error handling. For a mutation tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with the action, no unnecessary words. Every word contributes to clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple action tool with no output schema, the description is minimally complete. However, it does not mention the return value (e.g., success/failure) or potential errors, which would be helpful for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for all three parameters including format constraints for timestamp. The description adds no additional parameter information, but the schema suffices, resulting in a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Add a reaction emoji to a message' clearly states the action (add) and the resource (reaction emoji to a message), distinguishing it from sibling tools like slack_post_message or slack_list_channels.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The context is implied (when you want to react), but no exclusions or prerequisites are mentioned, leaving the agent to infer applicability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get messages from a channel in chronological order. Use this when: 1) You need the latest conversation flow without specific filters, 2) You want ALL messages including bot/automation messages, 3) You need to browse messages sequentially with pagination. Do NOT use if you have specific search criteria (user, keywords, dates) - use slack_search_messages instead.
| Name | Required | Description | Default |
|---|---|---|---|
| channel_id | Yes | The ID of the channel. Use this tool for: browsing latest messages without filters, getting ALL messages including bot/automation messages, sequential pagination. If you need to search by user, keywords, or dates, use slack_search_messages instead. | |
| cursor | No | Pagination cursor for next page of results | |
| limit | No | Number of messages to retrieve (default 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses chronological order, inclusion of bot messages, and pagination support, but omits rate limits, authentication requirements, or any potential side effects. Moderate disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is brief (2 sentences plus a list) and front-loaded with the primary action. The list format aids readability, though the second sentence partially repeats schema info. Very efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple fetch tool with 3 parameters and no output schema, the description covers purpose, usage conditions, and pagination. Does not describe return format, but this is mitigated by the schema descriptions. Adequate for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with detailed parameter descriptions (e.g., channel_id includes usage guidance, limit has default and bounds). The tool description adds no extra semantic value beyond the schema, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool retrieves messages from a channel in chronological order. It distinguishes from sibling tools by specifying use cases and explicitly naming an alternative (slack_search_messages) for filtered searches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use conditions (three numbered points) and a clear when-not-to-use condition (specific search criteria). Directs to an alternative tool, offering actionable guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all replies in a message thread
| Name | Required | Description | Default |
|---|---|---|---|
| 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. | |
| cursor | No | Pagination cursor for next page of results | |
| limit | No | Number of replies to retrieve (default 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits but only restates the basic action. It omits pagination behavior, rate limits, or whether the parent message is included.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The single-sentence description is concise and front-loaded with the action, but slightly too sparse to be excellent. It could include more detail without sacrificing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters and no output schema, but the description does not explain return value format, pagination handling, or any constraints. It is incomplete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds no additional meaning beyond what the schema already provides for parameters like cursor and limit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get all replies in a message thread' clearly states the action (get) and the resource (replies in a thread), distinguishing it from sibling tools that handle channels, posting messages, or adding reactions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like slack_get_channel_history. It does not mention prerequisites or context for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get multiple users profile information in bulk
| Name | Required | Description | Default |
|---|---|---|---|
| user_ids | Yes | Array of user IDs to retrieve profiles for (max 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full behavioral disclosure. It only states a read operation, omitting any traits like authentication needs, error handling, or rate limits.
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 wasted words. Perfectly concise for a simple read tool.
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 but lacks details on return value format, error conditions, or exact profile fields. With no output schema, more context would be helpful.
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 a good description for user_ids. The description adds no additional meaning beyond what the schema already provides, meeting baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (get) and resource (user profile information) with a bulk scope. However, it does not explicitly distinguish from sibling tools like slack_get_users, leaving some ambiguity.
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, no mention of prerequisites or constraints beyond the schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve basic profile information of all users in the workspace
| Name | Required | Description | Default |
|---|---|---|---|
| cursor | No | Pagination cursor for next page of results | |
| limit | No | Maximum number of users to return (default 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only says 'retrieve basic profile information.' It does not disclose pagination (though schema has cursor/limit), rate limits, or that it may return a large dataset. Schema provides some context, so minimum viable.
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 that efficiently conveys the tool's purpose. No unnecessary words or repetition. Front-loaded with the key action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and no description of return format. The description says 'basic profile information' but does not specify fields or structure. For a tool that returns potentially many users, this is insufficient for an agent to understand the response.
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 covers both parameters (cursor and limit) with descriptions. The description adds no additional meaning beyond what schema provides. Since schema description coverage is 100%, 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 action ('Retrieve'), the resource ('basic profile information of all users'), and the scope ('all users in the workspace'). The name 'get_users' distinguishes it from siblings like 'search_users' and 'get_user_profiles', implying a bulk retrieval.
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 the alternative 'slack_search_users' or 'slack_get_user_profiles'. There is no mention of prerequisites, performance considerations, or context that would help an agent decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List public channels in the workspace with pagination
| Name | Required | Description | Default |
|---|---|---|---|
| cursor | No | Pagination cursor for next page of results | |
| limit | No | Maximum number of channels to return (default 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that it lists public channels and supports pagination. However, it does not mention rate limits, required permissions, or whether it returns all public channels or only those the user is a member of. This adds some value but is not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the verb and resource. Every word is purposeful and there is no extraneous information, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with pagination, the description covers the core purpose and pagination mechanism. It does not describe the return format or additional behavior, but given the simplicity, it is nearly complete. A slight gap is the lack of mention that it lists only public channels.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both 'limit' and 'cursor' are already described in the schema parameters. The description adds no additional semantic detail beyond what the schema provides, so it meets the baseline but does not enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List public channels in the workspace with pagination', specifying the verb 'list', resource 'public channels', scope 'workspace', and mentions pagination. This distinguishes it from sibling tools like slack_post_message or slack_get_channel_history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives or when not to use it. It implies a read operation but lacks guidance on context, such as for obtaining a list of channels before posting or searching. Without explicit when/when-not, it is adequate but has gaps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Post a new message to a Slack channel
| Name | Required | Description | Default |
|---|---|---|---|
| channel_id | Yes | The ID of the channel to post to | |
| text | Yes | The message text to post |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavioral traits. It mentions 'Post' implying a write operation but omits details like authentication requirements, rate limits, or what happens if the channel ID is invalid. The description does not confirm whether the message is sent immediately or if there are formatting options.
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 that efficiently communicates the core action. It is front-loaded with the verb and resource, containing no unnecessary words or redundancy.
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 lack of annotations and output schema, the description should provide more context about what the tool returns (e.g., message timestamp) and potential failure modes. It does not mention that the bot must be a member of the channel or that the message text supports formatting. The description feels incomplete for a tool with behavioral complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers both parameters with descriptions (channel_id and text), achieving 100% coverage. The description adds no extra meaning beyond the schema, so baseline 3 is appropriate. No additional context like where to obtain the channel ID or how to format the text 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 tool's action ('Post a new message') and target resource ('a Slack channel'). It distinguishes from siblings like 'slack_reply_to_thread' (which posts to a thread) and 'slack_add_reaction' (adds a reaction), making the purpose 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 (e.g., 'slack_reply_to_thread' for threads, 'slack_get_channel_history' for reading messages). There is no mention of prerequisites, such as the bot needing to be a member of the channel.
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 | |
| text | Yes | The reply text | |
| 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?
With no annotations, the description bears full responsibility for behavioral disclosure. It only says 'reply' without clarifying permissions, rate limits, error behavior, or that the reply appears in the thread. Minimal insight.
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 fluff, but could include more context without increasing length. Efficient though.
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?
No output schema, no annotations, and 3 parameters. The description lacks context on return value, error scenarios, or how to obtain thread_ts, leaving 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 coverage is 100%, and the description adds no extra meaning beyond the schema. The schema already describes channel_id, text, and thread_ts with details. Baseline 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 states 'Reply to a specific message thread in Slack,' which clearly identifies the action (reply) and target (thread). It distinguishes from siblings like slack_post_message (new message) and slack_get_thread_replies (read-only).
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, prerequisites (e.g., needing channel_id and thread_ts), or when not to use it (e.g., if the thread doesn't exist).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for channels by partial name match. Use this when you need to find channels containing specific keywords in their names. Returns up to the specified limit of matching channels.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search channels by partial name match (case-insensitive). Searches across channel names. | |
| limit | No | Maximum number of channels to return (default 20) | |
| include_archived | No | Include archived channels in results (default false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states 'Returns up to the specified limit of matching channels,' which is minimal. It does not disclose behavioral aspects like rate limits, pagination, or whether the search is exact or partial beyond what the schema already says.
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, front-loaded with the main purpose, and contains no unnecessary words. It is appropriately sized.
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 explains the search behavior and return limit. For a simple search tool with no output schema, this is adequate. Could mention result format but not critical.
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 clear parameter descriptions. The tool description adds little beyond the schema, so a baseline score 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 tool searches for channels by partial name match, with a specific verb and resource. It distinguishes from sibling tools like slack_list_channels (lists all) and slack_search_messages (searches 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?
The description says 'Use this when you need to find channels containing specific keywords in their names,' providing clear context on when to use. However, it does not explicitly mention when not to use or contrast with alternative sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for messages with specific criteria/filters. Use this when: 1) You need to find messages from a specific user, 2) You need messages from a specific date range, 3) You need to search by keywords, 4) You want to filter by channel. This tool is optimized for targeted searches. For general channel browsing without filters, use slack_get_channel_history instead.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Basic search query text only. Use this tool when you need to: search by keywords, filter by user/date/channel, find specific messages with criteria. For general channel browsing without filters, use slack_get_channel_history instead. Do NOT include modifiers like "from:", "in:", etc. - use the dedicated fields instead. | |
| in_channel | No | Search within a specific channel. Must be a Slack channel ID (e.g., "C1234567"). Use slack_list_channels to find channel IDs first. | |
| from_user | No | Search for messages from a specific user. IMPORTANT: You cannot use display names or usernames directly. First use slack_get_users to find the user by name and get their user ID (e.g., "U1234567"), then use that ID here. | |
| before | No | Search for messages before this date (YYYY-MM-DD) | |
| after | No | Search for messages after this date (YYYY-MM-DD) | |
| on | No | Search for messages on this specific date (YYYY-MM-DD) | |
| during | No | Search for messages during a specific time period (e.g., "July", "2023", "last week") | |
| highlight | No | Enable highlighting of search results | |
| sort | No | Search result sort method (score or timestamp) | score |
| sort_dir | No | Sort direction (ascending or descending) | desc |
| count | No | Number of results per page (max 100) | |
| page | No | Page number of results (max 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the tool is 'optimized for targeted searches' and advises against using modifiers in the query, but does not disclose behavioral traits such as pagination behavior, result limits beyond parameters, error handling, or rate limits. This is adequate but leaves gaps.
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 four well-structured sentences: first states the purpose, then lists four use cases, then explains optimization, and finally states the alternative. No superfluous content; front-loaded with key 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?
The description covers purpose, usage guidelines, and differentiation, but lacks information about return values or output format (no output schema). It also does not mention required permissions or error conditions. For a tool with 12 parameters, the description is moderately complete but could be more comprehensive.
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 tool description adds little beyond what the schema descriptions already provide; it reiterates the high-level categories (keywords, user, date, channel) but does not offer additional parameter-specific insights that are not already in the schema field 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?
The description clearly states the tool searches for messages with specific criteria/filters, lists concrete use cases (by user, date, keywords, channel), and explicitly distinguishes it from sibling tool slack_get_channel_history for general browsing without filters.
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 explicit conditions for using the tool (four numbered scenarios) and directly advises when not to use it, directing to slack_get_channel_history instead. The schema descriptions reinforce this guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for users by partial name match across username, display name, and real name. Use this when you need to find users containing specific keywords in their names. Returns up to the specified limit of matching users.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search users by name, display name, or real name (partial match, case-insensitive) | |
| limit | No | Maximum number of users to return (default 20) | |
| include_bots | No | Include bot users in results (default false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses partial matching and the limit behavior, but does not mention that bots are excluded by default (include_bots defaults to false) or return format. Adequate but could be more detailed.
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 with no unnecessary words. Front-loaded with the action and immediate context. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 3 parameters, full schema coverage, and no output schema, the description explains the search behavior and limit. It does not mention return format or error handling, but is fairly complete for a simple search 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 is appropriate. The description reinforces what the query parameter does but adds no additional details about limit or include_bots beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches for users by partial name match across username, display name, and real name. This distinguishes it from sibling tools like slack_get_users (which likely returns all users) and slack_search_channels (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?
It explicitly says 'Use this when you need to find users containing specific keywords in their names,' providing clear context. It does not explicitly state when not to use alternatives, but the purpose is sufficiently differentiated.
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_reactionslack_get_channel_historyslack_get_thread_repliesslack_get_user_profilesslack_get_usersslack_list_channelsslack_post_messageslack_reply_to_threadslack_search_channelsslack_search_messagesslack_search_usersScored across 11 tools
Each tool has a clearly distinct purpose. Potential overlaps (e.g., get_channel_history vs search_messages, get_users vs get_user_profiles) are explicitly disambiguated in descriptions, making it easy for an agent to select the right tool.
All tools follow a consistent 'slack_verb_noun' pattern (e.g., slack_add_reaction, slack_search_messages). The naming is predictable and uniform across the entire set.
With 11 tools, the server covers core Slack operations (messaging, search, user/channel info, reactions) without being overly numerous. Each tool serves a necessary function, and the count feels well-scoped.
The tool set covers essential read/write operations for messages, threads, reactions, and user/channel discovery. Minor gaps exist, such as message editing/deletion and channel creation, but these are not critical for most Slack automation use cases.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
A Model Context Protocol server for Wix AI tools
MCP server for Sendbird — chat users, channels, members, and messages from your AI client.