Server has 7 tools with complete schemas and descriptions. Naming follows verb_noun pattern (loxone_get_*, loxone_send_*, loxberry_*). Descriptions are present and substantive (50-150 chars typical). However, parameter descriptions are sparse or missing for several tools (e.g., loxone_get_event_history lacks descriptions for start_time, end_time, limit). Output schemas are not documented in the visible code. Error handling is minimal, no recovery guidance or error categorization visible. Tool composition is reasonable but loxberry_operate is overly generic (accepts arbitrary operation strings), violating single-responsibility principle.

• Split loxberry_operate into specific, named tools: loxberry_restart_service, loxberry_update_config, loxberry_check_updates, etc. Each should have explicit parameters and clear descriptions.
• Add parameter descriptions to loxone_get_event_history: clarify that start_time and end_time are Unix timestamps (seconds or milliseconds?), and document limit bounds (1-100? 1-1000?).
• Document output schemas for all tools. Add a 'Returns' section to each tool description listing the response object structure and field types. Example: 'Returns: {uuid: string, name: string, type: string, visibility: "direct"|"linked"|"hidden"}'.
• Add error recovery guidance to tool descriptions. Example for loxone_get_control_details: 'If UUID not found, call loxone_get_structure first to discover valid control UUIDs.'
• Implement a dry-run or confirmation pattern for loxone_send_command. Add an optional 'dry_run: boolean' parameter that returns what would be sent without executing, or require explicit confirmation via a separate confirm_command tool.

Inferred effective spec: <=2025-11-25.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry