Loading ToolBench
MCP server for Discord integration - D&D session monitoring and communication
The server defines 16 tools with reasonable naming and basic schemas, but falls short of production quality. Naming is generally clear (verb_noun pattern) with good action clarity. However, parameter descriptions are sparse or missing for many tools, output schemas are not explicitly documented, and error handling lacks recovery guidance. Tool definitions are explicitly visible in source code (not inferred), which is positive. The schema completeness varies significantly, some tools have detailed input schemas while others lack parameter descriptions. Most critical gap: no documented output schemas or field mappings, forcing LLMs to infer response structure. This is compounded by missing descriptions for optional parameters and lack of guidance on parameter relationships (e.g., when to use channel_id vs channel_name).
Reply to a Discord user via Botka. For DM replies, provide author_id. For channel replies, provide channel_id (from botka_messages content).
Add a Discord channel to the monitoring list.
Add an emoji reaction to a Discord message.
Delete multiple messages from a Discord channel. Messages older than 14 days are deleted individually.
Fetch messages from Discord channel via REST API with pagination support.
Get message history for a channel within a date range.
No documented output schemas. Tools return responses (e.g., discord_read_messages returns messages, discord_list_channels returns channels) but the response structure, field names, and types are not documented. LLMs cannot reliably compose tool chains without knowing what fields to extract and pass downstream.
Missing parameter descriptions for optional fields. discord_list_channels, discord_list_guilds, and voice_status have empty input schemas (no properties) but descriptions are vague. discord_read_messages accepts limit, channel_id, and channel_name but does not describe the relationship between channel_id and channel_name (mutually exclusive vs. alternative). Pagination parameters (before, after, limit) in discord_fetch_messages lack guidance on defaults and constraints.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 48 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 46 | - | v1 |
List all monitored Discord channels.
List all text channels in a Discord guild.
List all Discord guilds (servers) the bot is a member of.
Read messages from a Discord channel by ID or name.
Search for messages in Discord channels by query text.
Send a message to a Discord channel via REST API.
Join a Discord voice channel and start recording per-speaker audio. Bot must be in the guild.
Leave the voice channel and stop recording. Ends the active recording session.
Get current voice recording status: active sessions, chunks recorded, recent sessions from DB.
Query voice transcriptions. Filter by session, speaker, or full-text search.
Error handling lacks recovery guidance. Handler code includes errorResponse() calls (e.g., 'Channel not found') but does not suggest next steps. Per pattern:recovery-guide, errors should guide the LLM: 'Channel not found. Try discord_list_channels() to see available channels.' Current errors are bare messages without actionable alternatives.
Destructive tools lack confirmation mechanism. discord_delete_messages is marked DESTRUCTIVE but has no dry-run or confirmation step. Per pattern:confirmation-request, irreversible operations should support multi-step confirmation. An agent could delete channels without user approval.
Tool descriptions lack WHEN-to-use context. discord_read_messages and discord_fetch_messages are very similar but distinctions are unclear. Per pattern:tool-description, descriptions should explain WHAT the tool does, WHEN to use it, and any prerequisites. Baseline for good descriptions is 50-200 chars; many here are <50 chars or generic.
Result limits not enforced or documented consistently. discord_fetch_messages caps at 500 messages, discord_read_messages at 200, discord_search_messages at 200. No per-tool justification in descriptions. Per mxe:enforce-result-limits, caps should be stated in tool descriptions to manage context window risk.
No tool annotations. Per Spec Alignment (current 2026-07-28), tools should declare readOnlyHint, destructiveHint, and idempotentHint. Tools like discord_delete_messages (destructive), voice_join (stateful), and discord_read_messages (read-only) should have explicit annotations to guide agent safety reasoning. Currently, Risk metadata is provided in the evaluation input but not in the MCP tool definitions.
Inconsistent parameter naming conventions. botka_reply uses 'author_id' and 'author_name' (good), but discord_add_channel uses 'guild_id' and 'name' (inconsistent suffix). Per naming convention rubric, when multiple identifiers exist (ID + name), suffix both consistently: guild_id, guild_name or guild_id, guild_display_name. This inconsistency forces LLMs to guess field mappings.
Missing rate limiting and timeout guidance. Tools that call Discord REST API (discord_send_message, discord_fetch_messages, etc.) do not document rate limits or timeout behavior. Per pattern:tool-gateway, external service calls should have explicit timeouts and recovery guidance.