This server has critical definition gaps. Tool descriptions are minimal (4-24 chars, well below the 50-200 char baseline for LLM optimization). Most parameters lack descriptions entirely. Input schemas are present but sparse. No output schemas documented. Error handling is minimal. The scenario-driven design (ethical dilemma simulation) is creative but does not compensate for poor tool interface quality. No tool annotations (readOnlyHint/destructiveHint) despite clear risk levels. Naming is verb-based but descriptions fail to explain WHEN to use each tool or what it returns.

• Expand all tool descriptions to 80-150 chars. Example: 'checkRooms' → 'Check the current status of a room (fire detection, power, sprinkler activation). Returns room status, occupants, and contents. Use before deciding to cut power or activate sprinklers.'
• Document output schemas for all tools. E.g., getAvailableEnergy should return {availableEnergy: number, unit: string, timestamp: string}. This enables agents to chain calls and extract required fields.
• Add tool annotations: mark cutRoomPower with destructiveHint=true, setSprinklerStatus with idempotentHint=true (repeated calls with same params produce same result), and all get_* tools with readOnlyHint=true.
• Enhance error messages with recovery guidance. E.g., 'Room not found (ID: 5). Valid rooms are: 1 (Baby Room), 2 (CEO Office). Try checkRooms() to list available rooms.'
• Add parameter descriptions explaining the semantic meaning and constraints. E.g., sprinklerId: 'Sprinkler ID (1-4). Sprinklers 1-2 serve Baby Room, 3-4 serve CEO Office. Use getSprinklers(roomId) to discover available sprinklers in a room.'