MCP server with weather data fetching capability, supporting both SSE and stdio transports
Critical failures across all dimensions. The server defines a single tool (getWeatherDataByCityName) twice with identical signatures, suggesting a copy-paste error or incomplete refactoring. Tool has a valid Zod schema (city: z.string()) but lacks any description whatsoever. Parameter 'city' has no description. Output is hardcoded JSON text with no documented schema. No error handling guidance, failures return {temp: null, error: '...'} as unstructured text. No input validation beyond type. Naming is acceptable (verb_noun pattern), but everything else fails baseline standards. Both STDIO and SSE implementations are identical in tool definition, indicating no transport-specific optimization.
Tool registered twice with identical name and signature. Indicates incomplete implementation or copy-paste error. Only one tool will be callable; the second registration silently overwrites the first.
Tool has no description. LLMs cannot determine when or why to select this tool. Baseline: 100% of A+ tools have descriptions; this tool scores 0/100 on description dimension.
Parameter 'city' lacks description. LLMs cannot infer whether to pass a city name, code, or ID. Baseline: 100% of A+ tools have parameter descriptions.
Output schema undocumented. Tool returns JSON text without specifying structure, field types, or error format. LLMs cannot reliably parse or chain results.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 31 | 2026-07-28+ | v2 |
Error handling provides no recovery guidance. Failures return {temp: null, error: '...'} as unstructured text. LLMs cannot determine if error is retryable, user-fixable, or fatal.