Six tools with consistent naming (verb_noun pattern: get_*) and adequate descriptions (120-180 chars each). All tools are READ_ONLY and properly documented. However, input schemas are minimal, only a single optional 'plan_id' parameter with basic description. No output schemas documented. Descriptions lack WHEN/WHY guidance and dependency hints. No error handling guidance or recovery paths. Parameter descriptions are generic ('Optional flight plan ID') without format constraints or examples of valid IDs. Tools return formatted strings rather than structured objects, forcing LLMs to parse unstructured text.

• Convert all tool outputs from formatted strings to structured JSON objects. Return {flight_number, aircraft_icao, aircraft_reg, departure_icao, arrival_icao, distance_nm, cruise_fl, ete_minutes, block_minutes, passengers, trip_fuel_kg, takeoff_fuel_kg, plan_id, generated_utc} instead of a formatted string. This enables LLMs to extract specific fields without parsing.
• Add format constraints to plan_id parameter: 'Optional flight plan ID (numeric or alphanumeric string). If omitted, fetches the most recent dispatch for SIMBRIEF_PILOT_ID.'
• Add error handling guidance to all tool descriptions: 'Returns error if plan_id is invalid or API is unreachable. If plan not found, try omitting plan_id to fetch the latest dispatch.'
• Add tool annotations to FastMCP tool registration: use @mcp.tool(readOnlyHint=True) to declare all tools as read-only, enabling LLMs to reason about safety without parsing descriptions.
• Expand descriptions with WHEN/WHY context: 'Call this to get a quick overview (flight number, aircraft, route, times, fuel). Use get_fuel_plan for detailed fuel breakdown, get_weights for weight distribution, or get_weather for meteorological data.'