This server presents 7 tools with mixed quality. Tool definitions are present in dashboard files (ToolPicker.tsx, Tools.tsx), but CRITICAL ISSUE: the actual MCP server implementation source code is NOT provided, only Dockerfile, package.json files, and React dashboard components are visible. The server appears to be HTTP-based (Express), but the core MCP tool registration, schema definitions, and error handling logic cannot be verified from the provided code. For the 7 tools documented in the dashboard: 1. NAMING (average 75): All tools use clear verb_noun format (read_messages, send_message, add_reaction, etc.), which is excellent. Names are self-documenting and follow arcade.dev patterns. No compound 'and' names. ✓ 2. DESCRIPTIONS (average 55): Descriptions exist for all 7 tools and range from 50-170 characters. However, most lack depth. For example, 'read_messages' has a solid description explaining the 15-minute queue and filtering behavior. But 'list_channels' is bare ('List Discord channels this entity can access'), 42 chars, minimal guidance on when to call vs get_channel_history. 'introduce' description (58 chars) omits whether it requires special permissions or how formatting works. Most descriptions are under 100 chars and lack WHEN/WHY/HOW context that LLMs need for robust selection. Baseline is 194 chars for A+ tools. 3. PARAMETERS (average 45): Critical gap. Tool definitions list parameter names, types, and brief descriptions, BUT: - Parameters are documented in the React components (ToolPicker.tsx, Tools.tsx), NOT in the actual MCP server code visible here. - No input schemas are visible in the provided source code. - Parameter validation rules are not documented (e.g., channel_id format, message_id constraints, emoji format beyond '👍'). - Many parameters lack format guidance: 'channel_id' is a string, but is it a numeric Discord ID or a slug? The description just says 'Channel ID'. - 'read_messages' has good param descriptions for limit (default 50) and boolean flags, but 'get_entity_info' has ZERO parameters, no schema shown. - No documented dependencies between parameters (e.g., 'emoji' param says 'custom emoji name', what format? How does the bot resolve custom emoji?). 4. OUTPUT SCHEMAS (average 35): MAJOR GAP. No output schemas are documented in the provided code. For example: - What does 'read_messages' return? Assume a list of message objects, but what fields? {id, content, author, timestamp}? Are timestamps ISO 8601 or Unix? Are attachments included? - 'send_message', does it return the sent message? Just a success bool? Missing message_id needed for reactions/edits? - 'list_channels', what fields? channel_id, name, topic, type? Pagination? - 'get_entity_info', what identity fields? Missing: would force LLM to guess structure. - This violates the output schema requirement (100% of A+ tools have documented return types). All 7 tools score ~0 on output documentation. 5. ERROR HANDLING (average 20): No error guidance visible. No recovery hints, no retryable/fatal classification. The MCP server source code (where error handling would be) is not provided. 6. SECURITY (average 30): - No visible mention of permission gates or scope declarations. - Tool descriptions mention 'this entity' (Discord bot identity) but no indication of RBAC or per-tool permission checks. - No audit trail guidance. - 'send_message' and 'send_dm' (in ToolPicker hint) could be high-risk, no dry-run or confirmation pattern mentioned. 7. COMPOSITION (average 35): - read_messages → send_message chain seems sound (get channel context, then reply). - 'introduce' reads 'get_entity_info', so multi-step is possible. - However, many tools overlap or have unclear sequencing (list_channels vs get_channel_history vs search_messages, when use each?). - No documented tool chains or prerequisites. PER-TOOL BREAKDOWN (7 tools evaluated from React dashboard; actual MCP registration NOT visible):

• URGENT: Provide the full MCP server source (src/index.ts, src/tools/*.ts) to verify actual tool registration, input schemas, output schemas, and error handling. Current evaluation is incomplete.
• Document the complete return type for each tool. Minimum: tool returns {success: bool, ...result_fields} with all fields typed and described. Example: read_messages returns {messages: [{id, content, author_id, timestamp_iso8601, attachments?}], total_count, next_cursor?}
• Add constraint documentation to ALL parameters. For each param, state the type, format, range, and any special handling: - channel_id: 'Discord numeric channel ID (19 digits, e.g., 1234567890123456789)' - emoji: 'Native Unicode emoji (e.g., 👍) or custom emoji name with colons (e.g., :custom_emoji:)' - limit: 'Number of results to return (1 - 100, default 50). Values >100 are capped at 100.'
• Expand descriptions to 100 - 200 characters and include WHEN to use and how to distinguish from similar tools. Example for list_channels: 'List all channels this entity can access. Returns channel metadata (id, name, topic, type). Use this to discover available channels before reading messages. For real-time history of a specific channel, use get_channel_history instead.'
• Add recovery guidance to error responses. In the MCP error handler, return structured errors: {error: 'channel_not_found', message: 'Channel (123) not found. Available channels: [...]', recoverable: true, next_step: 'Try list_channels() to find the correct ID.'}
• Document tool security & scope. For each write tool (send_message, add_reaction, introduce), add a permissions field: {name: 'send_message', permissions: ['write:message'], requires_confirmation: false, ...}

Inferred effective spec: 2026-07-28+.

• Relies on Stateful initialize / Mcp-Session-Id (removed; protocol is stateless) - make each request self-contained