All 5 tools have basic descriptions and parameter schemas, but quality is inconsistent. Tool names follow verb_noun convention (search_*, plan_*, get_). However, descriptions lack actionable detail for LLM selection, they state WHAT but not WHEN or WHY to use each tool. Parameters have types and basic descriptions, but lack constraints (enums, ranges, patterns). No output schemas documented. Error handling is absent, the query_tripgenie() function returns raw strings on failure with no recovery guidance. The server delegates all logic to an external TripGenie API, making it a thin wrapper that doesn't validate inputs or structure responses.

• Add output schema documentation for each tool. Define the structure returned (e.g. list of hotels with fields: name, price_per_night, rating, features, booking_url). Use JSON Schema in tool registration.
• Implement structured error handling: catch API failures and return {"error": "<category>", "message": "<actionable guidance>", "retry": true/false}. E.g. 'API timeout. Retry in 30 seconds.' or 'Invalid city name. Try search_attractions(city="Beijing") instead.'
• Convert free-form parameters to enums: budget → ["budget", "mid-range", "luxury"]; cabin → ["economy", "business", "first"]; trip_type → ["one way", "round trip"]. Add min/max constraints: days 1 - 365, guests 1 - 20, travelers 1 - 20.
• Enhance descriptions with WHEN/WHY context. E.g. 'Use search_hotels for accommodation lookup. Use plan_itinerary if you need a complete multi-day plan including hotels, attractions, and dining.' Add dependency hints: 'Call search_attractions first to identify must-see sites, then use plan_itinerary to build a day-by-day schedule.'
• Remove hardcoded PROXY_TOKEN. Require PROXY_TOKEN environment variable with no fallback. Validate it is set at server startup. Never log or return tokens in responses.