22 tools with consistent naming (verb_noun pattern: get_, list_, search_, etc.) and descriptions present for all. However, input schemas lack critical detail: most parameters have type and description, but output schemas are entirely undocumented. No error handling guidance, no pagination metadata (limit/offset/cursor), no per-tool risk annotations. Descriptions average ~120 chars (within baseline 194), but lack actionable constraints (enums, ranges, format specs). Tools like 'compose_page' and 'coherence_check' accept complex nested structures (sections array, HTML/CSS strings) with minimal schema documentation. No evidence of idempotency markers, confirmation patterns for destructive ops, or recovery guidance.

• Document output schema for every tool. Specify field names, types (string, number, array, object), and whether fields are always present or conditional. Use JSON Schema format in tool registration.
• Add pagination to list_* and search_* tools: accept 'limit' (1-100, default 20) and 'offset' or 'cursor' parameters; return 'total_count' and 'next_cursor' in response. Cap default results at 20-50 items.
• Convert free-form parameter descriptions to formal constraints: define valid folder names as an enum (e.g. ['animations', 'components', 'effects', ...]), specify limit range (1-100), add regex pattern for query strings if needed.
• Add error handling guidance: document what errors each tool can return (e.g. 'folder not found', 'no results', 'invalid palette name') and suggest recovery steps (e.g. 'Call list_categories to see valid folders').
• For complex tools (compose_page, coherence_check), provide example input payloads in the description or as a separate schema reference. Show the expected structure of 'sections' array and required vs optional fields.