Four read-only tools with basic descriptions and partial schemas. Tool names follow verb_noun convention (search_*, get_*, list_) which is good. Descriptions exist but are brief (10-50 chars) and lack context on when to use each tool or what downstream actions they enable. Input schemas are present with type declarations, but parameter descriptions are minimal. No output schemas documented. No error handling guidance. Tools are well-scoped (single responsibility) but lack the depth needed for confident LLM selection and chaining.

• Expand tool descriptions to 80-150 chars. Example: 'search_components: Search for existing components by name. Call this BEFORE creating a new component to avoid duplicates. Returns component names and file paths. If found, use get_component_props to inspect its API.'
• Document output schemas for all tools. Example for search_components: 'Returns array of {name: string, filePath: string, exportType: string}'. For get_component_props: 'Returns {name, filePath, exportType, props: [{name, type, required, defaultValue?, variants?}]}'.
• Convert example values to enums. For list_tokens, define: type enum = ['color', 'dimension', 'fontFamily', 'fontSize', 'spacing', 'lineHeight', ...] based on actual token types in the system.
• Add error recovery guidance to parameter descriptions. Example for get_component_props: 'Exact component name. If unknown, call search_components() first with a partial name.'
• Add per-tool usage hints. Example for get_token: 'Use this to resolve a specific design token value before hardcoding colors, spacing, or typography in component code.'