Three tools with clear verb-noun naming (get_*) and reasonable descriptions (100-150 chars each). All tools have input schemas with typed parameters and descriptions. However, output schemas are completely undocumented, LLMs cannot predict what fields to expect from responses. Error handling returns strings rather than structured objects, making it difficult for agents to distinguish success from failure or determine retry strategy. No parameter constraints (enums, ranges) despite 'days' parameter accepting 1-5. Tool descriptions lack WHEN-to-use context and dependency hints. No mention of fallback behavior or caching markers in descriptions, forcing LLMs to infer from response text.

• Define output schemas for each tool. E.g., get_current_weather returns {temperature_f: number, feels_like_f: number, description: string, humidity: number, wind_speed_mph: number, pressure_hpa: number, visibility_m: number, city: string, country: string, cached: boolean}. Document in tool docstring or via JSON Schema.
• Replace string error responses with structured error objects: {error: string, code: 'not_found'|'timeout'|'invalid_input'|'server_error', recovery: string}. E.g., 'Invalid city' → {error: 'City not found', code: 'not_found', recovery: 'Try search_cities() or provide a valid city name'}.
• Add min/max constraints to 'days' parameter in schema: {type: 'integer', minimum: 1, maximum: 5, default: 3}. Update description to reference the constraint: 'Number of forecast days (1-5, default 3).'
• Expand tool descriptions to include WHEN-to-use context: 'Get current weather conditions (temperature, humidity, wind) for a city. Use this for immediate conditions; use get_weather_forecast for multi-day planning. Requires a valid city name.'
• Document caching and fallback behavior in descriptions or via tool annotations. Add readOnlyHint: true to all three tools. Consider adding a 'source' field to responses (mcp_server|fallback_api) so LLMs understand data provenance.