Single tool 'system_info' has a detailed description (194 chars) and clear input schema with enum constraints for categories. However, the tool lacks critical production-grade patterns: no output schema documentation, no error handling guidance, no parameter descriptions beyond the array itself, and no indication of what fields are returned. The description is informative but does not explain WHEN to use this tool vs alternatives, what prerequisites exist, or how to interpret results. Parameter 'categories' has a description but lacks guidance on behavior when empty/omitted (description says 'all categories are returned' but this is buried in the array description, not the parameter itself). No per-parameter descriptions for the enum values (cpu, memory, gpu, disk, os, network, display). Output is inferred from the description text rather than formally documented in a schema.

• Add a formal JSON Schema for the response object documenting all returned fields (e.g., cpu.physical_cores: integer, cpu.brand: string, memory.total_bytes: number, gpu: array of {model, vram_mb, core_count}, etc.). This enables LLMs to reliably extract and chain data.
• Add descriptions to each enum value in the 'categories' parameter. E.g., 'cpu: Processor info (cores, brand, frequency)', 'gpu: Graphics accelerators (model, VRAM, core count)', 'network: Network interfaces (names, IPs, MAC addresses)'.
• Document error cases in the tool description: 'Returns partial results if some categories fail (e.g., GPU detection unavailable on non-Apple systems). Check returned object for presence of expected fields.'
• Expand the tool description to include use cases and prerequisites: 'Use this to gather system diagnostics for troubleshooting, capacity planning, or environment reporting. Works best on macOS; some fields (P/E cores, GPU core count) are Apple Silicon-specific.'
• Migrate from STDIO to HTTP+SSE or Streamable HTTP transport to enable remote access and hosted client compatibility.