Server provides 5 read-only tools with documented input schemas and descriptions. All tools follow verb_noun naming (list_, get_, query_). However, several tools have descriptions that are somewhat generic, and output schemas are not explicitly documented in the visible code. Parameter descriptions are present but vary in specificity. No destructive operations (all READ_ONLY), which reduces security/error handling burden. Tools are well-composed for log querying workflow but lack response field documentation and error recovery guidance.

• Document output schema for each tool. Example for query_logs: 'Returns array of log entries, each with {dt: ISO8601 string, raw: string, ...fields} sorted by dt DESC. Returns up to limit entries.'
• Convert enum values from descriptions to formal JSON Schema enum constraints. For get_source_info data_type parameter: add 'enum': ['recent', 'historical', 'metrics', 'union'].
• Add error guidance to descriptions. Example: 'If source_id is not found, returns error with available source IDs. Call list_sources() to discover valid IDs.'
• Expand list_sources and list_source_groups descriptions to 100+ characters, explaining when to use each and what data structure each reveals.
• Add cursor/offset pagination to query_logs for large result sets. Include 'next_cursor' in response when more results exist, accept optional 'cursor' parameter.
• Add 'time_range_hint' to query_logs description: 'Supports relative times (last_24_hours) or custom ISO 8601 range. Use relative times for simplicity unless specific dates required.'
• Document which fields are always present vs optional in responses (e.g. does log entry always have a level field, or is it null?).

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

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