16 tools with consistent verb-noun naming (recommend_, diagnose_, list_, get_, search_). All tools have descriptions (avg ~80 chars, within baseline 34-392). Input schemas present with type definitions and enums where appropriate. However, output schemas are not documented in the source code, critical for LLM planning. No error handling guidance visible. Tools are read-only (low risk), but lack recovery patterns and actionable error messages. Composition is sound: tools chain logically (search_patterns → get_pattern → get_relations). No security concerns (no credentials, no state mutation). Descriptions are functional but terse; could be richer with WHEN/WHY context.

• Document output schemas for all tools. Specify field names, types, and whether results are paginated. Example: 'Returns {patterns: [{number, name, slug, part}], total: number}'.
• Enrich descriptions with WHEN/WHY context. E.g., 'Get full content of a design principle (1-17). Use this after search_design() to read the complete principle, or after recommend_design() to understand a recommendation.'
• Add error recovery hints to tools that accept IDs (get_pattern, get_capability, get_design_principle). E.g., 'If pattern not found, try search_patterns() with a keyword.'
• For optional parameters, document the default behavior. E.g., 'section: Optional. If omitted, returns all sections. If specified, returns only that section.'
• Add limit/offset or cursor pagination to list_capabilities and list_patterns to handle large result sets gracefully.