Server has 8 tools with complete Zod schemas and descriptions in Turkish. Naming follows verb_noun pattern (lighthouse_analyze, check_metadata, etc.). Descriptions are present (avg ~150 chars) but lack LLM-optimized structure: they don't clearly state WHEN to use each tool vs. alternatives, or what the output contains. Parameters are typed with enums where appropriate (device, categories, pageType), but descriptions are minimal (avg ~40 chars) and don't explain constraints or dependencies. No output schemas documented, LLMs cannot predict response structure. Error handling exists but is generic ('Lighthouse analizi başarısız oldu') without recovery guidance. Tool composition is reasonable (8 focused tools), but several tools operate on similar concerns (check_* family) without clear differentiation.

• Document output schemas for all tools. E.g., lighthouse_analyze returns {scores: {performance, seo, accessibility, best_practices}, recommendations: [{title, description, severity}]}. This enables LLMs to plan downstream actions and extract data reliably.
• Expand parameter descriptions to 50-100 chars each. Include constraints, defaults, and examples. E.g., 'categories: Array of audit categories to run. Defaults to all if omitted. Valid: performance, accessibility, best-practices, seo.'
• Add WHEN-to-use guidance to tool descriptions. Clarify the distinction between check_component_quality (code metrics), nextjs_code_review (SEO/perf issues), and check_accessibility (a11y only). Help LLMs pick the right tool.
• Implement error categorization and recovery guidance. Distinguish retryable errors (network timeout → retry with backoff) from user-fixable (invalid URL → ask user for valid URL) from fatal (Chrome not installed → inform user). Return actionable next steps.
• Add pagination support and result limits. Cap recommendation lists at 20-50 items; offer limit and offset parameters. Document in tool descriptions: 'Returns up to 20 recommendations. Use limit and offset for pagination.'