This is a minimal starter template with two weather tools. Both tools have names starting with action verbs (get_), basic descriptions, and input schemas with type constraints. However, descriptions are very brief (under 50 chars each), output schemas are completely undocumented, and there is no error handling guidance. The tools are read-only and simple, but lack the depth and LLM-optimization expected of production-grade definitions. Tool composition is appropriate (two separate tools), but parameter descriptions are minimal and do not guide the LLM on context or dependencies.
Get weather alerts for a state
Get weather forecast for a location
Tool descriptions are too brief (under 50 chars). LLMs need explicit guidance on WHAT the tool does, WHEN to use it, and WHAT it returns. Current descriptions lack context and dependency hints.
Output schemas are completely undocumented. Code shows tools call external NWS APIs and return formatted responses, but no schema is declared in tool registration. LLMs cannot plan downstream calls or extract fields without knowing response structure.
Parameter descriptions are minimal. The 'state' parameter for get-alerts has a basic description ('Two-letter state code'), but lacks guidance on what happens on invalid input or missing data. The 'latitude' and 'longitude' parameters are constrained by min/max, but descriptions do not explain the coordinate system or typical use cases.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 56 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 44 | - | v1 |
No error handling or recovery guidance. The makeNWSRequest utility catches errors and logs them, but tools do not return structured error responses telling the LLM what went wrong or what to do next. A failed API call just returns null with no actionable message.
No pagination support. get-alerts likely returns multiple weather alerts, but the tool offers no limit, offset, or cursor parameters. A state with many active alerts could return hundreds of results, blowing the context window.
Tool descriptions do not state whether operations are read-only or idempotent. While the code only reads external APIs, the descriptions should explicitly say 'This is a read-only operation' so the LLM knows it is safe to retry.