Four well-defined tools with complete input schemas and clear descriptions. Tool names follow verb_noun convention (current_by_*, forecast_by_*, observations_in_*). All parameters have type definitions and descriptions. Descriptions are substantive (100 - 200 chars), explaining WHAT the tool does and WHEN to use it. Output schemas are documented in code (normalizeObservation function). However, no output schema is formally declared in the tool definitions themselves, LLMs cannot see what fields to expect. Error handling is present but minimal (no recovery guidance). No enum constraints on data_type parameter. Missing parameter validation rules (e.g., ZIP code format, bbox format, date format). No idempotency hints or destructive operation markers.

• Add explicit output schema declarations to each tool definition. Include fields like date, aqi, category, reporting_area, latitude, longitude with types and descriptions so LLMs know what to expect.
• Add enum constraint to observations_in_bbox data_type parameter: {"enum": ["A", "C", "B"]} to prevent invalid values.
• Document parameter validation rules in descriptions: 'zip_code must be a 5-digit US ZIP code (e.g., 94103)', 'bbox format: minLon,minLat,maxLon,maxLat (e.g., -122.5,37.7,-122.3,37.8)', 'date must be YYYY-MM-DD (e.g., 2024-01-15)'.
• Enhance error messages with recovery guidance: 'AirNow: unauthorized, check the API key or contact the operator for platform credentials' and 'AirNow: rate-limit (HTTP 429), free tier is 500/hour; retry after 60 seconds'.
• Move API key from tool parameter to server-side environment variable (AIRNOW_API_KEY). Inject it in callTool() without exposing it as a parameter, preventing credential leakage in logs and traces.