Loading ToolBench
MCP server for Slack integration, meeting notes, and follow-ups
SmartIntern exhibits significant gaps in definition quality across most tools. While tool names follow verb_noun conventions (list_channels, get_channel_info, send_message), descriptions are generic and many critical parameters lack detailed constraints. The codebase shows explicit tool registration with schemas in src/mcp/tools/*.ts files, but schema quality is inconsistent, some tools have minimal parameter descriptions, and output schemas are not visible in the provided source. Parameter descriptions often lack specificity about format, constraints, and dependencies (e.g., 'Max number of messages' for limit parameter lacks min/max bounds; 'Message text' for send_message text parameter lacks length constraints). No enum constraints are defined for status fields in track_follow_up_status and remind_action_items. Error handling guidance is absent from descriptions. Security concerns: the server uses PostgreSQL and Slack API tokens but descriptions do not indicate how credentials are injected, params suggest they may be embedded server-side (good) but this is not documented. Overall, this reads like a minimal MVP rather than production-grade tooling.
Create a follow-up reminder for an action item
Create and post meeting notes from a Slack conversation
Extract action items from a Slack conversation
Get recent messages from a Slack channel
Get detailed information about a Slack channel
Get replies in a Slack thread
List available Slack channels
Parameter descriptions lack specificity about format, range, and constraints. Example: 'Max number of messages' for limit parameter in get_channel_history does not specify min/max bounds (pattern baseline: min - max bounds required). No enum constraints for status fields in track_follow_up_status ('status', 'new_status'), LLM cannot infer valid values.
Output schemas are not documented in tool descriptions or visible in source code. LLMs cannot plan downstream tool calls or extract required fields (e.g., does get_channel_info return a channel_id for use in send_message?). Pattern baseline: 100% of A+ tools have documented return types.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 31 | - | v1 |
Send reminders for open action items
Send a message to a Slack channel
Get or update follow-up status
Error handling guidance is absent. Descriptions do not tell LLMs what to do on failure (e.g., 'If channel not found, try list_channels() to discover available channels'). Pattern baseline: error responses must guide recovery.
Tool descriptions are too generic. Example: send_message description is 'Send a message to a Slack channel' (30 chars), pattern baseline is 10 - 1024, but descriptions should be 50 - 200 chars to provide actionable context. No mention of threading, mentions, formatting, or rate limits.
track_follow_up_status tool is ambiguous in intent and naming. It accepts optional 'status' (filter?), optional 'action_item_id' (lookup?), and optional 'new_status' (update?). This combines READ and WRITE behavior in one tool, violating single-responsibility principle. Description does not clarify when each parameter is used. Should be split into track_follow_up_status (read) and update_follow_up_status (write).
create_meeting_notes and extract_action_items both accept optional 'post_to_channel' / 'post_summary' boolean parameters with no guidance on default behavior. Per pattern baseline, defaults must not cause unintended side effects, posting to channel may be destructive if not explicit. Descriptions do not indicate whether these are mutually exclusive.
Parameters accept both IDs and human-readable names (implied by Slack context), but descriptions do not clarify this. Example: 'channel_id' description says 'The ID of the channel', does this accept 'general' or only 'C1234567890'? Per pattern baseline, suffix parameters with type (channel_id vs channel_name) or document both forms.
No pagination support visible in list_channels or get_channel_history descriptions. Per pattern baseline, tools returning lists should accept page/offset and limit parameters and return a total count or next_cursor. get_channel_history accepts limit but no offset/cursor for pagination.
Composition risk: create_follow_up and track_follow_up_status suggest a follow-up tracking system, but their relationship to create_meeting_notes and extract_action_items is unclear. Do meeting notes automatically create follow-ups? Must extract_action_items precede create_follow_up? Descriptions do not document the workflow or tool dependencies.