Model Context Protocol (MCP) server for Graylog log searching with distributed tracing. Search logs, trace requests across services, get surrounding context, and debug production issues.
Five tools with complete schemas and descriptions, but quality is uneven. Tool names follow verb_noun convention well (search_logs_absolute, trace_request, list_streams). Descriptions are present and contextual (avg ~120 chars), exceeding the 10-char minimum but below the 50-200 char LLM-optimized range. All parameters have type definitions and descriptions. However, parameter descriptions lack actionable constraints (e.g., no regex patterns, min/max for numeric fields, or enum declarations for constrained values). Output schemas are not documented, LLMs cannot predict response structure. Error handling is absent from tool definitions. No tool annotations (readOnlyHint, idempotentHint). The server implements input validation in helpers.js (isValidISO8601, validateQuery, etc.) but this is not surfaced in the schema or descriptions, forcing LLMs to guess at constraints.
Get logs surrounding a specific message (before and after) for context. Useful for understanding what happened around an error or event.
List all available Graylog streams. Use stream IDs with search_logs_absolute or search_logs_relative to filter results to a specific stream.
Search Graylog logs using absolute timestamps (from/to). Returns all log fields by default including trace_id, span_id, pod, service, container_name for distributed tracing.
Search Graylog logs using relative time range (e.g., last 15 minutes). Returns all log fields by default for distributed tracing.
Trace a request across services using trace_id. Returns all logs with the same trace_id, ordered by timestamp, showing the full request flow through your microservices.
Output schemas not documented. LLMs cannot predict response structure (fields, types, pagination). Handlers return formatMessages() output but schema is invisible to the protocol.
Parameter constraints not formalized. Descriptions mention defaults and ranges (e.g., 'limit: default 50, max 1000') but lack JSON Schema minValue/maxValue, pattern, or enum. LLMs cannot validate before calling.
No tool annotations. All tools are read-only (risk: READ_ONLY declared in metadata) but schema lacks readOnlyHint annotation. Agents cannot infer safety from the tool definition alone.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 56 | <=2025-11-25 | v2 |
Error handling not documented in tool definitions. Validation errors (invalid ISO8601, out-of-range limit) are caught server-side but tool descriptions do not guide LLMs on recovery (e.g., 'If timestamp is invalid, use ISO 8601 format: YYYY-MM-DDTHH:MM:SSZ').
list_streams has empty input schema (no properties). Description is generic ('List all available Graylog streams'). No guidance on pagination, filtering, or response structure.