Four travel-domain tools with basic schemas and descriptions. All tools have input schemas with typed parameters and descriptions, meeting minimum requirements. However, descriptions are generic (50-80 chars) and lack actionable context for LLM selection. No output schemas documented. Parameter descriptions are minimal, e.g., 'Departure date in YYYY-MM-DD format' lacks guidance on valid ranges, constraints, or error recovery. No error handling guidance. Tools follow verb_noun naming (search_*) but lack composition hints (e.g., which tool to call first, how results chain). No pagination documented despite travel APIs typically returning large result sets. Security and audit patterns absent.

• Document output schemas for all tools. Specify fields returned (e.g., flight_id, airline, departure_time, price, availability) with types and descriptions. Enable agents to extract and chain results.
• Expand tool descriptions to 100-150 chars. Include WHEN to use (e.g., 'Use this to find individual flights; use search_holiday_packages for bundled flight+hotel deals'), what results contain, and any prerequisites (e.g., 'Requires valid IATA codes').
• Add pagination parameters (limit: 1-50, offset: 0+) and document result caps. Specify default limit (e.g., 20) and max results returned. State in description: 'Returns up to 20 results; use offset to paginate.'
• Enhance parameter descriptions with constraints and error recovery. E.g., 'Departure date in YYYY-MM-DD format, must be 1-365 days in future. If invalid, returns error with valid range.' Include examples of valid values (FRA, BCN for airport codes).
• Add tool composition guidance in descriptions. E.g., flight tool: 'Returns flight_id and price. Use with hotel__search_hotels for same destination/dates to compare bundled vs. separate bookings.' Clarify when to use holiday_package vs. separate searches.

Inferred effective spec: 2025-06-18+.

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