27 tools with consistent naming (verb_noun pattern) and basic schemas, but critical gaps in descriptions and parameter documentation. Most tool descriptions are 50-150 chars (below the 194-char baseline for A+ tools). Parameter descriptions are sparse or missing entirely. No output schemas documented. Error handling is absent. Tool composition is reasonable (search → filter → detail pattern), but parameter relationships are undocumented. Example: search_flights returns search_id, which get_flight_details and filter_* tools require, this dependency is not stated in parameter descriptions. No tool has destructive/idempotent hints. Prompts are well-structured but tool definitions themselves lack LLM-optimization.

• Document output schemas for all tools. Example for search_flights: 'Returns {search_id: string, flights: [{airline: string, price: number, duration_minutes: number, departure_time: string, arrival_time: string}], total_results: number}'. This enables LLMs to plan filter and detail calls.
• Expand parameter descriptions to 50-150 chars with format/constraint hints. Example: 'search_id (string, 32-char hex): Unique identifier from search_flights. Required to retrieve or filter results. If invalid or expired, call search_flights again.'
• Add dependency hints to all filter_* and get_*_details tools. Example: 'search_id (required): First call search_flights or search_hotels to obtain this ID. Results are cached for 24 hours.'
• Implement error handling with recovery guidance. Example: 'If Vercel KV is unavailable, the tool returns {error: "cache_unavailable", recovery: "Call search_flights again to refresh results"}'. Document this in tool description.
• Add tool annotations to schema: set readOnlyHint=true for all tools (already marked READ_ONLY). This aligns with MCP 2026-07-28 spec and enables LLM safety reasoning.