A Model Context Protocol server for fetching weather information
Single tool with basic schema and minimal description. Tool name 'get-weather' follows verb_noun convention (+), but description is only 56 chars and lacks context on when/why to use it. Input schema is present with proper JSON Schema structure, but parameter description is generic. No output schema documented. No error handling guidance. No parameter constraints (e.g., city format, length limits). Tool lacks idempotency hints and does not document API dependencies or failure modes.
Fetches current weather information for a given city
Missing output schema documentation. LLMs cannot plan downstream operations or extract fields without knowing response structure.
Tool description is 56 characters, below the 10 - 1024 baseline and lacks WHAT/WHEN/WHY context. Does not explain prerequisites (API key required), failure modes, or when to use this vs alternatives.
Parameter 'city' description is generic ('The name of the city...') and includes an example value ('Istanbul'). LLMs may reuse example literally. No format constraints, length limits, or validation rules documented.
Error handling returns generic text ('An error occurred...') without recovery guidance. LLM cannot determine if error is retryable, user-fixable, or fatal. No actionable next steps provided.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 50 | 2026-07-28+ | v2 |
API credentials (WEATHER_API_BASE_URL, WEATHER_API_KEY) are injected via environment variables (correct), but tool does not document this dependency or what happens if keys are missing.