Loading ToolBench
This Slack MCP server implements 9 tools with generally clear naming and adequate descriptions, but has significant gaps in parameter documentation, output schema clarity, and error handling guidance. All tools are explicitly registered with input schemas visible in index.ts, avoiding the inference penalty. However, parameter descriptions often lack detail about constraints, formats, and dependencies. Output schemas are not documented, the server returns raw API responses without explaining structure to LLMs. Error handling is minimal; failures will not guide agents toward recovery.
Lookup a user by their email address
Add a reaction emoji to a message
Get recent messages from a channel
Get all replies in a message thread
Get detailed profile information for a specific user
Get a list of all users in the workspace with their basic profile information
Output schemas not documented. LLMs cannot infer what fields each tool returns, forcing them to guess about structure. E.g., slack_list_channels returns paginated results, but the response schema (channels array structure, pagination cursor format, total count) is never documented.
Parameter descriptions lack constraint details. E.g., 'limit' in slack_list_channels says 'max 200' but doesn't state minimum (1?) or whether default 100 is inclusive. timestamp parameters in slack_reply_to_thread and slack_add_reaction have verbose format guidance but lack examples of what valid/invalid timestamps look like, forcing LLMs to infer.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 55 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 19 | - | v1 |
List public channels in the workspace with pagination
Post a new message to a Slack channel
Reply to a specific message thread in Slack
Error handling is absent. No tool documents what happens on failure (e.g., channel not found, invalid timestamp, permission denied, rate limit). Agents will receive raw API errors with no recovery guidance. slack_post_message, slack_reply_to_thread, slack_add_reaction offer no guidance if the operation fails.
No write-operation confirmation or dry-run. slack_post_message and slack_reply_to_thread are destructive (posts messages to Slack permanently). Agents that hallucinate or misunderstand context could post incorrect messages. No confirmation-request pattern or dry-run preview available.
Parameter dependency undocumented. slack_reply_to_thread requires both channel_id and thread_ts in exact format ('1234567890.123456'). The description explains the format conversion rule but does not warn that if the format is wrong, the tool silently fails. No guidance on how to obtain a valid thread_ts.
Pagination behavior unclear. slack_list_channels and slack_get_users accept cursor parameters, but the tool description does not explain when to use cursor, what format it has, how to detect end-of-results, or how to handle partial pages. This forces LLMs to infer pagination logic.
No documentation of which tools require SLACK_TEAM_ID environment variable. The code shows getChannels() requires process.env.SLACK_TEAM_ID, but the tool description does not warn agents that calls may fail silently if the environment is misconfigured.