Server has 13 tools with complete schemas and descriptions in Russian. All tools follow verb_noun naming (search_*, get_*, lookup_*). Descriptions are present and contextual (avg ~120 chars), exceeding the 10-char minimum. Input schemas use Zod with proper types, descriptions, and constraints (min/max, defaults, enums where applicable). However, output schemas are not documented, responses are wrapped as plain text without structured field definitions. Error handling is minimal (withErrorHandling wrapper exists but recovery guidance is absent). No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite all tools being read-only. Parameter descriptions are adequate but lack format/constraint details in some cases (e.g., date formats stated in description but not enforced via pattern). No pagination guidance for large result sets.

• Document output schemas for all tools. Specify which fields are returned (e.g., flight_id, price, airline, departure_time) with types and descriptions. This enables LLMs to extract and chain results.
• Add readOnlyHint: true to all tool definitions in server.tool() calls. This signals to clients that results are cacheable and safe to retry.
• Enhance error handling: catch API errors and return structured messages like 'Invalid IATA code: MOW not found. Try lookup_airports("Moscow") first.' instead of raw stack traces.
• Add JSON Schema pattern constraints for dates: use pattern: '^\d{4}-\d{2}(-\d{2})?$' for YYYY-MM-DD format validation at the schema level, not just description.
• Document result limits and pagination in tool descriptions. E.g., 'Returns up to 30 flights (limit parameter). For more results, use offset or next_cursor pagination.' Specify what fields enable chaining (e.g., flight_id for get_flight_details).

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

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