Loading ToolBench
MCP server for Discord management providing tools to interact with Discord servers, channels, messages, users, roles, webhooks, and more
Discord-mcp provides 20 tools with consistent naming patterns (verb_noun style), but exhibits significant gaps in schema completeness, parameter documentation, and error handling guidance. Tool descriptions are present but often generic. While the naming follows conventions well, the schema definitions lack depth, many parameters are missing type information or descriptions, and output schemas are not documented. No evidence of error handling guidance, confirmation patterns for destructive operations, or recovery suggestions. The server does implement basic Spring AI MCP patterns and provides valid tool registration, but falls short of production-grade quality.
Create a new category for channels
Upload a new custom emoji to the server. Provide image as base64 (Data URI or raw) OR a direct image URL. Max 256KB
Create a new text channel
Delete a category
Delete a channel
Deletes a permission overwrite for a role or member from a channel
Missing or incomplete input schemas for most tools. Parameters declared but many lack type definitions (e.g., guildId, categoryId often marked 'type:string' with minimal constraint info). Several parameters missing descriptions or have only 1-2 word descriptions.
Destructive operations (delete_category, delete_channel, delete_emoji) lack confirmation/dry-run patterns and no error recovery guidance. Descriptions do not warn of irreversibility or suggest confirmation steps before executing.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 61 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 40 | - | v1 |
Permanently delete a custom emoji from the server
Edit a category (rename or move position)
Edit an existing emoji's name or role restrictions
Edit settings of a text channel (name, topic, nsfw, slowmode, category, position)
Find a category ID using name and server ID
Find a channel type and ID using name and server ID
Get detailed information about a specific custom emoji
Get detailed discord server information
Returns all permission overwrites for a channel with role/member breakdown and allow/deny details
List of all channels
List of channels in a specific category
List all custom emojis on the server
Creates or updates permission overwrite for a member on a channel
Creates or updates permission overwrite for a role on a channel
No documented output schemas for any tool. LLMs cannot infer what fields will be returned, forcing them to plan blind and unable to chain results to downstream tools. Missing return type documentation is a production blocker.
Tool descriptions are too generic and do not explain WHEN to use a tool vs similar alternatives. For example, find_category vs list_channels vs get_server_info all discover data but lack guidance on which to call first or when one is preferable.
Several parameters marked 'required:false' with no explanation of defaults or behavior when omitted. E.g., guildId is optional in most tools but no guidance on whether it infers from context, uses a global default, or fails silently.
No evidence of error handling guidance in tool definitions. Descriptions do not indicate what errors might occur (e.g., 'Channel not found', 'Insufficient permissions'), how to recover, or what to try next.
Parameter descriptions for complex fields (e.g., allowRaw, denyRaw in permission tools, allowPermissions, denyPermissions) are terse and do not explain format, constraints, or examples. LLMs cannot infer how to construct bitfield values or CSV lists without clearer guidance.
create_emoji tool accepts both 'image' (base64) and 'imageUrl' parameters but does not document whether both are optional, mutually exclusive, or if priority exists when both are provided.
List tools (list_channels, list_emojis, list_channels_in_category) have no pagination parameters (limit, offset, cursor) or return count documentation. Large Discord servers could return hundreds of items, exhausting context windows.
Tool annotations (readOnlyHint, destructiveHint, idempotentHint) are not present in source code but are declared in the FEATURES section. These should be explicitly applied to tools based on their Risk category for better agent planning.