Loading ToolBench
Two tools are explicitly defined with basic schemas and descriptions. However, definitions lack depth required for production LLM agents. slack_get_users has reasonable parameter documentation but lacks output schema specification. slack_post_message has minimal parameter descriptions and no guidance on error recovery or prerequisites. Neither tool description explains WHEN to use it vs alternatives, what happens on failure, or what the response structure contains. Parameter naming is clear but lacks constraints (e.g., message length limits, valid channel formats). Error handling exists but returns raw JSON responses without actionable recovery guidance. No tool annotations (readOnlyHint, destructiveHint). Missing critical patterns: recovery-guide, response-shaper, paginated-result details.
Get a list of all users in the workspace with basic information
Post a new message to a Slack channel
No output schema documentation. LLMs cannot plan downstream tool calls or extract return values without knowing response structure. slack_get_users should document that it returns {members: [{id, name, email, ...}], response_metadata: {next_cursor?}}. slack_post_message should document {ok: boolean, channel: string, ts: string, message: {...}}.
slack_post_message description is minimal (39 characters) and omits when/why to use it vs other Slack tools. No mention that this tool MODIFIES STATE (sends a message), agents need to know calls have irreversible consequences before attempting retries. State modification: message is immediately visible to channel members. Requires valid channel_id and non-empty text.'
Error messages in src/index.ts return raw JSON error objects without actionable recovery guidance. Example: 'Unknown tool: slack_xyz' gives the agent nothing to do. Per pattern:recovery-guide, errors should guide next steps: 'Unknown tool. Available tools: slack_get_users, slack_post_message. Did you mean slack_get_users?'
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 10 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 43 | - | v1 |
slack_get_users accepts 'limit' (number, 1-200) but parameter description lacks min/max constraints. Description states 'default 100, max 200' in prose but not as JSON Schema minValue/maxValue. No constraint on minimum value (0 is invalid but not prevented). No documentation of pagination behavior or when to use next_cursor.
slack_post_message 'text' parameter has no length constraint or format guidance. Slack API has limits (4000 characters); LLMs will pass arbitrarily long text, causing silent truncation or API errors. Description should state: 'Message text (1-4000 characters, supports Slack markdown).'
slack_post_message 'channel_id' parameter description is vague ('The Channel ID to post the message to'). No guidance on format (e.g., 'C1234567890', not 'general' or '#general'). slack_get_users has no way to return channel_id values, forcing LLMs to guess or look up channel IDs by hand.
No tool annotations. slack_post_message should have destructiveHint: true and idempotentHint: false (posting the same message twice creates two messages). slack_get_users should have readOnlyHint: true. Annotations guide agent behavior and LLM understanding of side effects.
slack_get_users description omits pagination guidance. It says 'Get a list of all users' (misleading, it's paginated, not comprehensive) but doesn't explain that cursor and limit are used for pagination, or when to call again. Description should state: 'Retrieve paginated user list. Use limit to cap results (default 100, max 200). Use cursor to fetch next page from response_metadata.next_cursor.'