Four tools with complete schemas and reasonable descriptions. All tools are READ_ONLY and properly registered with Zod schemas. Naming follows verb_noun pattern (resolve_place, search_flights, search_stays, search_cars). Descriptions are 100-200 chars, within baseline range (p10=34, p90=392). However, parameter descriptions are sparse, many lack context about format, constraints, or dependencies. Output schemas are not documented. Error handling returns generic fail() wrapper without recovery guidance. No tool annotations (readOnlyHint, etc.) despite all being read-only.

• Document output schemas for each tool. E.g., resolve_place returns [{name, iata_code, city, type, latitude, longitude}]. search_flights returns [{price, airline, departure_time, arrival_time, stops}]. This enables LLMs to chain calls and extract required fields.
• Add format/constraint details to parameter descriptions. E.g., 'departure_date (YYYY-MM-DD, must be today or later)', 'radius_km (1-100, default 10)', 'driver_age (18-99, default 30)'. Use the description text since LLMs cannot parse JSON Schema pattern fields.
• Enhance error messages with recovery guidance. E.g., if origin IATA is invalid, return 'Invalid origin code. Call resolve_place("<user input>") first to get valid IATA codes.' This guides the agent to self-correct.
• Add readOnlyHint annotations to all four tools in registerTool() to signal they are safe to retry and have no side effects. This helps agents reason about error recovery.
• Document result limits in tool descriptions. E.g., 'Returns up to 6 place suggestions' for resolve_place. If search_flights/stays/cars return large sets, add pagination parameters (limit, offset) and document the default/max.
• Add dependency hints to descriptions. E.g., search_flights should say 'Use IATA codes from resolve_place()' (already present, good). search_stays/cars should say 'Use coordinates from resolve_place()' to guide multi-step planning.