Loading ToolBench
MCP server for Slack integration with OAuth authentication, providing tools for messaging, channel management, user management, file operations, and workspace administration
This Slack MCP server has moderate definition quality with significant gaps in error handling, parameter documentation, and output schema clarity. The 7 tools are registered via fastmcp @mcp.tool decorators with explicit names and descriptions (10-194 chars), meeting basic naming and description standards. However, only 1 of 7 tools (send_slack_message) has comprehensive parameter schemas with type definitions and descriptions for all parameters. Most tools lack documented output schemas, critical for LLM composition. Error handling is present but inconsistent, only send_slack_message and update_slack_message include error context ('Either text or blocks must be provided'); others have no recovery guidance. Security is partially addressed (OAuth state checking), but secrets and tokens appear to flow through context objects without explicit validation. The tool signatures follow verb_noun convention, improving discoverability.
Check if the current user has completed OAuth
Delete a Slack message
Get the OAuth URL for Slack authorization
List all Slack channels with optional filtering and pagination
Schedule a message to be sent later
Send a message to a Slack channel with optional rich formatting
Update an existing Slack message
Missing output schemas for 5 of 7 tools. get_oauth_url, check_oauth_status, delete_slack_message have no documented return structure, LLMs cannot plan downstream calls or extract needed IDs. Only send_slack_message and update_slack_message explicitly document their response payloads (channel, ts, success, error).
No input schema visible for get_oauth_url and check_oauth_status. Both are defined with empty parameter lists ({}) but lack explicit JSON Schema type definitions in the code.
Inconsistent error handling across tools. send_slack_message includes actionable error messages ('Either text or blocks must be provided'). delete_slack_message, schedule_slack_message, and get_oauth_url have no visible error guidance, LLMs receive bare exceptions or None responses. Pattern: recovery-guide recommends categorizing errors as retryable vs user-fixable.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 61 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 42 | - | v1 |
Secrets and tokens flow through context objects and are stored/retrieved without explicit validation or sanitization. In check_oauth_status, token_data (team_name, team_id, scope, created_at, expires_at) is returned to the LLM, expires_at suggests expiration logic, but no refresh mechanism or security warning is documented. Pattern: secret-injection forbids credentials in responses.
delete_slack_message (DESTRUCTIVE risk) has no confirmation or dry-run capability. Pattern: confirmation-request recommends gating irreversible operations behind a confirm step. Code shows only: if result.ok: return success else return error. No mention of undo or safety gates.
list_slack_channels accepts limit (default 100, max 100) and cursor but does not document pagination behavior or total count. Pattern: paginated-result requires offset/limit and a next_cursor or total for LLM composition. Current response payload is not documented, unclear if pagination metadata is returned.
Parameter descriptions in delete_slack_message and schedule_slack_message are minimal or missing context. delete_slack_message has only channel and ts descriptions; no guidance on format (e.g., 'Channel ID (e.g., C1234567890) or channel name (#general)'). schedule_slack_message documents post_at as Unix timestamp but does not warn about timezone handling or past dates.
Multiple tools accept channel parameter as 'ID or name' but do not distinguish the two in parameter documentation. send_slack_message documents: 'Channel ID or name (e.g., '#general' or 'C1234567890')', good. But delete_slack_message and schedule_slack_message only say 'Channel ID', which is inconsistent. Pattern: natural-identifiers suggests accepting both and resolving inside the tool, with clear documentation.