Loading ToolBench
Slack MCP Server for Model Context Protocol APIs
This server has 19 tools with consistent naming (verb_noun convention), readable descriptions (100-200 chars typical), and declared input schemas. However, several critical gaps reduce the score: (1) descriptions lack WHEN/WHY guidance and actionable error recovery hints; (2) many parameters accept free-form strings instead of enums (e.g., sort direction, channel types); (3) output schemas are undocumented, LLMs cannot plan downstream calls; (4) error handling is absent from descriptions; (5) parameter relationships and dependencies are undocumented (e.g., blocks vs text in send_message); (6) no support for pagination in list tools despite API limits; (7) destructive tools lack confirmation or dry-run patterns. Naming is strong but descriptions and schemas need significant work for production use.
Add a reaction emoji to a Slack message.
Archive a Slack channel.
Create a new Slack channel.
Delete a message from a Slack channel.
Get message history for a Slack channel.
Get detailed information about a specific Slack channel.
Get information about the Slack workspace/team.
Output schemas completely undocumented. LLMs cannot plan follow-up calls because they don't know what fields get_channel_info, list_users, search_messages, or other tools return. This forces agents to either guess or make extra discovery calls.
Free-form string parameters lack enum constraints. 'types' in list_channels accepts 'public_channel, private_channel, mpim, im' but is not declared as an enum, LLM may pass invalid values. 'sort' and 'sort_dir' in search_messages similarly lack enum constraints.
Destructive operations (delete_message, archive_channel) lack dry-run, confirmation, or compensation patterns. Agents can permanently delete messages or archive channels with no safeguard. Description does not warn about irreversibility.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 52 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 22 | - | v1 |
Get detailed information about a specific Slack user.
Invite users to a Slack channel.
List all channels in the Slack workspace.
List all users in the Slack workspace.
Remove a reaction emoji from a Slack message.
Search for messages across the Slack workspace.
Send a message to a Slack channel.
Set the purpose for a Slack channel.
Set the topic for a Slack channel.
Unarchive a Slack channel.
Update an existing message in a Slack channel.
Upload a file to one or more Slack channels.
Pagination not implemented despite 1-1000 limits in list_channels, list_users, get_channel_history, search_messages. Large result sets will bloat LLM context. No documented limit enforcement or next_cursor/offset support in descriptions.
Descriptions lack WHEN/WHY guidance. 'Send a message to a Slack channel' does not explain when to use send_message vs update_message vs add_reaction, or what happens if the channel is archived, or permission requirements.
No error handling guidance in tool descriptions. LLMs don't know if a 'channel not found' error is retryable, user-fixable, or fatal. Descriptions should say 'Call list_channels() first to verify channel exists' or similar recovery paths.
Parameter relationships undocumented. send_message accepts both 'text' and 'blocks', are they mutually exclusive? Optional? What happens if both are provided? Slack API behavior not explained to LLM.
Ambiguous parameter naming for channels. Tools accept both 'channel_id' and 'channel name' per description ('The ID or name'), but parameter is singular 'channel'. This forces LLM guessing, is it an ID or name? Should be split into channel_id and channel_name or described with explicit format rules.
Timestamp format inconsistent or undocumented. 'oldest', 'latest', 'thread_ts', 'ts' parameters lack format specifications, are they Unix seconds, milliseconds, ISO 8601 strings? LLM will guess wrong.
No permission scopes documented. Tools should declare required scopes (e.g., 'chat:write', 'channels:read') so agents understand least-privilege requirements and can report failures clearly.