etracker-mcp demonstrates solid tool design with consistent naming (verb_noun pattern), comprehensive parameter schemas using Zod, and clear descriptions. All 8 tools follow action-verb conventions (list_, get_, compare_). Schemas are well-structured with type constraints and descriptions. However, output schemas are not explicitly documented in the source, responses are inferred from JSON stringification. Error handling is present but lacks recovery guidance. Date validation and parameter constraints are implemented server-side, which is good practice.

• Document output schemas for all tools. Example: 'Returns {reports: [{id: string, name: string, description: string}], total: number}'. This enables LLMs to plan downstream operations.
• Enhance error messages with recovery guidance. E.g., 'Invalid date range: exceeds 90-day limit (requested 120 days). Try splitting into two queries: [from-to-90days] and [90days-to].'
• Add readOnlyHint: true to all tool definitions in the MCP server registration to explicitly declare safety.
• Include total_count and next_offset in paginated responses so LLMs know whether more results exist and can iterate intelligently.
• Clarify compare_periods calculation: document whether it returns simple percentage change, CAGR, or absolute difference, and how zero/null values are handled.

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

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