The server defines two tools with complete Zod schemas and descriptions. Both tools have clear verb-based names and adequate parameter documentation. However, output schemas are not explicitly documented, and some descriptions lack depth about when to use each tool vs. the other. Parameter validation is present in schemas but error handling guidance is minimal.

• Document the return schema for both tools: specify that successful responses include a 'markdown' field (string), and error responses include 'error' field (string) with a specific error classification (e.g., 'invalid_syntax', 'github_api_error', 'timeout'). See pattern:response-shaper.
• Add error classification and recovery guidance. Wrap errors with: 'Error: <message>. Category: <retryable|user-fixable|fatal>. Next: <suggestion>.' For spec_to_diagrams, explicitly handle missing GITHUB_TOKEN: 'Error: GITHUB_TOKEN not set. Set GITHUB_TOKEN env var before calling this tool.'
• Enhance tool descriptions with mutual exclusivity guidance: 'Use encode_plantuml when you already have valid PlantUML source; use spec_to_diagrams when you have a plain-English spec and want diagrams auto-generated.' This helps LLMs pick the right tool.
• Add per-item error handling for spec_to_diagrams. If generating one of 4 requested diagrams fails, return the successful ones plus error details for the failed type, not a complete failure. This matches the 'lines.join' pattern already in the code.
• Document parameter dependencies: 'If format=svg but base_url points to a PNG-only server, encoding will fail.' Add validation with actionable errors.
• Consider adding a 'validation_mode' parameter to spec_to_diagrams: when true, return the spec→PlantUML mapping without encoding (cheaper, faster preview). This enables LLM confirmation before commit.

Inferred effective spec: 2026-07-28+.

• Relies on Stateful initialize / Mcp-Session-Id (removed; protocol is stateless) - make each request self-contained