Loading ToolBench
The server defines 8 tools with explicit schemas, descriptions, and parameter types. Naming follows verb_noun conventions (list_, post_, get_, reply_to_, add_), which is good. Descriptions are present and contextually appropriate (10-250 chars range). However, there are significant gaps: (1) No output schemas documented for any tool, LLMs cannot plan downstream calls or know what fields to extract; (2) Parameter descriptions lack constraint details (e.g., timestamp format, channel_id syntax, cursor format); (3) No error handling guidance, failures return raw API responses without recovery hints; (4) Missing pagination continuation info in list tools; (5) No documentation of which operations are idempotent or have side effects (critical for agent retry logic); (6) slack_list_channels and slack_get_users support pagination but responses don't indicate whether more results exist or provide continuation tokens. The server is above minimal viability but lacks production-grade completeness.
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
List public or pre-defined channels in the workspace with pagination
No output schemas documented. LLMs cannot determine what fields are returned, preventing them from planning downstream tool calls or extracting required IDs for chaining (e.g., channel_id from list_channels to pass to post_message).
Parameter descriptions lack explicit format and constraint details. For example, 'thread_ts' says 'format 1234567890.123456' but does not indicate this is a Slack timestamp format or how to obtain it. 'cursor' is undescribed in pagination context.
No error handling guidance or recovery hints. If a tool fails (e.g., 'channel not found', 'invalid reaction'), there is no indication of what the LLM should do next (retry, ask user, call a discovery tool).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 55 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Post a new message to a Slack channel
Reply to a specific message thread in Slack
Pagination tools (slack_list_channels, slack_get_users) do not document pagination continuation. No indication whether a 'next_cursor' exists, total count, or whether results are exhausted. This prevents agents from recognizing when to stop pagination.
No explicit documentation of tool idempotence or side effects. Agents need to know which calls are safe to retry (e.g., GET operations) and which have irreversible consequences (post_message, add_reaction). Without this, agents may hesitate to retry on ambiguous failures.
slack_get_channel_history has a default limit of 10, which is quite low. Agents may need to make multiple calls to get a meaningful conversation history. Consider documenting recommended limits for common use cases.
Parameter descriptions do not explain when or why to use optional parameters. For example, slack_list_channels has optional 'limit' and 'cursor' but does not hint at typical pagination flow (call without cursor, get page, check if more exist, call with returned cursor).