Loading ToolBench
Weather MCP Server that provides weather alerts and forecasts using the National Weather Service API
Two tools with basic schemas and descriptions, but significant quality gaps. Both tools have input schemas with proper types and constraints (latitude/longitude ranges, state length), and descriptions are present but brief (18-27 chars). Descriptions lack context on WHEN to use each tool, what they return, and any prerequisites. No output schemas documented. Parameter descriptions are minimal. Typo in get-forecast description ('weathre foreacast'). No error handling guidance. No tool annotations. Composition is reasonable (two distinct tools), but descriptions fall short of LLM-optimization baselines (target 50-200 chars; these are 18-27).
Get weather alerts for a state
Get weathre foreacast for a location
Tool descriptions are too brief (18-27 chars) and lack context. 'Get weather alerts for a state' does not explain WHEN to use this tool, what data it returns, or how it differs from get-forecast. LLMs need 50-200 char descriptions with WHAT, WHEN, and WHAT-IT-RETURNS.
No output schemas documented. Callers cannot know what fields to expect (e.g., does get-forecast return temperature, wind, precipitation?). LLMs need structured output definitions to plan downstream calls.
No error handling guidance. If NWS API fails or location is unsupported, the tool returns a text message but does not tell the LLM whether to retry, ask the user, or give up. Missing recovery hints.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 55 | 2026-07-28+ | v2 |
Typo in get-forecast description: 'weathre foreacast' should be 'weather forecast'. Also, description does not mention that only US locations are supported (this is only in error text).
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Both tools are read-only and idempotent, but this is not declared in the schema. Clients cannot infer safety properties.