Single tool with critical definition gaps. read_airtable_winds has a generic description (67 chars) that lacks WHEN to use it, WHAT it returns structurally, and any prerequisites. No parameter descriptions exist (N/A due to empty schema). Tool name lacks clarity on scope, does it read all records, filter by date, or support pagination? No error handling guidance. Naming is acceptable (verb_noun: read_airtable), but the implementation is severely underspecified for LLM use.

• Add input parameters: 'view' (optional string, Airtable view name), 'max_records' (optional int, 1-1000, default 100), 'offset' (optional string, pagination cursor). Document each with type, range, and purpose.
• Expand description to 150-250 chars: 'Fetch records from the configured Airtable table. Returns up to max_records records with pagination support. Use this to retrieve wind data for analysis or filtering. Requires AIRTABLE_BASE_ID, AIRTABLE_TABLE_ID, and AIRTABLE_TOKEN environment variables.'
• Document output schema: 'Returns a list of record objects, each with fields: id (string), fields (object with user-defined columns), createdTime (ISO 8601 string). Example fields depend on your Airtable schema.'
• Implement result capping and pagination: accept 'limit' param (default 20, max 100), return 'offset' in response for next call. Prevents context window exhaustion.
• Add error handling: catch requests.HTTPError and return structured error with recovery hint, e.g., 'Airtable API returned 401 Unauthorized. Verify AIRTABLE_TOKEN is valid and has data.records:read scope.'

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

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