Server has 10 tools with basic schemas and descriptions, but significant quality gaps. Most tool descriptions are present but generic (50-150 chars, below the 194-char baseline). Parameter descriptions exist but lack specificity on constraints, formats, and valid ranges. No documented output schemas visible. Error handling guidance is absent. Tool naming follows verb_noun convention but some names are vague ('guidance', 'project_context'). No evidence of idempotency markers, permission gates, or recovery guidance. STDIO transport caps protocol readiness at 50.

• Document output schemas for all tools. For task_pipeline, specify: {project_context: string, recommendations: string[], code_search_results: [{file: string, snippet: string, line_number: int}], ui_guidance: string}. For guidance, specify: {resources: [{name: string, type: string, content: string}], total_count: int}.
• Add constraint descriptions to all parameters. E.g., 'query (string, 1-500 chars): Search term for guidance resources. Use keywords like "error handling", "async patterns", or "testing". Partial matches supported.' Replace vague 'Search query for guidance resources' with actionable constraints.
• Split 'guidance' tool into 'search_guidance' (operation: search) and 'get_guidance' (operation: get, workflow, precode, verify, feedback). This follows the single-responsibility pattern and makes LLM tool selection clearer.
• Add error handling guidance to project_context: 'If file not found, try search operation with a keyword from the filename. If search returns no results, the file may not exist in this project.' Similar guidance for guidance and session_continuity.
• Add idempotency and confirmation hints to write tools. For session_continuity save: 'Idempotent, calling twice with same state produces same result. No confirmation needed.' For workflow_gate set_stage: 'Non-idempotent, sets stage once. Confirm user intent before calling.'