A weather service MCP server providing weather information for specified locations
This server has one tool (get_weather) with minimal documentation. The tool name is appropriately verb-prefixed (get_), but the input schema is incomplete, the description is missing entirely, and there are no parameter descriptions. The tool definition in src/index.mjs shows: server.tool('get_weather', { location: z.string() }, ...). While Zod schema is present, there is no tool description, no parameter description for 'location', and no documented output schema. Against the 54 Agentic Tool Patterns baseline, this server scores poorly on naming (acceptable), description (critical failure), schema completeness (partial), and error handling (none visible). The server also implements prompts and resources, but these have similar documentation gaps. This is a minimal proof-of-concept that does not meet production baseline standards.
Tool 'get_weather' has no description. LLMs cannot determine when or why to select this tool without explicit guidance on its purpose, when to use it, and what it returns.
Parameter 'location' in get_weather has no description. LLMs cannot infer what 'location' means (city name, coordinates, zip code, country code, address?) and will guess, causing invocation failures.
Output schema is not documented. The tool returns hardcoded text, but LLMs do not know the structure of the response (what fields to expect, what type each field is, what the response represents).
No error handling or recovery guidance. If the location is invalid or the weather service fails, the tool provides no actionable error message to guide the LLM's next step.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 30 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Hardcoded response ignores user input. The tool always returns 'sunny with a high of 25°C' regardless of location, making it non-functional. This is a critical logic flaw, not a documentation issue.