Loading ToolBench
A Spring Boot-based MCP server that provides weather forecasting and alerts through the National Weather Service API
This MCP server has 2 tools with basic definitions but significant quality gaps. Both tools have verb-noun names (getWeatherForcastByLocation, getAlerts) following action conventions, and both include minimal descriptions and input schemas. However, the descriptions are extremely sparse (14-16 characters), parameter descriptions are missing entirely, output schemas are undocumented, and there is no error handling guidance. The tool names contain spelling errors ('Forcast' instead of 'Forecast'). Tool definitions are visible in WeatherService.java, but parameter schemas lack descriptions and output structure is not documented. These are read-only tools (low risk), but the implementation falls short of production quality baselines.
Get weather alerts for a US state
Get the weather forecast for a given latitude and longitude
Tool descriptions are critically short (14-16 characters) and below the 20-character minimum threshold. 'Get the weather forecast for a given latitude and longitude' is too terse to guide LLM tool selection.
Parameter descriptions are completely missing. The 'latitude', 'longitude', and 'state' parameters have only type and no explanatory text. LLMs cannot infer parameter semantics from names alone, 'state' could mean US state code, application state, or status. Every parameter requires a description per the rubric.
Output schemas are not documented anywhere in the source code. There is no documentation of what fields the tools return, their types, or structure. Without a documented return type, LLMs cannot plan downstream tool calls or extract needed data.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 26 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 37 | - | v1 |
Tool name contains a spelling error: 'getWeatherForcastByLocation' should be 'getWeatherForecastByLocation'. Misspellings undermine clarity and may confuse LLMs or client integrations.
No error handling or recovery guidance. If an invalid latitude/longitude is passed, or no alerts exist for a state, the tools provide no actionable error messages to guide the LLM's next step.
No parameter constraints documented. For 'latitude' and 'longitude', valid ranges are -90 to 90 and -180 to 180 respectively. For 'state', the constraint is a 2-letter US state code, but this is only mentioned in passing in the description, not as a formal constraint or enum. The rubric requires format/range documentation.
No pagination or result limits documented. If getWeatherForcastByLocation returns time-series forecast data for multiple days/hours, there is no indication of how many results are returned, whether pagination is supported, or what the limit is. Per the rubric, tools returning lists must accept limit/page parameters.