Loading ToolBench
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 defines 22 tools with reasonable naming conventions and mostly adequate descriptions. Tool names follow the verb_noun pattern (conversations_history, reactions_add, channels_list). Descriptions exist for all tools and range 40 - 250 characters, meeting the 10-1024 character baseline. However, significant gaps exist: (1) Input schemas are present but parameter type definitions are inconsistent, many parameters like 'limit', 'cursor', 'sort' lack explicit type declarations in the schema structure visible in the source. (2) Output schemas are completely undocumented, there is no specification of what fields tools return, which breaks downstream tool chaining and forces LLMs to infer structure. (3) Error handling guidance is absent, no tool documents recovery steps, retryability, or what to do on failure. (4) Parameter descriptions, while present, often lack constraint details (format, range, valid values). (5) Some parameter naming inconsistencies exist: channel_id is formatted differently across tools. (6) A critical security concern: the server handles Slack API tokens but there is no evidence of explicit secret injection guidance in the tool definitions themselves, though the server-side likely manages them. On strengths: naming is consistently verb-forward, descriptions are substantive (not placeholder text), and the server covers a coherent domain (Slack interactions). The 22 tools show domain completeness but definition depth lags production standards.
Get data from an attachment by URL. Supports files, images, PDFs, and other content types.
List all channels in the workspace with optional filtering and search.
List all channels the authenticated user is a member of.
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
Join a conversation by channel ID.
Output schemas completely undocumented. No specification of what fields any tool returns (e.g., does conversations_history return 'messages', 'channel_info', 'next_cursor'?). This breaks downstream tool chaining and forces LLMs to infer structure from trial and error.
Parameter type definitions inconsistent or missing. Parameters like 'limit' (conversations_history), 'cursor', 'sort' (channels_list) are declared with type 'string' but semantics vary. 'limit' accepts both time ranges ('1d') and numeric counts ('50'), the parameter description documents this, but the schema type is 'string' with no formal constraint (enum, pattern, or oneOf). LLMs will struggle to pick valid values.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 62 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 49 | - | v1 |
Leave a conversation by channel ID.
Mark a conversation as read by setting the read cursor to a specific timestamp.
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
Search for messages in a conversation by keyword using the Slack search API.
Get conversation unreads information.
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.
Clear saved items marked as completed.
List all saved items for the authenticated user.
Update saved items (save or unsave messages, files, etc.).
Create a new user group in the workspace.
List all user groups in the workspace.
List all user groups that the authenticated user is a member of.
Update an existing user group.
Update the list of users in a user group.
Search for users in the workspace by name or other criteria.
No error handling guidance. Tools do not document what happens on failure, whether errors are retryable, or what the LLM should do next. Example: reactions_add does not specify: 'If the message is not found, will this fail silently or return a 404? If it does fail, should I retry or ask the user?' This violates the recovery-guide pattern.
Destructive operations lack confirmation or dry-run support. conversations_leave and saved_clear_completed are marked DESTRUCTIVE but have no mention of confirmation, dry-run, or rollback. Agents can accidentally delete saved items or leave critical channels without safeguards.
Pagination support unclear. conversations_history and conversations_replies accept 'cursor' and 'limit' parameters, but there is no documentation of what the response returns as 'next_cursor'. Will it be a field called 'next_cursor', 'cursor', or something else? This breaks pagination chaining.
Natural identifier support inconsistent. conversations_add_message accepts channel_id 'in format Cxxxxxxxxxx or its name starting with # or @'. This is good (supports both IDs and names), but other tools like channels_list do not explicitly state whether they accept channel names or only IDs. Mixed support across tools increases confusion.
Parameter naming inconsistencies. 'timestamp' is used in reactions_add/reactions_remove, but 'ts' is used elsewhere (conversations_replies thread_ts). Using both naming conventions for the same concept (message timestamp) increases cognitive load and error risk for LLMs.
Parameter constraint documentation lacks formal structure. conversations_history 'limit' parameter description says 'e.g. 1d, 1w, 30d, 90d which is a default limit for free tier history) or number of messages (e.g. 50)'. These examples should be enums or regex patterns in the schema, not prose. LLMs will hallucinate formats like '2w' or '100msg' that may not be valid.