This OS information helper has 15 tools covering system monitoring. All tools are READ_ONLY and have basic descriptions. However, there are systematic gaps in parameter descriptions, missing output schemas, and inconsistent definition quality. Tool names follow verb_noun convention reasonably well (get_*, list_*, initialize_*, monitor_*, find_*), but many parameter descriptions are minimal or absent. The codebase shows schema validation for some parameters (e.g., limit constraints in get_running_processes), but output schemas are not explicitly documented anywhere. Error handling is present but generic. Most tools would benefit from richer parameter descriptions, explicit output schema documentation, and more detailed guidance on when to use each tool versus alternatives.

• Document output schemas for all 15 tools. Create a schema documentation comment block for each tool describing the JSON structure returned. Example for get_running_processes: 'Returns a dict with keys: {processes: [{pid, name, cpu_percent, memory_mb, create_time, status, username}, ...], total_count: int, limit_applied: int, timestamp: ISO8601}'.
• Enhance parameter descriptions with explicit constraints and examples. For limit parameters, state: 'Limit results to N processes (1 - 50, default 15). Higher limits risk context window exhaustion.' For duration_seconds and check_interval, state: 'Seconds (1 - 300, default 10). Intervals below 1 second cause high CPU usage.'
• Clarify overlapping tools with WHEN-to-call guidance. In get_os_info description, add: 'Call this after initialize_os_connection to get detailed system info. Use get_system_boot_info instead if you only need uptime and boot time.'
• Add pagination/result count limits. For list_open_ports and get_active_connections, add a limit parameter (default 50, max 500) and return a total_count field. State in description: 'Returns up to 50 connections; call with higher limit or offset for more results.'
• Implement error classification and recovery guidance. Replace generic errors with: (1) Categorize the error (retryable, user-fixable, unrecoverable), (2) Return actionable recovery hints. Example: 'Battery info unavailable on non-laptop systems. Call get_system_resource_usage for overall power metrics instead.'
• Standardize tool naming and add discovery hints. Create a single get_processes tool with filters (status, category, sort_by) instead of find_process + get_running_processes. Add a note: 'Use this for all process queries. filter by status="running" or category="Development Tool" for common tasks.'

Inferred effective spec: <=2025-11-25.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry