Loading ToolBench
Slack MCP Server with OAuth authentication. Provides tools for interacting with Slack conversations, users, and channels.
This server demonstrates solid tool design with strong naming conventions, comprehensive parameter descriptions, and good schema documentation. All 7 tools follow verb-noun patterns (slack_get_*, slack_send_*, slack_reply_*). Descriptions are detailed and contextual. Parameters consistently include types, descriptions, and defaults. The compact response optimization shows thoughtful API design. However, there are gaps in error handling guidance, missing output schema documentation, and some parameters could use stricter constraints (enums instead of free-form strings). The write tools lack confirmation/dry-run patterns for safety. Most tools are well-designed for agent composition, with clear ID/name resolution strategies.
Retrieve messages from a Slack channel with pagination support. Accepts channel IDs or #names.
List channels, search channels by name, or get detailed info for a specific channel. Supports filtering by type (public, private, DM, group DM). Pass `query` to search by a name fragment (case-insensitive substring match, e.g. 'eng' matches '#engineering' and '#eng-infra') instead of listing or fetching by exact ID.
Get replies from a Slack thread. Accepts channel IDs or #names.
List workspace users or get a specific user's profile by ID.
Reply to a thread in a Slack channel. Only available when X-Writable-Channels header is configured. Target channel must be in the allowlist. Accepts channel names or IDs.
Write tools (slack_send_message, slack_reply_in_thread) lack confirmation/dry-run patterns or explicit idempotency guarantees. Agents may send duplicate messages on retry without knowing they already executed.
Output schemas are not documented in tool definitions. LLMs cannot plan downstream tool calls or know what fields to extract. The compact response helpers in slack_tools.py suggest responses are rich, but this is not exposed in tool metadata.
Error handling is not described in tool documentation. No guidance on what errors LLMs should expect, how to recover (retry vs. user intervention), or actionable next steps. Error responses likely come from Slack SDK without agent-friendly wrapping.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 69 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Search for messages across all Slack conversations with advanced filters. Supports date ranges (YYYY-MM-DD or relative like '7d', '1m'), user filters, and channel filters.
Send a message to a Slack channel. Only available when X-Writable-Channels header is configured. Target channel must be in the allowlist. Accepts channel names or IDs.
slack_search_messages accepts sort_order ('asc'|'desc') as a free-form string instead of an enum. LLMs may hallucinate other values like 'ascending' or 'reverse'. Same for sort_by ('timestamp'|'relevance').
slack_get_channels types parameter accepts a comma-separated filter string ('public_channel,private_channel', 'im,mpim') without enum constraints. This invites hallucinated values and makes validation opaque.
Write tools (slack_send_message, slack_reply_in_thread) do not document their output/return value. What fields do they return? Just success/failure? A message_ts for follow-up chaining? Unknown.
Pagination parameters (cursor, limit) are present but behavior is not fully documented. When is next_cursor provided vs. null? What does it contain? How should LLMs know pagination is exhausted?
slack_send_message and slack_reply_in_thread descriptions mention X-Writable-Channels header configuration but do not explain what happens if a channel is NOT in the allowlist. Error message? Silent failure? Unclear recovery path.