Three well-named, read-only tools with complete input schemas and solid descriptions (150 - 200 chars each). All parameters are typed and described. Tool names follow verb_noun pattern (search_, get_, count_). Schemas use proper JSON Schema with type declarations. However, output schemas are not documented, LLMs cannot predict response structure. Error handling returns generic error objects without recovery guidance. No parameter constraints (enums, ranges) despite opportunities (e.g., order_by should be an enum). Missing per-parameter validation rules in descriptions.

• Document output schemas for all three tools. For search_earthquakes, specify: returns {earthquakes: [{id, magnitude, magType, place, time (ISO 8601), longitude, latitude, depth_km, felt_reports, tsunami_flag, significance, url, type}], count: number}. For get_earthquake, document all returned fields and their types.
• Convert order_by to an enum: {type: 'string', enum: ['time', 'magnitude', 'time-asc', 'magnitude-asc'], description: '...'}. This prevents hallucinated values and makes the tool self-documenting.
• Add range constraints to numeric parameter descriptions. E.g., 'limit: Max events to return (1 - 100, default 20).' and 'latitude: Center latitude for circular search (-90 to 90).'
• Enhance error responses with recovery guidance. Instead of {error: 'USGS: 400 ...'}, return {error: 'Invalid time range or magnitude filter. Verify start_time < end_time and min_magnitude <= max_magnitude. See USGS FDSNWS docs for valid ranges.'}
• Add pagination support to search_earthquakes: include offset/limit parameters and return {earthquakes: [...], total_count: number, has_more: boolean} so agents can iterate over large result sets.