Four tools with basic schemas and descriptions, but significant quality gaps. All tools have input schemas with type definitions and descriptions present, meeting minimum requirements. However, descriptions are terse (10-50 chars), parameter descriptions lack context and constraints, and output schemas are undocumented. No error handling guidance, no pagination support for list-like operations, and no tool annotations. The 'get_random' tool description is flippant ('trust me') rather than professional. Tools are read-only but lack explicit idempotent hints. Naming is acceptable (verb_noun pattern) but lacks clarity on when to use similar tools (e.g., get_alerts vs get_forecast).

• Expand tool descriptions to 50-150 characters. Example: 'Get active weather alerts for a US state. Returns event type, severity, area, and instructions. Use when user asks about weather warnings or hazards.' This answers WHAT, WHEN, and WHY.
• Document output schemas explicitly. For get_alerts, specify: 'Returns a formatted string with alert details (event, area, severity, description, instructions) separated by dashes. Returns 'No active alerts' if none found.' For pow, specify: 'Returns a float representing a raised to power b.'
• Add parameter constraints to descriptions. Example: 'state: Two-letter US state code, uppercase (CA, NY, TX). Case-sensitive. Returns error if invalid.' For latitude/longitude: 'Latitude: -90 to +90 degrees. Longitude: -180 to +180 degrees.'
• Implement error classification and recovery guidance. Instead of 'Unable to fetch alerts', return: 'Failed to fetch alerts for state CA: NWS API timeout. Verify state code is valid (e.g., CA, NY) and try again.' This guides LLM retry logic.
• Add tool annotations (idempotentHint: true) to all read-only tools via FastMCP decorators. This signals to agents that these tools are safe to retry without side effects.