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 10 tools with explicit schemas and descriptions. All tools have parameter schemas with types and descriptions, which is strong. However, there are significant quality gaps: (1) Descriptions are inconsistent in quality, some are 30-50 chars (too terse per the 10-1024 char baseline), while others exceed 200 chars and embed examples. (2) Parameter descriptions frequently include example values and raw format strings ('e.g., Cxxxxxxxxxx') which LLMs may reuse literally. (3) Output schemas are NOT documented in the provided code, only input schemas are visible. (4) Many parameters accept free-form strings where enums would be safer (e.g., 'channel_types' in channels_list is a string, not an enum; 'content_type' in conversations_add_message has a default but no enum constraint). (5) Error handling guidance is absent, no recovery paths or error categorization. (6) No confirmation patterns for destructive operations (conversations_rename, conversations_invite, conversations_set_topic). (7) Tool naming is good (verb_noun pattern), but descriptions are LLM-unfriendly with embedded examples.
Get list of channels
Add a message to a public channel, private channel, or direct message (DM, or IM) conversation by channel_id and thread_ts.
Create a new public channel
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
Invite users to a public channel
Rename a public channel
Output schemas not documented. The provided code shows input schemas but no declared output structure for any tool. LLMs cannot reason about what fields to expect or plan downstream tool calls.
Descriptions embed example values (e.g., 'Cxxxxxxxxxx', '1234567890.123456', 'U1234567890'). LLMs often reuse example IDs literally in real calls, causing failures. Replace with format constraints and validation rules.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 63 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 44 | - | v1 |
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 messages in a public channel, private channel, or direct message (DM, or IM) conversation using filters. All filters are optional, if not provided then search_query is required.
Set the topic of a public channel
Resolve a user by query (username, display name, real name, or email). Returns user ID, username, real name, display name, email, and match type.
Parameter 'channel_types' (channels_list) is a free-form string that accepts comma-separated values. Should be an enum or array of enums: ['public_channel', 'private_channel', 'im', 'mpim']. Current approach invites malformed input.
Parameter 'content_type' (conversations_add_message) has a default but no enum constraint. Should declare allowed values as an enum: ['text/markdown', 'text/plain'] to prevent LLM hallucination of unsupported types.
No error handling or recovery guidance. Tools lack descriptions of failure modes, retryable vs. non-retryable errors, or suggested next steps (e.g., 'If channel not found, try channels_list first'). Per pattern:recovery-guide, errors must be actionable.
Destructive operations (conversations_rename, conversations_invite, conversations_set_topic) lack confirmation patterns or dry-run support. Agents can irreversibly modify channels without user approval.
Many descriptions are too terse or verbose. 'Get messages from the channel...' (conversations_history) is 50 chars and lacks guidance on WHEN to use this vs. conversations_replies.
Parameter 'limit' in conversations_history and conversations_replies accepts a string with custom format ('1d', '30d', or '50'). This is non-standard and error-prone. Separate into two parameters: 'time_limit' (enum or range) and 'message_count' (integer 1-200), or provide strict validation with examples of valid formats.
No documented pagination behavior for tools returning lists (channels_list, conversations_search_messages). Missing: total count, has_more flag, and guidance on cursor handling. Per pattern:paginated-result, large results must be chunked.
Tool names 'conversations_*' are Slack API names, not action-focused. 'get_channel_messages', 'send_channel_message', 'list_channels' would be clearer for LLM selection. Current names are consistent internally but not optimized for agent discoverability.