This server presents a mixed quality picture. While search_flights has a detailed input schema with nested objects and comprehensive field descriptions, it has structural issues: the descriptions are verbose (>1024 chars), parameter dependencies are underdocumented, and error handling guidance is missing. The two internal tools (submit_session, get_session_results) are explicitly marked [INTERNAL] but still exposed, creating confusion about intended usage. None of the tools include output schema documentation, making it impossible for LLMs to plan downstream actions. The server provides no tool annotations (readOnlyHint, destructiveHint, idempotentHint), no error classification, and no recovery guidance. Parameter naming is somewhat inconsistent: 'infantsInSeat' vs 'infantsOnLap' use camelCase while 'departureAirport' also uses camelCase, but this contrasts with snake_case conventions in the broader ecosystem. The fallback parsing logic in http-server.js reveals that the tool is fragile and depends on Gemini AI for natural language extraction, not robust for production use.

• Document the output schema for search_flights. Include: list of flights, each with airline, flightNumber, departureTime, arrivalTime, price, currency, bookingUrl. This enables LLMs to extract prices and pass URLs to users.
• Remove submit_session and get_session_results from public tool list, or combine them into search_flights with internal polling (which the tool appears to do already via submit_and_poll_session). Expose only the high-level search_flights tool.
• Shorten search_flights description to ~150 chars focusing on the WHAT and WHEN: 'Search and compare flight prices across multiple booking platforms. Provide flight details (airports, dates, times, airline) and get ranked results with prices from different sites.'
• Add explicit constraints for time parameters. Mark departureTime and arrivalTime as required if provided, or clarify: 'If departureTime is omitted, the search will match flights on the given date regardless of time.' Enumerations or pattern constraints are better than prose hints like 'ASK the user'.
• Add error recovery guidance in each tool description. Example for search_flights: 'If no results found, try: (1) expanding the date range, (2) using nearby airports, (3) reducing passenger count. Returns empty list if no flights match criteria.'
• Add tool annotations in the MCP protocol layer (when registering tools). Example: {name: 'search_flights', inputSchema: {...}, description: '...', readOnlyHint: true}. This signals to MCP clients that the tool is safe to call without confirmation.