Loading ToolBench
MCP server implementation for Discord integration with LLM capabilities, system monitoring, and task management
This MCP server has significant definition quality gaps across all 5 tools. While all tools have descriptions and basic parameter schemas, the descriptions lack critical context for LLM selection, parameter descriptions are incomplete or generic, output schemas are entirely undocumented, and error handling is not explicitly visible. The server mixes Discord operations with destructive system commands (execute_shell_command) in a single tool set, violating composition principles. No tool has documented return types or error recovery guidance. Tool names follow verb_noun convention (positive), but parameters often lack type suffixes (user_id is good, but many accept string IDs without guidance on format or resolution). The tool that accepts shell commands with only user_id authorization (no approval/confirmation by default) represents a critical security concern. Overall, this server reads as a prototype or MVP with insufficient hardening for production agentic use.
Analyze a Discord message and suggest actions
Create a task based on Discord message
Execute shell command on host system - REQUIRES ADMIN
Get real-time system information (CPU, RAM, disk usage)
Send a message to a Discord channel
execute_shell_command is critically unsafe: defaults require_confirmation to false, accepts arbitrary shell commands with only user_id validation, and provides no description of output format, sanitization, timeout, or error recovery. A single malicious prompt could delete entire filesystems or expose secrets.
No tool documents output schemas. LLMs cannot anticipate response structure, field types, or available chaining IDs (e.g., task_id after create_task_from_message, message_id after send_discord_message). This forces wasteful discovery calls and invites parsing errors.
Tool descriptions lack critical context: no WHEN to call each tool, no WHAT is returned, no recovery guidance on errors. E.g., send_discord_message does not say whether it returns a message URL or just a confirmation. This forces LLMs to guess tool selection.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 52 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Mixing Discord collaboration tools with destructive system commands (execute_shell_command) violates single-responsibility composition. Each tool should do one clear job, this server mixes chat integrations with host administration, creating a confusing surface and amplifying blast radius if compromised.
Parameters lack descriptions or use generic descriptions. E.g., 'user_id' parameter appears in multiple tools but is never explained: is it a Discord user ID, system user, or agent identity? No guidance on format. 'info_type' in get_system_info has an enum but the description does not explain what each type returns.
Dangerous defaults: send_discord_message requires_approval defaults to false (allows unapproved sends), execute_shell_command require_confirmation defaults to false (allows unapproved command execution). These violate the default-values pattern and invite accidental destructive actions.
No error handling or recovery guidance visible. Tools provide no hints on what to do if a Discord channel is not found, a user lacks permission, a shell command times out, or a task creation fails. LLMs cannot self-correct without explicit error categories and suggestions.
user_id parameter used for authorization/authentication in multiple tools but no scope declaration or permission model documented. How does authorization actually work? Is there a role-based access control system? Are there audit logs? This is vague and suggests security implementation is incomplete.