Three tools with strong naming conventions (get_rules, list_skills, get_skill) and generally clear descriptions. All tools have descriptions and basic parameter schemas using Zod. However, output schemas are not formally documented in the server registration, and parameter descriptions contain example values (a pattern violation). Tool composition is sound, each tool has a single responsibility and names follow verb_noun convention. The server properly validates inputs (max_results 1-20) and returns structured text responses.

• Remove example values from parameter descriptions. Replace 'Current file path (e.g. src/components/Button.tsx)' with formal constraints: 'Current file path (relative or absolute; .ts, .tsx, .js, .jsx files supported)'. Use parameter validation to enforce these rather than examples.
• Document output schema in tool registration. Define the response structure explicitly, e.g., for get_rules: {type: 'object', properties: {matched_rules: {type: 'array', items: {name, description, priority, content}}, total_count, returned_count}}. Return structured JSON in tool responses instead of plain markdown text.
• Add recovery guidance to error responses. When get_skill returns 'not found', include: 'Skill "X" not found. Use list_skills to see available skill names, or use get_rules to search by tags or file path.'
• Clarify parameter terminology. Change 'max_results' description from 'Max skills to return' to 'Max rules to return' to align with the tool's purpose (get_rules, not get_skills).
• Add tool distinctions. Enhance get_skill description to clarify: 'Fetch a single rule by exact name (useful when you already know the name). Use get_rules for context-aware search by file path or tags; use list_skills for a full inventory.'
• Implement idempotent-operation pattern. Document that these are all read-only, safe to retry, with no side effects, this is correct but should be explicit in each description.