Loading ToolBench
A powerful MCP server for Slack workspaces - supports DMs, Group DMs, smart history fetch, and works via OAuth or browser tokens
The server provides 13 tools with basic structure but significant quality gaps. Naming is verb-forward and mostly clear (get_*, create_*, add_*, archive_*, invite_*), following actionable conventions. However, descriptions are inconsistent in depth, most tools have 1 - 3 sentence descriptions that meet the bare minimum but lack actionable detail about when to use each tool vs. alternatives. Parameter schemas are present for all tools but underdeveloped: most parameters use generic string types without enum constraints, format validation, or dependency documentation. For example, the 'limit' parameter across get_channels, get_messages, and get_thread_messages accepts ambiguous string expressions ('1d', '1w', '30d', or a number) without formal validation. The 'channel' parameter (used in get_channel_info, get_messages, archive_channel, invite_users_to_channel) accepts both name and ID but does not document this flexibility in the descriptions. Output schemas are inferred from code (convert_slack_message, messages_to_csv, etc.) but not formally declared in tool definitions. Error handling is minimal, no recovery guidance or error categorization visible. Security baseline is reasonable (no secrets in parameters, using environment variables for config), but no explicit permission gates or audit logging in the visible code. Tool composition is reasonable (single-responsibility tools), but some tools could be more granular (e.g., open_dm and get_dm are semantically similar and could be consolidated with clearer naming). The server lacks documentation of idempotency guarantees, rate limiting, and pagination strategies.
Post a message to a channel
Archive a channel
Create a new channel
Get detailed information about a specific channel
Get a list of channels
Get a direct message channel with a user
Get a group direct message channel
Get messages from a channel
Parameter type ambiguity: 'limit' parameter accepts string expressions ('1d', '1w', '30d', number) without formal schema constraints. No enum, pattern, or example in the input schema, only description text. LLMs cannot parse string constraints from descriptions alone.
Ambiguous parameter naming: 'channel' parameter in get_channel_info, get_messages, archive_channel accepts both name and ID, but this is documented only in description text. Best practice is separate parameters (channel_id, channel_name) to avoid type confusion.
Output schemas not formally documented. Tool descriptions reference CSV conversion and message objects, but no explicit schema definition visible in tool registration. LLMs must infer output structure from descriptions, increasing misuse risk.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 40 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 37 | - | v1 |
Get messages from a thread
Get a list of users in the workspace
Invite users to a channel
Open a direct message with a user
Search for messages across the workspace
No error recovery guidance. Tool descriptions lack actionable error messages, recovery steps, or guidance on when to retry vs. ask the user. E.g., 'Archive a channel' does not explain what happens if the channel is not found or if permission is denied.
Inconsistent parameter descriptions. Some tools document flexibility ('Channel name or ID'), but descriptions are terse and lack examples of valid input formats. Descriptions average ~50 chars; baseline for A-grade tools is 194 chars.
Similar tool names risk LLM confusion: open_dm vs get_dm, get_channel_info vs get_channels. Naming does not clearly disambiguate when to call each. Consider: 'open_dm' suggests side effect; 'get_dm' is read-only. Descriptions do not clarify the distinction.
No pagination metadata in visible tool definitions. get_channels, get_messages accept 'limit' but do not document offset, cursor, or total count. Large result sets may exceed context limits without pagination guidance.
Tool annotations missing. No readOnlyHint, destructiveHint, or idempotentHint visible in schema. LLMs cannot distinguish safe reads from destructive writes without heuristics, increasing retry risk and context confusion.
Minimal idempotency documentation. No visible guarantees that repeated calls with the same parameters produce the same result. create_channel, add_message, and invite_users_to_channel may have side effects; agents retrying on ambiguous failures risk duplicate records or messages.