RedAlert MCP has 12 tools with consistent naming (verb_noun pattern) and descriptions. All tools have input schemas with Zod validation. However, descriptions are often generic (e.g., 'Get statistics summary of alerts' lacks context on when to use vs. similar tools). Parameter descriptions are present but minimal, many lack format guidance, constraints, or examples of valid values. Output schemas are not documented in the source code, forcing LLMs to infer response structure. Error handling uses formatErrorResult() but lacks recovery guidance or error categorization. No tool annotations (readOnlyHint, destructiveHint) despite clear read/write distinctions.

• Document output schemas for all tools. For each tool, specify: response type (object/array), field names, field types, and which fields are required. Example: 'Returns {alerts: Alert[], total: number, nextCursor?: string}' where Alert = {id, type, city, timestamp}.
• Rewrite stats tool descriptions to clarify distinctions. E.g., 'get_stats_summary: High-level alert counts and trends over a date range. Use this for dashboards. get_stats_cities: Breakdown by city. Use this to find which cities are most affected. get_stats_history: Detailed per-alert records. Use this for audit trails or detailed analysis.'
• Add format and enum constraints to parameters. E.g., startDate: 'ISO 8601 date string (YYYY-MM-DD)', sort: 'One of: timestamp, count, city', order: 'One of: asc, desc'.
• Enhance error responses with recovery guidance. E.g., instead of 'Connection failed', return 'Connection to RedAlert server failed. Retry in 5 seconds or call health_check() to verify service status.'
• Add tool annotations via MCP SDK. Mark subscribe_alerts and unsubscribe_alerts with destructiveHint: true. Mark all read-only tools with readOnlyHint: true. Mark idempotent tools (health_check, get_*) with idempotentHint: true.