Six tools with clear action verbs and privacy-focused descriptions. However, critical gaps undermine production readiness: (1) All tools have empty input schemas (no parameters documented despite is_system_busy accepting cpu_threshold and memory_threshold); (2) Parameter descriptions missing entirely, is_system_busy's thresholds lack units, ranges, or defaults; (3) No output schemas documented, callers cannot plan downstream operations; (4) Error handling absent, no guidance on failure modes or recovery; (5) Descriptions are adequate (100-150 chars) but lack WHEN/WHY context for LLM selection. Tools are read-only and safe, but schema incompleteness and missing parameter docs violate pattern:tool and pattern:tool-description baselines.

• Add explicit input schemas to all tools. For is_system_busy, define cpu_threshold and memory_threshold as numbers with minimum: 0, maximum: 100, default: 80 and 85 respectively, and descriptions: 'CPU usage percentage threshold (0 - 100, default 80)' and 'Memory usage percentage threshold (0 - 100, default 85)'.
• Document output schemas for all tools. Define the SystemMetrics object with typed fields (cpu_usage_percent: number, cpu_count_logical: integer, memory_total_bytes: integer, etc.) so LLMs know what to expect and can chain calls.
• Expand tool descriptions to include WHEN to use each tool. Example: 'get_cpu: Returns only CPU usage and core count. Use this for quick CPU checks; use get_metrics for a complete system snapshot.' This disambiguates overlapping tools.
• Add error handling guidance. Document failure modes: 'On Linux, may fail if /proc is inaccessible (permission denied). On Windows, process_count returns 0 (not supported). Failures return null fields with an error message in the response.'
• Provide parameter constraints in descriptions. For is_system_busy, clarify: 'cpu_threshold: CPU usage percentage (0 - 100, default 80). Values above 100 are clamped to 100. memory_threshold: Memory usage percentage (0 - 100, default 85).'