Server provides 13 tools with consistent naming (verb_noun pattern) and complete input schemas. All tools have descriptions (avg 85 chars, within baseline 34-392). However, descriptions are generic and lack LLM-optimized guidance on WHEN to use each tool or dependencies between them. Output schemas are not documented, LLMs cannot predict response structure. Error handling is minimal (no recovery guidance, no categorization). No tool annotations (readOnlyHint/destructiveHint) despite clear risk levels. Parameters lack format constraints (dates are free-form strings, not ISO 8601 validated). Missing idempotency guidance for write operations.

• Add output schema documentation to every tool. Document the structure of 'result' field, field types, and which fields are safe to chain into downstream tools.
• Add regex pattern or format constraint to date parameters. Use JSON Schema 'format': 'date' or 'pattern': '^\d{4}-\d{2}-\d{2}$' to enforce YYYY-MM-DD.
• Implement tool annotations: add readOnlyHint=true to all GET/read tools, destructiveHint=true to delete operations, idempotentHint=true to safe retries. Expose via MCP schema.
• Enhance error handling: wrap API errors with recovery guidance. E.g., 'Metering point not found. Call eloverblik_metering_points() to list available points.' Categorize errors as retryable (timeout, 429) vs user-fixable (invalid ID) vs fatal.
• Expand descriptions to 50-150 chars with LLM-optimized guidance: state WHAT, WHEN to use, and any prerequisites. E.g., 'Fetch electricity consumption for a date range. Call eloverblik_metering_points() first if you need to discover available metering points.'

Inferred effective spec: <=2025-11-25.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry