Three tools with clear, domain-specific descriptions (60-150 chars each) and proper input schemas. However, parameter descriptions are sparse or missing entirely. crisis_radar__today and crisis_radar__rescore lack parameter-level documentation. The 'window' parameter in crisis_radar__trend has a description but no type constraints (min/max). No output schemas documented. Error handling and recovery guidance absent. Naming is verb-noun compliant but generic (today, trend, rescore), does not clearly distinguish intent from similar tools in a larger toolkit.

• Document output schemas for all three tools. Example for crisis_radar__today: {type: object, properties: {date: {type: string, format: date-time}, total: {type: number}, clusters: {type: object, additionalProperties: {type: number}}, recommendation: {type: string}, risk_level: {type: string}, signal: {type: object, properties: {active: boolean, streak_days: integer, required_days: integer}}, news_paragraph: {type: string}}}
• Add min/max constraints to 'window' parameter: {type: integer, minimum: 1, maximum: 365, default: 30, description: 'Days to look back (1-365)'}
• Add parameter descriptions to crisis_radar__today. If it accepts optional date override, document it: {type: string, format: date, description: 'Target date (YYYY-MM-DD). Defaults to today. If missing, runs pipeline for current date.'}
• Implement error responses with recovery guidance. Example: 'No data for 2024-01-15. Available dates: 2024-01-14, 2024-01-13. Try crisis_radar__rescore with a valid date.' Categorize errors as retryable (timeout, rate limit) vs user-fixable (invalid date) vs fatal (config error).
• Rename tools with clearer verbs and domain context: get_crisis_radar_daily_report, get_crisis_radar_trend_analysis, rescore_crisis_radar_date. Or use consistent prefix: crisis_radar_get_today → crisis_radar_fetch_daily_report.