Loading ToolBench
A Model Context Protocol server for retrieving weather alerts and forecasts from the US National Weather Service (NWS) API
The server defines 2 tools with explicit schemas and descriptions visible in main.go and model.go. Both tools follow verb_noun naming conventions (get alerts, get forecast). However, there are significant gaps in description quality, parameter annotations, and error handling guidance. Tool descriptions are brief (20-50 chars) and lack context about when/why to use them. Parameter descriptions in model.go use jsonschema tags but are minimal. Output schemas include both success and error fields, but error responses lack actionable recovery guidance. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite tools being read-only. The code shows basic validation but no comprehensive input constraint documentation. This server is functional but falls short of production-grade quality patterns.
Get weather alerts for a US state
Get weather forecast for a location.
Tool descriptions are too brief (under 50 chars) and lack actionable context. 'Get weather alerts for a US state' and 'Get weather forecast for a location.' do not explain WHEN to use these tools, prerequisites, or what the agent should do with results. Per pattern:tool-description, descriptions should be 50-200 chars with clear context for LLM selection.
Parameter descriptions in model.go are minimal tag values ('Two-letter US state code (e.g. CA, NY)', 'Latitude of the location (recommended: up to 4 decimal places)') but lack structured constraints and validation guidance. No explicit min/max for numeric params, no enum for state param. Per pattern:constrained-input, parameters accepting known sets of values should use enums; numeric params need min/max ranges.
Error responses in model.go (GetAlertsOutput.Error, GetForecastOutput.Error) are generic strings like 'Unable to fetch alerts.' and 'Invalid response format.' Per pattern:recovery-guide, errors must include what to do next and be categorized as retryable vs user-fixable. Current error messages give the LLM no actionable path forward.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 44 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 36 | - | v1 |
Output schema includes both 'alerts'/'forecast' (success field) and 'error' (error field) in the same struct, forcing the LLM to inspect both. Per pattern:response-shaper and best practices, success and error should be cleanly separated. Consider returning structured error objects with codes, messages, and recovery hints rather than free-text strings.
No tool annotations despite both tools being read-only. Per Spec Alignment (2026-07-28), tools should declare readOnlyHint, destructiveHint, and idempotentHint. The 'Risk: READ_ONLY' metadata in the server description is not exposed in the MCP tool definitions, so clients cannot see these semantics.
The 'state' parameter in get_alerts accepts any string but should be constrained to valid US state codes. Per pattern:constrained-input, parameters with known valid sets (50 US states) should declare enums. Currently, an LLM could pass 'XX' or 'invalid' without the tool rejecting it upfront.
Numeric parameters (latitude, longitude) in get_forecast lack min/max constraints in the schema. Per pattern:constrained-input and baseline guidance, numeric params should define range (e.g. latitude -90 to 90, longitude -180 to 180). Current description only mentions 'recommended: up to 4 decimal places', which is not a formal constraint.