Console-mcp has 10 tools with complete input schemas and descriptions, but quality is uneven. Tool names follow verb_noun convention (get_, list_, stream_) which is good. However, descriptions are generic and lack actionable context for LLM selection. Parameters have types and enums where appropriate (logLevel), but descriptions are minimal (10-30 chars). No output schemas are documented. Error handling is present but not recovery-focused. The server lacks tool annotations (readOnlyHint, idempotentHint) despite all tools being read-only. No pagination support despite tools returning potentially large result sets.

• Add output schemas to all tools. Document the structure of returned objects (e.g., get_console_logs returns {logs: string[], timestamp: string, processCount: number}). This enables LLMs to chain tools and extract the right fields.
• Expand tool descriptions to 100-150 chars. Include WHEN to use each tool. Example: 'Get recent macOS Console.app logs (last N minutes). Use this for historical logs; use stream_console_logs for real-time monitoring. Returns raw log lines as a string.'
• Add readOnlyHint: true to all tool definitions. This signals to LLMs that these tools are safe to retry on transient failures and do not modify state.
• Add pagination to list_connected_devices, list_simulators, and get_crash_reports. Include limit (default 20, max 100) and offset parameters. Return total_count so LLMs know if more results exist.
• Clarify process filter behavior in parameter descriptions. Specify: 'Process name substring match (case-insensitive). If no process matches, returns all logs. Example: process="Safari" matches com.apple.Safari and Safari.'
• Document error recovery paths. When idevicesyslog is unavailable, the tool returns a fallback message. Add to description: 'If device logs fail, ensure device is connected and trusted. Call list_connected_devices first to verify device UDID.'