Seven tools with basic schemas and descriptions, but significant gaps in parameter documentation and output schema clarity. Tool names follow verb_noun convention (audio_set_volume, theme_get, calendar_add, app_launch, panel_open), which is good. However, most parameter descriptions are minimal (e.g., 'Volume level (0-100)' for audio_set_volume, 'Panel name (e.g. settings)' for panel_open). No output schemas documented anywhere in the source. Error handling is present (errorReporting=true) but not visible in tool definitions. The app_launch tool accepts 'cmd' with a constraint 'no arguments allowed' but this is buried in the description rather than enforced via schema. calendar_add requires date/time/title but lacks format validation hints in descriptions. No evidence of idempotency declarations, confirmation patterns for destructive ops, or recovery guidance in error messages.

• Add output schemas to all tools. Document what fields are returned (e.g., audio_get_volume returns {volume: integer, unit: string}). This enables LLMs to chain calls and extract required data.
• Expand parameter descriptions to 50-150 characters. Include WHEN to use the tool and WHAT happens on success. E.g., 'Set the system volume level (0-100). Returns the new volume. Use this to adjust audio before playing media.'
• Add JSON Schema pattern constraints for date/time parameters in calendar_add. Use 'pattern': '^\d{4}-\d{2}-\d{2}$' for dates and 'pattern': '^\d{2}:\d{2}$' for times.
• Document error cases and recovery paths in tool descriptions. E.g., 'If app_launch fails with 'not found', the application is not in the allowed list. Call app_launch with a different app name or check the system app menu.'
• Add destructiveHint/readOnlyHint annotations to tool definitions. Mark audio_set_volume, theme_set, calendar_add, app_launch, and panel_open as destructive (they modify state); mark audio_get_volume, theme_get as readOnly.