Loading ToolBench
MCP server for retrieving weather alerts and forecasts from the National Weather Service API
Two tools with basic verb-noun naming (get-alerts, get-forecast). Both have short descriptions (34-45 chars, below baseline 194 chars) that lack context on WHEN to use them or what they return. Input schemas are present with Zod validation and constraints (lat/lon bounds, state length), but descriptions are minimal. No output schema documented. Error handling returns plain text without recovery guidance. No tool annotations (readOnlyHint, etc.). Composition is sound (each tool does one thing), but descriptions are too terse for LLM selection and lack dependency hints.
Get weather alerts for a state
Get weather forecast for a location
Tool descriptions are too short (34-45 chars vs baseline 194 chars). 'Get weather alerts for a state' lacks WHEN to use it, what it returns, and prerequisites. LLMs cannot distinguish this from similar tools or plan multi-step workflows.
No output schema documented. Callers cannot predict response structure (text content, fields, pagination). LLMs must infer output format, risking parsing errors and wasted tokens.
Error responses are plain text without recovery guidance. 'Failed to retrieve alerts data' gives the LLM no actionable next step. Should indicate: is this retryable? Should the user provide different input? Is the service down?
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Both tools are read-only and idempotent, but this is not declared in the schema. Agents cannot optimize caching or retry logic.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 50 | 2026-07-28+ | v2 |
Parameter descriptions lack format guidance. 'Two-letter state code (e.g. CA, NY)' uses example values instead of formal constraints. Latitude/longitude descriptions omit use cases (e.g., 'Use decimal degrees for US locations only').