MCP server providing weather and time information tools via HTTP/SSE transport
Two tools with basic verb-noun naming (get-weather, get-time) and minimal descriptions. Both have simple input schemas with a single 'city' parameter. Descriptions are present but generic (10-50 chars), below the 194-char baseline for production tools. No parameter descriptions provided, LLMs cannot infer what 'city' means without context. No output schemas documented. No error handling guidance. Tools are READ_ONLY but lack explicit risk annotations. Schemas are present but minimal; parameters lack descriptions, violating the 100% baseline for A+ tools.
tool to get the current time in a city
tool to get the current weather of a city
Parameter descriptions missing. 'city' parameter has no description explaining what it accepts (city name, code, coordinates?), violating the 100% baseline for A+ tools.
Tool descriptions are generic and under 50 chars. 'tool to get the current weather of a city' lacks context on when to use it vs alternatives, expected output format, or prerequisites. Baseline is 194 chars.
Output schemas not documented. LLMs cannot plan downstream calls or extract fields without knowing the response structure. No documentation of returned fields (temperature, condition, time format).
No error handling guidance. If a city is not found or the service fails, LLMs receive no recovery hints. Missing pattern: recovery-guide.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 44 | 2026-07-28+ | v2 |
Tool annotations missing. Risk is READ_ONLY but not declared via readOnlyHint in schema. Agents cannot infer safety without explicit annotations.