This MCP server has three tools with critical structural and documentation deficiencies. Tool definitions are difficult to locate in test files rather than service implementations, and descriptions range from absent to minimal. Input parameters lack proper schema definitions with type constraints. No output schemas are documented. Tool names follow verb_noun convention, but definitions are underdeveloped for production use.

• Move tool definitions from test files (McpTestSse.java, McpTestStdio.java) to production service classes with explicit @Tool annotations, full JSON Schema input definitions, and documented return types.
• For getWeatherForecastByLocation: Add schema with latitude/longitude as numbers with min/max bounds (e.g., latitude -90 to 90, longitude -180 to 180), and document return structure (temperature, forecast array, last_updated, etc.).
• For getAlerts: Define 'state' as an enum of valid US state abbreviations or full names. Document return structure (alert list with id, title, description, severity, issued_at).
• For getToolContext: Either remove this tool (it returns a hardcoded directory unrelated to actual tool context) or rewrite to document what MCP context information it actually exposes and why an agent would call it.
• Expand all descriptions to 100 - 200 characters, explaining WHAT each tool does, WHEN to use it (e.g., 'Call this before planning weather-dependent activities'), and any prerequisites.
• Add per-parameter descriptions with format constraints: 'latitude (number, -90 to 90)' and 'state (string, e.g., CA, Texas; must be valid US state)'.
• Implement error handling that returns structured errors with recovery guidance, e.g., 'Invalid latitude: -95. Must be between -90 and 90.'
• Add limit/pagination parameters to getAlerts if it can return many results, and document the default/max in the description.