The MCP server defines 5 tools with reasonable structure, but has notable gaps in description quality, parameter documentation, and error handling guidance. Tool names follow verb-noun convention well (add-design-pattern, get-file-design-pattern, review-code-change, validate-architect). However, descriptions vary significantly in clarity and actionability. Parameters are typed with JSON Schema, but many lack sufficient detail on constraints, formats, and valid ranges. Output schemas are not explicitly documented for any tool. Error handling and recovery guidance is minimal. The server uses current MCP SDK (1.29.0) but is STDIO-only, which is a hard transport limitation.

• Document the output schema for each tool explicitly. For example, get-file-design-pattern should specify: 'Returns {patterns: [{name: string, status: "compliant"|"violation", guidance: string}], summary: string}' (or actual structure). This enables LLM planning.
• Differentiate get-file-design-pattern and review-code-change more clearly. Add to each description: 'get-file-design-pattern checks style/structure against design patterns; review-code-change enforces coding rules and standards.' Specify which tool to call for each use case.
• Add format constraints to file_path parameters. Example: 'Relative or absolute file path (e.g., "src/components/Button.tsx"). Relative paths are resolved from workspace root. Supported extensions: .ts, .tsx, .js, .jsx.'
• Document error scenarios and recovery guidance. Example for validate-architect: 'If architect.yaml is invalid, returns errors array with: {line: number, column: number, message: string, fix: string}. If file not found, returns {error: "File not found", searchPath: string}. If both file_path and template_name provided, returns {error: "Provide exactly one of file_path or template_name"}'.
• Clarify the semantic difference between add-design-pattern and add_rule in their descriptions. Example: 'add-design-pattern groups files by structural intent (e.g., component hierarchy). add_rule enforces coding standards (e.g., must use barrel exports). Use add-design-pattern first to define structure, then add_rule to enforce compliance.'
• Use JSON Schema 'oneOf' in validate-architect to enforce mutual exclusivity: 'oneOf: [{required: ["file_path"]}, {required: ["template_name"]}]' instead of relying on description.

Inferred effective spec: <=2025-11-25.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry