Loading ToolBench
An MCP server implementation using HTTP Streamable transport for weather data, providing real-time weather alerts and forecasts via the National Weather Service API
This MCP server defines 4 weather tools across TypeScript and Python examples. While schemas and basic descriptions are present, there are significant gaps in parameter documentation, naming consistency, output schema documentation, and error handling. The tools are simple READ_ONLY operations, but lack the depth expected of production-grade agent tools. Average tool score: 52/100.
Get weather alerts for a state
Get weather forecast for a location
Get weather alerts for a US state.
Get weather forecast for a location.
No output schemas documented for any tool. LLMs cannot predict response structure, plan chained calls, or extract correct fields. Formatters exist server-side (formatAlert, ForecastPeriod interface) but are invisible to clients.
Inconsistent naming across TypeScript and Python implementations (get-alerts vs get_alerts, get-forecast vs get_forecast). Agents treat these as separate tools and cannot recognize they are duplicates. Should use one canonical name (recommend snake_case for all MCP tools).
Parameter descriptions lack constraint details. Latitude/longitude parameters have no min/max bounds documented. State parameter has no enum or regex pattern. Description text mentions 'Two-letter state code (e.g. CA, NY)' but examples in descriptions are discouraged, use formal constraints instead.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 54 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 44 | - | v1 |
Tool descriptions are below recommended minimum (50-200 chars). 'Get weather alerts for a state' (35 chars) and 'Get weather forecast for a location' (40 chars) lack context on when to use each tool, what data is returned, or dependencies. LLMs cannot discriminate intent from these sparse descriptions.
No error handling documented. Code catches errors and returns null (makeNWSRequest), but tools do not declare how LLMs should respond to failures (e.g., invalid state code, unreachable API, malformed coordinates). No recovery guidance provided.
No pagination or result limits documented. Alerts query could return hundreds of features; code does not show limit enforcement or pagination. If alerts list is large, response will blow context window. Pattern requires explicit limits and pagination parameters.
State parameter accepts free-form string with no validation. LLM can pass 'california' instead of 'CA', or typos like 'NY1'. Should declare state parameter as enum with all 50 US state codes, or add validation with clear error messages.