Critical gaps across all dimensions. Tool descriptions are minimal (1-4 words, well below 20-char threshold). No input schemas visible in provided source, cannot verify parameter types, constraints, or descriptions. Tool names follow verb_noun pattern (positive), but lack context for LLM selection. No evidence of output schema documentation. Error handling and recovery guidance absent. 28 tools with identical structural deficiencies.

• Expand all tool descriptions to 50-200 characters. Include WHAT the tool does, WHEN to use it, and any prerequisites. Example: 'air_list_domains' → 'List all AI risk assessment domains available in your account. Use this to discover domain IDs before creating projects or running assessments.'
• Document input schemas for all tools in src/capabilities.ts. For each parameter, specify: type (string|number|boolean|enum), description (20+ chars), constraints (min/max, regex, enum values), and whether required. Example: 'domain_id: {type: string, description: "The unique identifier of the domain (e.g., GDPR-2024). Required.", pattern: "^[A-Z0-9-]+$"}'
• Document output schemas. For each tool, specify the response object structure with field types and descriptions. Example: 'air_list_domains returns {domains: [{id: string, name: string, created_at: ISO8601}], total: number, next_cursor?: string}'
• Add error handling guidance to write-operation tools (create_project, upload_document_*, submit_fact_answers, start_assessment, etc.). Include: error classification (retryable/user-fixable/fatal), actionable messages, and recovery steps. Example: 'If domain_id not found, call air_list_domains to discover valid IDs.'
• Rename 'air_search' to 'air_search_documents' or 'air_search_assessments' to clarify scope. Generic names waste LLM reasoning cycles and increase selection errors.