Loading ToolBench
MCP server that provides weather alerts and forecasts using the National Weather Service (NWS) API
Two tools with basic schemas and descriptions, but significant gaps in parameter documentation and output structure. Both tools have verb-noun naming (get-alerts, get-forecast) which is correct. Descriptions exist but are minimal (18-27 chars, below the 50-200 char LLM-optimized baseline). Input schemas use Zod with type constraints (latitude/longitude bounds, state length), but lack detailed parameter descriptions beyond the constraint itself. No output schema documentation. Error handling returns text responses but lacks actionable recovery guidance. No tool annotations (readOnlyHint, etc.). Overall structure is functional but falls short of production quality.
Get weather alerts for a state
Get weather forecast for a location
Minimal tool descriptions (18-27 chars). LLM-optimized descriptions should be 50-200 chars and answer: what does it do, when to use it, what does it return. Current descriptions lack context for tool selection.
No output schema documentation. LLMs cannot plan downstream calls or extract data without knowing response structure. Both tools return text content but structure is undocumented.
Error responses lack actionable recovery guidance. Errors return plain text ('Failed to retrieve alerts data') without suggesting next steps or alternative tools. Should follow pattern:recovery-guide.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Both tools are read-only but lack explicit annotation. Agents cannot infer safety properties without annotations.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 47 | 2026-07-28+ | v2 |
Parameter descriptions are constraint-only, not LLM-optimized. 'Two-letter state code (e.g. CA, NY)' includes example values that LLMs may reuse literally. Should use enum or pattern constraint instead, and explain when/why to call the tool.