Single tool 'getWeather' has critical definition gaps. Description is minimal (28 chars, below 20-char floor). Input schema present but parameter 'city' lacks description (null value visible in schema). No output schema documented. No error handling guidance. Tool does not follow LLM-optimized description pattern (should be 50-200 chars explaining WHAT, WHEN, and WHAT IT RETURNS). No parameter constraints (e.g., city format, length limits). Naming is acceptable (verb_noun pattern), but overall definition quality is poor.
Get weather data for a city
Must expand to 50-200 chars explaining WHAT the tool does, WHEN to use it, and WHAT it returns.
Parameter 'city' has null description in schema. Every parameter must have a non-empty description explaining what it controls, expected format, and constraints (e.g., 'City name (e.g., New York, London). Max 100 chars.').
No output schema documented. LLMs cannot plan downstream calls or extract data without knowing response structure. Document: returns object with 'content' array containing 'type' and 'text' fields, plus optional 'isError' flag.
No error handling guidance. When API key is missing or city not found, errors return generic messages ('Failed to fetch weather data'). Should return actionable errors: 'WEATHER_API_KEY not configured. Contact admin.' or 'City not found. Try a different spelling or nearby city.'
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 42 | 2026-07-28+ | v2 |
No input validation or constraints. Parameter 'city' accepts any string. Should document: max length, character restrictions, and whether special characters/numbers are allowed. Prevents LLM from passing invalid values.