Loading ToolBench
An MCP server that provides read-only access to Slack workspace data including channels, messages, users, and threads
This Slack MCP server demonstrates solid definition quality with consistent naming patterns, comprehensive parameter schemas, and well-structured pagination support across all 7 tools. All tools follow the verb_noun convention (list_*, get_*). Descriptions are present and contextual, averaging ~150-180 chars, which falls within the production baseline (p10=34, p90=392). Input schemas are complete with proper JSON types and constraints (min/max for limits, enum-style patterns via descriptions). However, output schemas are NOT documented in the visible code, we cannot see what fields are returned or their types. Error handling is implicit (relies on slack-sdk error propagation) with no explicit recovery guidance. Tool names could be slightly more disambiguated (get_channel_info vs get_messages both operate on channels). No destructive/irreversible operations present, so confirmation patterns are not applicable. Security is adequate (Slack token injected server-side, no secrets in params). Overall, this is a read-only, well-organized tool suite that would benefit from documented output schemas and explicit error handling.
Get detailed information about a specific channel. The channel can be specified either by its ID or by its name (without the # prefix).
Get messages from a channel with pagination support. This endpoint supports pagination through the cursor parameter. If the result set is large, the response will include a next_cursor which should be passed in subsequent requests to get the next page.
Get all messages in a thread with pagination support. Returns all messages belonging to the specified thread. This endpoint supports pagination through the cursor parameter. If the result set is large, the response will include a next_cursor which should be passed in subsequent requests to get the next page.
Get detailed information about a specific user.
List channels in the workspace with pagination support. This endpoint supports pagination through the cursor parameter. If the result set is large, the response will include a next_cursor which should be passed in subsequent requests to get the next page.
Output schemas not documented. Tools return results from slack-sdk but no explicit documentation of response structure, field types, or what an LLM should expect. This forces LLMs to infer structure from returned data, risking field extraction errors and suboptimal downstream chaining.
No explicit error handling or recovery guidance. slack-sdk exceptions are not caught and re-mapped to actionable error messages. LLMs will receive raw API errors (e.g., 'not_in_channel', 'channel_not_found') without guidance on what to try next.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 65 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 51 | - | v1 |
List threads in a channel with pagination support. Returns only the first message of each thread (thread parent message) in the specified channel. This endpoint supports pagination through the cursor parameter. If the result set is large, the response will include a next_cursor which should be passed in subsequent requests to get the next page.
List users in the workspace with pagination support. This endpoint supports pagination through the cursor parameter. If the result set is large, the response will include a next_cursor which should be passed in subsequent requests to get the next page.
Parameter descriptions lack format/constraint detail. 'channel_name' is described as 'Name of the channel' but does not state whether to include or exclude the '#' prefix, valid character set, or max length. Similar for thread_ts, is it a Unix timestamp, epoch ms, or ISO string?
get_channel_info accepts both channel_id and channel_name but does not document which is preferred or what happens if both are provided. This creates ambiguity for LLMs.
No chaining field documentation. Tools that return channels or threads do not explicitly document whether returned channel_id or thread_ts values can be passed directly to downstream tools (e.g., can get_messages accept a channel_id returned from list_channels, or only channel_name?). This blocks efficient tool composition.