Three tools with complete schemas and descriptions, but significant gaps in parameter documentation and error handling. plan_trip_async has a comprehensive schema (16 params, all typed and described), but wait_for_plan_result and get_plan_result are minimal. Descriptions are adequate (100-200 chars) but lack actionable error guidance. No tool annotations (readOnlyHint, idempotentHint). Parameter descriptions are present but some lack constraints (e.g., optimizer enum values not formally constrained, timezone_offset range not specified). Output schemas are not documented, LLMs cannot predict response structure for downstream chaining.

• Document output schemas for all three tools. For plan_trip_async, specify: { routes: [{mode, duration_min, cost, distance_km, polyline, ...}], map_url: string, summary: {total_time, total_cost, total_distance, carbon_kg}, itinerary: [...] }. For wait_for_plan_result: { status: 'pending'|'done', plan_id: string }. For get_plan_result: { plan_id, routes, map_url, itinerary, summary }.
• Convert optimizer and evaluation parameters to formal JSON Schema enums: optimizer: enum=['ls', 'alns', 'de'], evaluation: enum=['znum', 'crisp']. Remove enum values from text descriptions.
• Add numeric constraints to plan_trip_async: timezone_offset (min=-12, max=14), start_hour (min=0, max=24), max_hours (min=0.5, max=24), budget (min=0), max_pois (min=1, max=50), timeout_seconds (min=1, max=300). Document in parameter descriptions.
• Add tool annotations to all three tools: readOnlyHint=true for all (they do not modify state). This signals to MCP clients that these tools are safe to retry without side effects.
• Enhance error descriptions with recovery paths. E.g., wait_for_plan_result: 'If status is pending after 10 retries, the computation may have failed. Call get_plan_result to check for error details, or restart with a new plan_id.'

Inferred effective spec: <=2025-11-25.

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