All 9 tools suffer from severely underdeveloped schemas and descriptions. Every tool accepts a single generic 'input' parameter (type: string, description: 'Input data (JSON)') with no structure, validation, or guidance. Descriptions are minimal (8-30 chars) and fail to explain WHAT the tool does, WHEN to use it, or what it returns. No output schemas are documented. Tools are thin wrappers around a remote API with no input validation, error recovery guidance, or parameter constraints. This violates core patterns: tool-description (descriptions too short), constrained-input (no enums/validation), response-shaper (no output schema), and recovery-guide (no error handling). The generic 'input' parameter forces LLMs to guess JSON structure, inviting malformed calls and silent failures.

• Replace generic 'input: string' with explicit, typed parameters. E.g., otts_calculator should accept {vehicle_type: enum, year: number, region: string, ...} with descriptions for each field. Document required vs optional fields.
• Expand tool descriptions to 100 - 200 chars. Example: 'otts_calculator: Calculate OTTS timeline and costs for vehicle homologation in EAEU. Requires vehicle type, year, and target region. Returns estimated timeline (days) and cost breakdown (USD).'
• Document output schemas in tool descriptions or as a separate schema field. E.g., 'Returns {timeline_days: number, cost_usd: number, breakdown: {...}, status: string}'. Enable LLMs to extract and chain results.
• Add error classification and recovery guidance. Catch API errors and return structured responses: {status: 'error', code: 'INVALID_VIN', message: 'VIN format invalid', suggestion: 'Provide a 17-character alphanumeric VIN'}. Guide LLM on retry vs user correction.
• Validate input JSON structure before calling remote API. Parse input string, check required fields, and return early with actionable errors. E.g., 'Missing required field: vehicle_type. Expected one of: truck, car, bus'.