MCP server for searching and analyzing service logs using natural language queries. Provides tools to search logs, get summaries, track request journeys across services, and analyze hourly statistics.
Server has 4 tools with complete input schemas and descriptions. Naming follows verb_noun convention (search_logs, get_log_summary, track_request_journey, get_hourly_stats). Descriptions are present and contextual (avg ~180 chars), exceeding the 10-char minimum but below the 50-200 char LLM-optimized range. All parameters have type definitions and descriptions. However, output schemas are not documented in the source code, critical for LLM planning. Error handling is minimal (no recovery guidance, no error categorization). No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite all tools being read-only. Parameter constraints are present (enums for logLevel) but inconsistently applied. Missing pagination guidance for search_logs despite 'limit' parameter suggesting large result sets.
Get hourly breakdown of log statistics (counts, errors, requests per hour). Use for performance analysis, identifying peak times, or hourly trends. Examples: 'show hourly stats for 2025-10-30', 'hourly breakdown api-gateway'
Get statistical summary of logs (total count, breakdown by log level). Use when user wants overall statistics or distribution. Examples: 'summarize api-gateway logs for October', 'show log breakdown for 2025-10-30'
Search and analyze service logs using natural language. Use this when the user wants to: find errors/warnings/logs, count occurrences, see specific log entries, filter by date/service/identifier. Examples: 'show errors in api-gateway on 2025-10-30', 'find logs with identifier ABC123', 'count warnings yesterday'
Trace a specific request across all services using its request ID. Use when debugging a specific request flow or investigating failures. Examples: 'track request abc-123', 'show journey for request xyz'
Output schemas not documented. LLMs cannot plan downstream calls or extract required fields without knowing response structure. search_logs returns 'totalMatches' but full schema is absent from code.
No tool annotations despite all tools being read-only. Missing readOnlyHint metadata prevents agents from understanding safety profile and retry semantics.
search_logs accepts 'limit' parameter (max 100) but no pagination guidance. Large result sets risk context window exhaustion. Missing offset/cursor and total_count in documented output.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 56 | 2026-07-28+ | v2 |
Error handling incomplete. Code shows 'No logs found' message but no recovery guidance (e.g., 'Try broadening date range or removing filters'). No error categorization (retryable vs user-fixable).
Parameter descriptions lack format constraints. 'startDate' and 'endDate' state 'YYYY-MM-DD format' in text but no regex pattern or JSON Schema format constraint. LLMs may pass invalid dates.