Loading ToolBench
Model Context Protocol (MCP) server for Discord integration, allowing Claude and other MCP clients to interact with Discord
MCP Discord provides 22 tools with consistent naming and basic schemas, but quality is uneven. Naming follows verb-first conventions (discord_create_*, discord_delete_*, discord_send, etc.), which is good. However, parameter descriptions are sparse or missing entirely. Input schemas are present for all tools but lack depth, most parameters have no description field, only type declarations. The tool descriptions themselves are brief and functional but lack the context needed for optimal LLM selection. No output schemas are documented. Error handling and recovery guidance are absent. This server is typical of community-grade MCP implementations, functional but not production-grade.
Adds multiple emoji reactions to a Discord message at once
Adds an emoji reaction to a specific Discord message
Creates a new category in a Discord server.
Creates a new post in a Discord forum channel with optional tags
Creates a new text channel in a Discord server with an optional topic
Creates a new webhook for a Discord channel
Parameter descriptions missing or incomplete. Most parameters in tool-list.ts lack descriptions, only type declarations are present. For example, 'guildId', 'categoryId', 'channelId', 'messageId' have type 'string' but no description explaining what these IDs represent or how to obtain them. LLMs cannot infer parameter meaning from names alone.
No output schemas documented. Tools like discord_read_messages, discord_get_server_info, discord_get_forum_post return complex data but the response structure is not documented in tool-list.ts. LLMs cannot plan downstream tool calls or extract referenced IDs (e.g., to pass a returned channel_id to discord_send) without seeing the response schema.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 56 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 40 | - | v1 |
Deletes a Discord category by ID.
Deletes a Discord channel with an optional reason
Deletes a forum post or thread with an optional reason
Deletes a specific message from a Discord text channel
Deletes an existing webhook for a Discord channel
Edits an existing Discord category (name and position).
Edits an existing webhook for a Discord channel
Lists all forum channels in a specified Discord server (guild)
Retrieves details about a forum post including its messages
Retrieves detailed information about a Discord server including channels and member count
Logs in to Discord using the configured token
Retrieves messages from a Discord text channel with a configurable limit
Removes a specific emoji reaction from a Discord message
Adds a reply to an existing forum post or thread
Sends a message to a specified Discord text channel
Sends a message to a Discord channel using a webhook
discord_login parameter 'token' is missing a description and violates secret injection pattern. Bot tokens should never be passed as tool parameters, they will be logged, stored in traces, and potentially leaked. Use server-side secret injection via environment variables (DISCORD_TOKEN) instead.
No error handling or recovery guidance. Tool definitions do not specify what happens on failure (e.g., channel not found, insufficient permissions, rate-limited). LLMs need actionable error messages to self-correct or suggest alternatives.
Destructive operations lack confirmation or dry-run capability. Tools like discord_delete_category, discord_delete_channel, discord_delete_message, discord_delete_forum_post, and discord_delete_webhook are irreversible. No mention of preview, confirmation step, or undo path. Agents can accidentally destroy data.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). The MCP spec supports tool annotations to declare tool safety properties. Without these, agents cannot reason about side effects or whether a tool is safe to retry.
Position and ordering parameters lack constraints. Tools like discord_create_category and discord_edit_category accept a 'position' parameter (number) with no minimum/maximum bounds or description of valid range. LLMs could pass negative or extremely large values.
discord_read_messages limit parameter has bounds (1 - 100) and default (50) defined in schema, which is good. However, most other tools lacking numeric parameters means no consistent constraint discipline.