Four tools with basic descriptions and Zod schemas, but significant gaps in parameter documentation and output structure. All tools are READ_ONLY and lack error handling guidance. Descriptions are present (avg ~100 chars) but lack actionable context for LLM selection. Parameter descriptions exist but are minimal. No output schemas documented. Tool names follow verb_noun pattern correctly. Telemetry logging present but not part of MCP spec.

• Document output schemas for all tools. Define the structure of returned data (e.g., get_component_patterns returns {components: [{name, file, patterns, examples}], total_count}). Use JSON Schema or TypeScript interfaces visible in code.
• Add enum constraints to issueType parameter in get_fix_history. Replace 'Filter by issue type (e.g., image-alt, button-name)' with explicit enum: ['image-alt', 'button-name', 'color-contrast', 'keyboard-navigation', 'focus-management']. This prevents hallucinated values.
• Enhance error responses with recovery guidance. When no patterns found, return: 'No ARIA patterns detected. Ensure components are in src/components or use React/Vue. Try specifying a component name or directory.' This guides LLM to self-correct.
• Add pagination to get_component_patterns and get_design_tokens. Accept limit (default 20, max 100) and offset parameters. Return {results: [...], total_count, has_more}. This prevents context window exhaustion on large codebases.
• Add optional parameters to get_scan_summary: issue_type (enum), severity (enum: critical|high|medium|low), limit (1-100). This enables scoped queries instead of always returning the full summary.