ARIA has 17 tools with consistent naming (verb_noun pattern: get_*, list_*, analyze_*, generate_*, export_*, query_*, semantic_*, etc.) and basic parameter schemas. However, descriptions are generic and lack LLM-optimization guidance. Most tools have 1 - 4 parameters with type definitions, but parameter descriptions are minimal (often 1 - 2 sentences). Output schemas are not documented, LLMs cannot infer what fields to expect from responses. Error handling is absent from tool definitions. The server relies on a backend API (ARIA backend) for actual analysis, but tool definitions do not explain failure modes, recovery paths, or what data is returned. This is typical of community servers that expose API wrappers without LLM-specific refinement.

• Document output schemas for all 17 tools. Specify field names, types, and what each field represents. E.g., get_dead_code should return {dead_code_items: [{file: string, symbol: string, confidence: number}], total: number}.
• Convert informal enum descriptions to formal JSON Schema enums. E.g., get_impact_analysis.operating_mode should be {type: 'string', enum: ['SAFE', 'BALANCED', 'EXPLORATORY']} with description explaining each.
• Add min/max bounds to numeric parameters. E.g., semantic_search.top_k: {type: 'integer', minimum: 1, maximum: 100, default: 10}.
• Expand tool descriptions to 100 - 200 characters explaining WHEN to use each tool. E.g., 'query_codebase: Use for natural-language questions about code logic and intent (RAG-based). semantic_search: Use for finding code by structural similarity or keyword matching.'
• Add error handling guidance to tool descriptions. E.g., 'analyze_repository: Returns error if repo not found (try list_repositories first) or if analysis is already in progress (retry in 30s).' Include recovery paths for each failure mode.

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

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