Two tools with basic schemas and descriptions, but significant gaps in parameter documentation and output structure. query_data lacks input validation guidance and error recovery hints. get_current_weather has minimal description (89 chars, below 194-char baseline). Neither tool documents output schema or pagination. No tool annotations (readOnlyHint, idempotentHint). Parameter descriptions are present but sparse. Error handling is not visible in tool definitions. Overall structure is minimal for production use.

• Add explicit output schema documentation to both tools. For query_data: 'Returns CSV-formatted string with headers and rows. Example: "id, name\n1, Alice\n2, Bob". Max 1000 rows.' For get_current_weather: 'Returns JSON object with {location, temperature_c, condition, humidity_percent, wind_kmh}.'
• Expand get_current_weather description to 150 - 200 chars: 'Gets current weather for a location by geocoding the name to coordinates, then fetching live conditions. Returns temperature, humidity, wind, and condition. Fails if location is ambiguous or unreachable.'
• Add constraint guidance to query_data parameter: 'The SELECT SQL query to execute. Only SELECT statements allowed (read-only transaction enforced). Results limited to 1000 rows. Timeout: 30 seconds. Syntax errors return the database error message.'
• Declare tool annotations in the tool definition: readOnlyHint=true and idempotentHint=true for both tools. This signals to LLMs that these calls are safe to retry and do not modify state.
• Add error recovery hints to descriptions: query_data should mention 'If query fails, check SQL syntax and table names via schema discovery'; get_current_weather should mention 'If location not found, try a broader city name or country code (e.g., "London, UK").'.

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

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