Loading ToolBench
MCP server for searching and exploring Slack messages, files, and user profiles with advanced filtering capabilities
Slack Explorer MCP demonstrates solid definition quality with well-structured tool schemas and mostly complete parameter documentation. All 6 tools have explicit descriptions and properly typed input schemas using the mark3labs/mcp-go framework. Tool annotations (readOnlyHint, destructiveHint, openWorldHint) are correctly applied to all tools. However, there are gaps in output schema documentation, some parameter descriptions lack actionable constraints, and error handling guidance is not evident in the definitions. The server exhibits production-grade naming conventions (verb_noun pattern) and good parameter organization. The main limitations are missing output schema documentation and lack of error recovery guidance in tool descriptions.
Get HTML content of Slack canvases by their IDs.
Get all replies in a message thread Note: To construct Slack permalinks from the response: - Use workspace_url from search_messages tool response - Thread reply URL: {workspace_url}/archives/{channel_id}/p{ts without dot}?thread_ts={thread_ts}&channel={channel_id}&message_ts={ts} Where channel_id and thread_ts are the values provided as input parameters
Get multiple users profile information in bulk
Search for files with specific criteria/filters. Use this when: 1) You need to find files (canvases, PDFs, etc.) by keywords, 2) You need files from a specific user, 3) You need to filter by file type, 4) You want to filter by channel or date range.
Search for messages with specific criteria/filters. Use this when: 1) You need to find messages from a specific user, 2) You need messages from a specific date range, 3) You need to search by keywords, 4) You want to filter by channel. This tool is optimized for targeted searches. Note: Response includes workspace_url, channel.id, and ts (timestamp) which can be used to construct Slack permalinks: - Regular message (no thread_ts field): {workspace_url}/archives/{channel.id}/p{ts without dot} - Thread reply (has thread_ts field): Same URL with ?thread_ts={thread_ts}&channel={channel.id}&message_ts={ts}
Output schemas not documented. While input schemas are complete and typed, the source code does not show return type documentation for any tool. LLMs cannot plan downstream tool calls or know what fields to expect in responses.
Missing parameter constraints on numeric ranges. The search_messages tool accepts 'count' (1-100, default: 20) and 'page' (1-100, default: 1) but these constraints are only stated in descriptions, not enforced as schema minima/maxima. get_thread_replies 'limit' (1-1000) similarly lacks formal bounds. LLMs cannot read constraint descriptions reliably.
Error handling guidance absent from tool descriptions. Descriptions do not mention what errors are possible, when to retry, or which errors are user-fixable. For example, search_messages might fail if 'in_channel' does not exist, but there is no guidance on recovery.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 62 | <=2025-11-25 | v2 |
| 2026-03-09 | C | 62 | - | v1 |
Search users by display name
Generic tool description for get_user_profiles. The description 'Get multiple users profile information in bulk' is minimal (54 chars, below the 100-char baseline). It lacks context on WHEN to use this tool vs alternatives, what fields are returned, or usage prerequisites.
get_canvas_content description is too generic (60 chars). 'Get HTML content of Slack canvases by their IDs.' lacks guidance on when to call this vs other tools, what the output format is (HTML structure, encoding), or prerequisites. No mention of file size limits or supported canvas types.
Enum constraints not formalized in schema. search_messages 'sort' param accepts 'score' or 'timestamp' (stated in description only), and 'sort_dir' accepts 'asc' or 'desc'. These should be declared as enum fields in the JSON Schema to prevent LLMs from hallucinating invalid values like 'relevance' or 'ascending'.
Missing pagination documentation in output. search_messages and search_files accept 'page' and 'count' parameters but the tool descriptions do not specify whether the response includes a 'total_count', 'has_next', or 'next_cursor' field. This forces LLMs to guess whether pagination is complete.