Server provides 7 read-only tools with consistent naming (sc_* prefix) and reasonable descriptions (avg 180 chars). However, most tools lack input schemas entirely (5 of 7 have empty {}), and parameter descriptions are minimal. sc_alerts has a proper schema with 2 params, but others expose no configurable inputs. Descriptions are domain-specific and helpful for storage admins, but lack LLM-optimized guidance on when to call each tool vs. alternatives. No error recovery hints, no output schema documentation, and no tool annotations. Follows basic tool pattern but misses composition and schema rigor expected of production tools.

• Add input schemas to all 6 tools with empty {}. Define parameters explicitly: sc_storage_center() needs no params (keep {}), but sc_capacity() should document any optional filters if the API supports them. Use JSON Schema with type, description, and enum for category.
• Document output schemas for all tools. For sc_alerts, specify: {"count": integer, "alerts": [{"time": string, "status": enum, "active": boolean, "category": string, "controller": string, "message": string}]}. Include field types and meanings.
• Add error recovery hints to descriptions. E.g. sc_alerts: 'If no alerts returned, verify SC_HOST and credentials are set. If connection fails, check network and TLS settings (SC_TLS_VERIFY).'
• Enhance descriptions with tool-selection guidance. E.g. sc_capacity: 'Call this FIRST for any space/full-pool question. Returns disk folder status, thresholds, and projected full dates. Then drill into sc_volumes for per-volume details.' Similar hints for sc_hardware + sc_alerts correlation.
• Add enum constraint to sc_alerts category parameter: {"type": "string", "enum": ["Hardware", "Storage", "System"], "description": "Filter alerts by category. Omit for all categories."}. Prevents hallucinated values.