Loading ToolBench
A Discord bot with MCP (Model Context Protocol) server integration, providing tools for Discord user and guild management, message sending, voice recording with Whisper STT transcription, and audio playback via Lavalink/Wavelink.
Discord-MCP-Server shows inconsistent quality across tools. 6 out of 7 tools have acceptable descriptions (50-150 chars), and all 7 have properly typed JSON schemas with parameter descriptions. However, critical issues emerge: (1) naming conventions are inconsistent, send_message_to_user requires a user_name parameter but should accept user_id as the primary identifier for performance; (2) send_message_to_channel uses channel_id which conflicts with the database's discord_channel_id naming; (3) error handling is minimal, most tools return generic error strings rather than actionable recovery guidance; (4) no parameter constraints (enums, ranges, regex patterns) are visible; (5) output schemas lack documentation for list-returning tools (get_known_users, get_known_guilds, get_guild_channels_tool); (6) one tool (get_guild_channels_tool) has an awkward name that violates verb_noun convention. The codebase shows database operations are present, but no rate limiting, pagination support, or batch operations are evident. Average tool description length is ~85 chars (p10 baseline 34, p90 baseline 392), suggesting adequate but terse documentation.
Adds a known guild to the database. Args: - guild_name (str): The name of the guild. - discord_guild_id (int): The Discord ID of the guild.
Adds a known user to the database. Args: - user_name (str): The name of the user. - discord_id (int): The Discord ID of the user.
Retrieves a list of channels for a given guild from the database. Args: - guild_id (int): The ID of the guild. Returns: - List of dicts containing channel information.
Retrieves a list of known guilds from the database. Returns: - List of dicts containing guild information.
Retrieves a list of known users from the database. Returns: - List of dicts containing user information.
Sends a message to a channel by its Discord ID. Args: - message (str): The message to send. - channel_id (int): The Discord ID of the channel to send the message to.
Tool naming convention violation: get_guild_channels_tool includes a '_tool' suffix which violates verb_noun pattern. Should be 'get_channels' or 'list_guild_channels'. This signals a naming collision that should be resolved at design time.
Parameter-identifier mismatch: send_message_to_user accepts user_name but should accept user_id as primary parameter for performance. Requiring name-based lookup inside the tool adds latency and introduces ambiguity if multiple users share a name. Similar issue in send_message_to_channel (uses channel_id, not discord_channel_id).
Missing output schemas: Tools returning lists (get_known_users, get_known_guilds, get_guild_channels_tool) do not document their return structure in docstrings. LLMs cannot predict field names and types, forcing them to guess or require example values. Each should document: returns list[dict] with fields {field: type, ...}.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 58 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Sends a message to a user by their Discord ID. Args: - message (str): The message to send. - user_name (str): The name of the user to send the message to.
Generic error messages: All error returns are unstructured strings (e.g., 'Failed to send message: {e}', 'User added successfully.'). LLMs receive no recovery guidance. Should include: (1) error category (retryable vs fatal), (2) constraint violated, (3) suggested next step. E.g., 'User not found. Try get_known_users() to see available users.'
No parameter constraints: Parameters like message (strings) and discord_id (integers) lack validation constraints in descriptions. No mention of length limits for message, ranges for numeric IDs, or format patterns. LLMs will pass arbitrarily large strings or negative IDs, causing failures.
No pagination support: Tools returning lists (get_known_users, get_known_guilds, get_guild_channels_tool) do not accept limit, offset, or cursor parameters. If a guild has thousands of channels, the entire list is returned, potentially exhausting context windows and wasting tokens.
Inconsistent async/sync signatures: send_message_to_user and send_message_to_channel are async; get_known_guilds and add_known_guild are sync. No documented reason for this variance. Inconsistency increases cognitive load and invites errors.
No idempotency contract: add_known_user and add_known_guild do not document whether calling them twice with identical inputs is safe (idempotent) or will create duplicates. Agents retry on ambiguous failures, non-idempotent operations risk data duplication.
Missing chaining IDs in responses: add_known_user and add_known_guild return only success/failure strings. They should return the created record's ID (user_id or guild_id) so downstream tools can reference it. Current design forces agents to call get_known_users() afterward to retrieve the ID, wasting a round-trip.