feat(mcp): expose children and infant passenger counts

[etcook]

The MCP tool layer only surfaced a single passengers field and hardcoded PassengerInfo(adults=params.passengers), dropping the library's existing children, infants_in_seat, and infants_on_lap support. Families could not be priced correctly.

Add children, infants_in_seat, and infants_on_lap (all default 0) to FlightSearchParams and DateSearchParams, to the search_flights, search_dates, and get_booking_options tool signatures, and pass them through to both PassengerInfo construction sites. Adult-only callers are unaffected (new fields default to 0).

Add passenger-mix tests asserting the counts flow into the constructed filters for both flight and date search.

Greptile Summary

This PR exposes children, infants_in_seat, and infants_on_lap passenger counts through the MCP tool layer, fixing a gap where those fields existed in PassengerInfo but were never reachable from search_flights, search_dates, or get_booking_options. The new fields default to 0, keeping all existing adult-only callers unaffected.

• FlightSearchParams and DateSearchParams gain three new int fields with ge=0 constraints; both _build_flight_filters and _execute_date_search now forward them into PassengerInfo.
• All three MCP tool functions (search_flights, search_dates, get_booking_options) gain matching Annotated parameters that are wired into the params objects.
• New TestPassengerMix class covers flight-search and date-search passenger mix; get_booking_options shares the same _build_flight_filters code path but has no dedicated passenger-mix test."

Confidence Score: 4/5

The change is safe to merge; it adds opt-in fields that default to zero and threads them through two symmetric code paths that are both exercised by the new tests.

The wiring is correct and symmetric across all three tools. The only gap is that the get_booking_options passenger-mix path, while using the same _build_flight_filters function, has no dedicated test to catch a future accidental mismatch in how those parameters are passed into FlightSearchParams from that tool body.

No files require special attention, though a glance at the get_booking_options parameter-to-FlightSearchParams construction block (around line 1331) is worthwhile during final review.

Important Files Changed

Filename	Overview
fli/mcp/server.py	Adds children/infants_in_seat/infants_on_lap to FlightSearchParams, DateSearchParams, and all three MCP tool signatures; both PassengerInfo construction sites updated symmetrically.
tests/mcp/test_new_filters.py	Adds TestPassengerMix covering flight-search and date-search passenger propagation; get_booking_options passenger-mix path is exercised by the same _build_flight_filters code but has no dedicated test.

Sequence Diagram

sequenceDiagram
    participant Client as MCP Client
    participant Tool as MCP Tool
    participant Params as FlightSearchParams / DateSearchParams
    participant Builder as _build_flight_filters / _execute_date_search
    participant PI as PassengerInfo
    participant Search as SearchFlights / SearchDates

    Client->>Tool: adults, children, infants_in_seat, infants_on_lap
    Tool->>Params: construct with all 4 fields
    Params->>Builder: params object
    Builder->>PI: PassengerInfo(adults, children, infants_in_seat, infants_on_lap)
    Builder->>Search: FlightSearchFilters / DateSearchFilters with populated PassengerInfo
    Search-->>Client: flight results / date results

Loading

Prompt To Fix All With AI

Fix the following 1 code review issue. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 1
tests/mcp/test_new_filters.py:243-286
**Missing passenger-mix test for `get_booking_options`**

`get_booking_options` received the same three new parameters and wires them into `FlightSearchParams` before calling `_execute_booking_options` → `_build_flight_filters`. That path is logically identical to the one already tested, but because the tool function constructs a fresh `FlightSearchParams` itself (rather than delegating to `_search_flights_from_params`), a typo or accidental omission there would not be caught by the existing `TestPassengerMix` tests. Adding a `test_booking_options_passenger_mix` case using `_get_booking_options_from_params` (the test entry-point already defined at line 1361 of `server.py`) would close that gap.

_{Reviews (1): Last reviewed commit: "feat(mcp): expose children and infant pa..." | Re-trigger Greptile}

Greptile also left 1 inline comment on this PR.

[alexechoi]

This fills a real gap — PassengerInfo already supports these fields and the MCP layer just drops them. The wiring looks complete and symmetric across all three tools, and it's fully backwards-compatible. Two suggestions:

1. Ratio/total validation. Google Flights caps total passengers at 9 and requires infants_on_lap <= adults. Right now adults=1, infants_on_lap=3 builds cleanly and returns a silently wrong quote. A model_validator on PassengerInfo would keep the rule in one place and give MCP callers an actionable error instead of a bad price — which fits this PR's "families priced correctly" goal.

2. Coordination with feat: add Google Flights Explore (GetExploreDestinations) support #226. That PR adds a search_explore tool with a fourth PassengerInfo(adults=params.passengers) construction site. There's no textual conflict with this branch, but whichever lands second should cover the other's site — happy to add the children/infant params to search_explore as a follow-up so the tool surface stays consistent.

(FWIW the Greptile note about a missing booking-options test looks stale relative to the final diff — test_booking_options_passenger_mix is there.)