All 7 tools have descriptions and basic naming, but critical gaps undermine quality. Input schemas are present but minimal, most parameters lack type constraints, enums, or validation guidance. Descriptions are domain-specific but generic for LLM selection (avg ~80 chars, below 194-char baseline). No output schemas documented. No error handling guidance. Parameters lack descriptions explaining format/constraints. No tool annotations (readOnlyHint present in metadata but not in schema). Composition is sound (each tool has one responsibility), but parameter design forces LLMs to guess at valid input formats.

• Add nested JSON Schema definitions for 'problem' and 'deliverable' objects. Document required fields (e.g., problem must include 'process', 'volume', 'owner', 'decision_type', 'latency', 'accuracy_target'). Use $ref to avoid duplication.
• Document output schemas for all tools. E.g., fde_recon returns {signals: {codebase_size: string, language_distribution: object, ...}, recommendations: string[]}. Include field types and descriptions.
• Add error handling guidance: 'If project_path is invalid, returns {error: 'path_not_found', suggestion: 'Verify path exists and is readable'}. Retryable: yes. User-fixable: yes.'
• Expand parameter descriptions with format/constraint guidance. E.g., 'problem_statement (string, 100-2000 chars): Natural language description of the business problem. Include context on current pain points and desired outcome.'
• Add tool selection guidance to descriptions. E.g., fde_recon: 'Call this FIRST to understand codebase structure before decomposing. Requires read access to project root.' fde_decompose: 'Call after fde_recon to structure the problem using the 6-Q framework.'