Server has 7 tools with mostly complete schemas and descriptions. Naming follows verb_noun pattern (get_, list_). Descriptions are present and reasonably detailed (100-300 chars typical). However, several parameters lack descriptions or have minimal guidance. Output schemas are not explicitly documented. Error handling is minimal, no recovery guidance or actionable error messages visible in tool definitions. Tool composition is sound (single responsibility), but parameter validation rules and constraints are underspecified.

• Document output schemas for all flight tools. Example: 'Returns {arrivals: [{flight_id, airline, status, actual_on}], departures: [...], num_pages: int, next_cursor: string|null}'. This enables LLM to extract and chain results.
• Formalize parameter constraints in descriptions. Replace 'max_pages 1 - 50' with 'max_pages: integer, minimum 1, maximum 50'. Replace 'max 32 chars' with 'airport_code: string, max length 32, pattern: [A-Z0-9]{1,4}'.
• Add error handling guidance. E.g., 'If airport_id is invalid, returns 404 with message. Try list_demo_airports() to find valid codes. If rate limited (429), retry after 60 seconds.'
• Clarify pagination. Document cursor format (opaque string), how to detect final page (next_cursor is null), and whether cursor expires. Example: 'cursor: optional string, opaque pagination token from previous response. Omit or pass null for first page.'
• Explicitly state mutually exclusive parameters. E.g., 'airline and category are mutually exclusive. If both provided, airline takes precedence. Omit category if airline is set.'

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

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