Model Context Protocol (MCP) server for Slack Workspaces. This integration supports both Stdio and SSE transports, proxy settings and does not require any permissions or bots being created or approved by Workspace admins
The Slack MCP server presents moderate quality with 15 well-defined tools across read, write, and management operations. All tools have descriptions and documented schemas with proper type definitions. However, several issues prevent a higher score: (1) parameter descriptions lack depth and constraint guidance, particularly around format specifications (e.g., timestamp format 1234567890.123456 mentioned in descriptions but not enforced via schema patterns); (2) output schemas are not documented, responses are not shown in the tool definitions, making it impossible for LLMs to plan downstream operations; (3) several parameter descriptions contain example values (e.g., '#general', '@username_dm', 'thumbsup') which risks LLMs reusing them literally; (4) error handling guidance is absent, tools lack recovery hints; (5) composition issues exist where some tools could be consolidated (e.g., conversations_history and conversations_replies are nearly identical patterns). The naming convention is verb-prefixed (conversations_, reactions_, channels_, usergroups_, saved_, attachment_) which is clear and follows baselines well.
Download an attachment's content by file ID. Returns file metadata and content (text files as-is, binary files as base64). Maximum file size is 5MB.
Get a list of all channels in the Slack workspace with optional filtering by channel type and sorting options.
Add a message to a public channel, private channel, or direct message (DM, or IM) conversation by channel_id and thread_ts.
Get messages from the channel (or DM) by channel_id, the last row/column in the response is used as 'cursor' parameter for pagination if not empty
Get a thread of messages posted to a conversation by channelID and thread_ts, the last row/column in the response is used as 'cursor' parameter for pagination if not empty
Output schemas not documented. Tool responses lack documented return field structures. LLMs cannot plan downstream tool chaining or extract required IDs for follow-up calls. For example, conversations_history and conversations_replies do not document what fields are returned, making it impossible for agents to know if they can access message IDs, timestamps, or user references for subsequent operations.
Parameter descriptions contain example values that risk literal reuse. The descriptions for conversations_history, conversations_replies, reactions_add, and channels_list include examples like '#general', '@username_dm', 'thumbsup', 'heart', 'rocket' which LLMs may reuse as literal values rather than as illustrative samples. Example values should be replaced with formal enum constraints or pattern specifications.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 64 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 28 | - | v1 |
Search for messages in Slack conversations using a search query. Returns matching messages with pagination support.
Add an emoji reaction to a message in a public channel, private channel, or direct message (DM, or IM) conversation.
Remove an emoji reaction from a message in a public channel, private channel, or direct message (DM, or IM) conversation.
Mark a saved item as complete.
Get a list of saved items in the Slack workspace.
Create a new user group in the Slack workspace.
List all user groups in the Slack workspace.
Get user groups that the authenticated user is a member of.
Update an existing user group in the Slack workspace.
Update the list of users in a user group.
Timestamp and format constraints not enforced in schemas. The 'timestamp' parameter in reactions_add and reactions_remove is described as requiring format '1234567890.123456' but no JSON Schema pattern field enforces this. Similarly, 'cursor' parameters lack format specifications. LLMs cannot validate these constraints without explicit schema patterns or length/regex definitions.
No error recovery guidance. Error responses lack actionable recovery hints. For example, if reactions_add fails because the message timestamp is invalid or the emoji is not recognized, there is no guidance on what the LLM should do next (retry, ask user, call a lookup tool). Error descriptions should include categories (retryable, user-fixable, fatal) and next-step suggestions.
Generic descriptions on utility tools. usergroups_list, usergroups_me, and saved_list have short or uninformative descriptions (55 - 60 chars). They do not explain what structure is returned, when to call them before other operations, or what the typical use case is.
Pagination cursors lack documentation. conversations_history and conversations_replies both accept 'cursor' and 'limit' parameters, but the interaction between them is underspecified. The descriptions state 'Must be empty when cursor is provided' for the limit param, but do not explain cursor semantics (is it opaque? Is it a message ID? How do you know when to stop?). Pagination guidance should explain cursor semantics and termination conditions.
Mutually exclusive parameter dependencies not documented. conversations_add_message has optional 'thread_ts' and 'text' parameters, but does not clarify whether text is required or whether a message can be added with empty text (e.g., for attachments or blocks). Similarly, channels_list has optional 'channel_types' and 'sort' parameters without documenting defaults or valid combinations.
No dry-run or confirmation pattern for destructive operations. Tools like saved_complete and usergroups_users_update (which updates group membership) are write operations but lack a dry-run, confirmation, or idempotency hint. Agents should be able to preview the impact before committing destructive changes.