Server has 12 tools with consistent naming (verb_noun pattern: spartan_list, spartan_search, spartan_view, etc.). All tools have descriptions (avg ~80 chars, within baseline). Input schemas are present and typed with Zod. However, descriptions are terse and lack LLM-optimization guidance (e.g., 'when to use', 'prerequisites'). Parameter descriptions exist but are minimal (avg ~40 chars vs baseline 72). Output schemas are not documented, LLMs cannot infer what fields to expect from responses. Error handling wraps Zod and SpartanError but lacks recovery guidance ('try X instead'). No tool annotations (readOnlyHint/destructiveHint) despite clear read/write distinction. Composition is sound (each tool has one responsibility), but chaining IDs are not documented in responses.

• Document output schemas for all tools. E.g., spartan_list should return {items: [{name, category, description}], total: number}. Include this in tool descriptions or a separate schema field.
• Enhance descriptions with LLM-optimization: add 'When to use', 'Prerequisites', and 'Next steps'. E.g., 'spartan_search: Find components by keyword. Use this before spartan_view to get details. Returns component names and categories.'
• Add tool annotations: mark spartan_cache_clear, spartan_registry_refresh, spartan_install_skill with destructiveHint=true; mark all read-only tools with readOnlyHint=true.
• Improve error messages with recovery guidance. In wrapHandler, catch SpartanError and append 'Try: spartan_list() to see available components' or similar context-aware suggestions.
• Expand parameter descriptions to 60-100 chars. E.g., 'scope' → 'Limit search to: components (UI elements), blocks (layout templates), docs (guides), or all (default). Use components for UI discovery, blocks for layout patterns.'
• Document pagination for list/search tools. If spartan_list or spartan_search return large result sets, add limit and offset/cursor parameters and document max results (e.g., 'Returns up to 50 items; use limit to reduce.').