14 tools with consistent verb-noun naming (get_*, stream_*) and clear descriptions (avg ~120 chars). All tools are READ_ONLY with no state-modifying operations. Input schemas present for most tools with parameter descriptions. However, schemas lack formal type constraints (enums, min/max bounds), output schemas are not documented, and parameter descriptions are minimal (10-30 chars). No error handling guidance, no pagination support despite tools returning potentially large datasets, and no tool annotations (readOnlyHint, etc.). Composition is sound, each tool has one responsibility, but output chaining is not documented.

• Document output schemas for all 14 tools. For each tool, specify the JSON structure returned: field names, types, and what each field represents. Example: get_system_info returns {cpu: {cores: int, usage: float}, memory: {total: int, used: int, free: int}, uptime: int}.
• Add enum constraints to string parameters. In get_issues, change severity parameter to include enum: ['critical', 'warning', 'info', '']. In stream_system_report, add enum for collectors with all valid names: ['os', 'system', 'disk', 'network', 'packages', 'services', 'security', 'hardware', 'docker', 'snaps', 'gpu', 'logs'].
• Expand parameter descriptions to 50-150 chars with format guidance. Example: 'mount_point: Filter results to a specific filesystem mount point (e.g., /, /home, /var). Leave empty to return all mounted filesystems.' This helps LLMs understand valid inputs.
• Add pagination support to tools returning lists. Add optional limit (default 20, max 100) and offset parameters to get_issues and get_log_info. Return total_count in response so agents know if more results exist.
• Document error scenarios and recovery paths in tool descriptions. Example: 'If the system is not accessible, returns error code 503 with message "System data unavailable". Retry after 30 seconds or check system connectivity.' This guides LLM recovery behavior.