Server has 8 well-defined tools with explicit schemas and descriptions. Most tools follow verb_noun naming (extract_palette, build_palette_folder, score_accessibility). Schemas are comprehensive with proper type constraints (enums, min/max bounds). However, descriptions vary in quality, some are verbose (build_palette_folder at 300+ chars) while others lack actionable context. Parameter descriptions are present but inconsistent in depth. Output schemas are documented in code but not formally exposed in tool definitions. Error handling is minimal, no recovery guidance or categorization. No tool annotations (readOnlyHint/destructiveHint) despite clear risk profiles (build_palette_folder is WRITE, others READ_ONLY).

• Add tool annotations: mark build_palette_folder with destructiveHint=true (writes files), mark all others with readOnlyHint=true. This enables clients to warn users before executing.
• Rewrite descriptions to 50-150 chars with explicit WHEN/WHY context. E.g., 'Extract dominant colors from a single image using k-means or median-cut clustering. Use this for brand palettes or simple color analysis. For screenshots with app windows, use extract_app_palette instead.'
• Document output schemas in tool definitions. Add a 'returns' field or inline schema comment showing expected response structure (e.g., palette: [{hex, rgb, hsl, population, role}]).
• Add error recovery guidance. When image_url and image_path are both missing, return: 'Missing image source. Provide either image_url (HTTP URL) or image_path (local file path).'
• Explicitly document mutually exclusive parameters in descriptions: 'Provide either image_url or image_path, not both. If both are given, image_url takes precedence.'