Loading ToolBench
The Slack Connector MCP has 4 tools with varying quality. Two tools (send_slack_direct_message, send_slack_channel_message) have minimal descriptions (under 20 chars) and lack parameter descriptions beyond bare field names. The list_slack_users tool includes a puzzling 'random_string' parameter with no clear purpose and no description justifying its existence. Input schemas are partially visible but parameter descriptions are sparse or missing. Output schemas are completely undocumented, callers cannot determine what list_slack_channels or list_slack_users actually return (structure, fields, pagination). Error handling is minimal; tool_response() returns a generic 'error' string with no recovery guidance. No input validation documented. No tool annotations (readOnlyHint/destructiveHint). Composition is reasonable (tools are single-purpose), but the interface lacks the LLM-optimized descriptions and documented schemas required for production agent use.
List available Slack channels.
List all Slack users in the workspace.
Send message to Slack channel.
Send DM to Slack user.
Tool descriptions are critically brief (under 20 chars) and lack actionable context. 'Send DM to Slack user' and 'Send message to Slack channel' do not explain when to use each tool, what happens on success, or whether the operation is idempotent/retryable. LLMs cannot determine selection criteria with such minimal guidance.
No parameter descriptions for send_slack_direct_message and send_slack_channel_message beyond field names. A parameter called 'message_text' is ambiguous, does it support markdown, mentions, threads? Does it have a length limit? LLMs cannot infer constraints from names alone.
list_slack_users includes a 'random_string' parameter with empty default and no description explaining its purpose. This appears to be a testing artifact or leftover. Undefined parameters force LLMs to guess whether to include it, wasting tokens and inviting errors.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 38 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 33 | - | v1 |
Output schemas are completely undocumented. list_slack_channels and list_slack_users return data via tool_response(), but the source code provides no specification of the return structure. Does list_slack_channels return a list of channel objects with 'id', 'name', 'topic'? Is pagination included? Without documented output schemas, LLMs cannot plan downstream tool calls or extract the correct data.
Error handling returns a generic 'error' string with no recovery guidance. If send_slack_direct_message fails because the user_id is invalid, the response should be 'User not found (U12345). Try list_slack_users() to find valid user IDs.' instead of a bare error message. This prevents the LLM from self-correcting.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) present. send_slack_direct_message and send_slack_channel_message are clearly destructive (they mutate state), but the tool definition does not declare this. Agents need explicit hints to plan safely and decide retry/compensation strategies.
list_slack_users parameters accept arbitrary strings for 'user_id' and 'channel_id' in send tools, but no validation or enum constraints are visible. Slack requires properly formatted IDs (e.g., 'U' prefix for users, 'C' prefix for channels). Invalid IDs will fail silently or with unhelpful API errors.
No rate limiting, timeout configuration, or retryability guidance documented. Slack API has rate limits; tools should declare expected latency, timeout behavior, and whether failures are transient or permanent. An agent in a retry loop could exhaust rate limits without backoff.