MCP server providing weather alerts, forecasts, and cryptocurrency price notifications
Server has 5 tools with basic schemas and descriptions, but significant quality gaps. Tool naming is inconsistent (get-alerts, get-forecast are clear; register-notification is vague about what it registers; get-user-notifications lacks verb clarity). Descriptions are present but generic (10-194 chars, below the 50-200 char LLM-optimized baseline). Parameters have types and descriptions, but several lack constraints or format guidance. Critical issue: tool descriptions do not match functionality, get-alerts and get-forecast claim to be weather tools but register-notification, get-user-notifications, and get-latest-token-price are cryptocurrency price alerts, creating semantic confusion. No output schemas documented. Error handling is minimal (generic try-catch blocks with no recovery guidance). No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Security concern: register-notification accepts session_id as a parameter, which could leak into logs.
Get weather alerts for a state
Get weather forecast for a location
Retrieve the latest token prices from the notification server. This tool fetches and returns the current prices of various tokens as maintained by the system.
Fetch all price alerts for a specific user session
Create a price alert for a specific token
Semantic mismatch: server named 'weather' but 3 of 5 tools are cryptocurrency price alerts, not weather. Tool descriptions do not clarify this domain split.
No output schemas documented. LLMs cannot infer what fields to expect from tool responses, forcing unstructured parsing and increasing hallucination risk.
Tool descriptions are generic and under 100 chars (baseline 50-200 for LLM optimization). 'Get weather alerts for a state' lacks context on when to use vs alternatives, what data is returned, or prerequisites.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 44 | 2026-07-28+ | v2 |
session_id parameter exposed in register-notification and get-user-notifications. Session IDs are sensitive identifiers that should not appear in tool parameters, they leak into logs and traces. Use server-side injection.
Error handling is minimal. Catch blocks return generic error text with no recovery guidance. LLMs cannot determine if errors are retryable, user-fixable, or fatal.