Single tool 'get_weather' has critical definition gaps. Description is present (47 chars, within range) but input schema is severely malformed. Parameters include non-standard fields ('tool_call_id', 'state', 'emit') that appear to be internal implementation details leaking into the tool interface. The 'location' parameter lacks explicit type declaration in the visible schema. No output schema is documented. The tool definition appears inferred from template code rather than explicitly registered via MCP protocol. No error handling guidance, no pagination, no structured output specification.

• Remove 'tool_call_id', 'state', and 'emit' from the input schema. These are internal framework details. Keep only 'location' as a user-facing parameter.
• Document the output schema explicitly: e.g., {temperature: number, unit: string, condition: string, humidity: number, forecast: array}. Include field descriptions.
• Expand the tool description to 100-150 chars: 'Get current weather for a location. Accepts city name (e.g., "San Francisco"), coordinates (lat,lon), or zip code. Returns temperature, condition, humidity, and 7-day forecast.'
• Add parameter description for 'location': 'The location to query. Accepts city name (e.g., "New York"), coordinates as "lat,lon" (e.g., "40.7128,-74.0060"), or US zip code (e.g., "10001").'
• Add error handling guidance in description: 'If location is ambiguous (e.g., "Springfield"), the tool returns available matches. If the API is unavailable, retry after 30 seconds.'

Inferred effective spec: 2025-06-18+.

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