Server has 10 tools with basic schemas and descriptions, but significant gaps limit production readiness. All tools have descriptions (10-50 chars, mostly under the 194-char baseline), and most have input schemas. However, many descriptions are generic and lack actionable context. Parameters lack descriptions in several tools (e.g., set_effect's 'effect' param has no guidance on valid values). No output schemas documented. Error handling is minimal, responses are plain text without recovery guidance. Tool naming is reasonable (verb_noun pattern) but some names are vague (e.g., 'get_nanoleaf_info' vs 'get_nanoleaf_status'). No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear read/write distinctions. Composition is reasonable, tools are single-purpose, but missing batch operations and pagination for discovery results.

• Add enum constraints to 'set_effect' parameter. Document valid effect names (e.g., 'Energize', 'Fireplace', 'Neon') in the schema and description to prevent hallucinated values.
• Document output schemas for all tools. Specify returned fields (e.g., get_nanoleaf_info returns {device_id, ip, port, brightness, color_mode, effect_name}). This enables LLMs to chain tools correctly.
• Enhance error responses with recovery guidance. Instead of 'Error during discovery: ...', return structured errors: {error: 'DISCOVERY_TIMEOUT', message: 'Device discovery timed out. Try connect_to_ip() with a known IP address.', retryable: true}.
• Add tool annotations. Mark destructive tools with destructiveHint: true (turn_on, turn_off, set_*, authorize). Mark read-only tools with readOnlyHint: true (get_*, discover, list).
• Expand descriptions to 100-200 chars. Example: 'Get current device state including brightness (0-100), color (HSV), active effect, and power status. Call this first to verify device connectivity.' This guides LLM selection and reduces ambiguity.