Read-only Elasticsearch log investigation server for Kibana, providing tools to query, aggregate, and analyze logs across multiple environments through the Kibana console proxy REST API.
Kibana MCP has well-structured tool definitions with complete input schemas and descriptions. All 6 tools follow verb_noun naming (count_logs, aggregate_logs, search_index, time_series, compare_windows, search_samples). Descriptions are detailed (100-250 chars) and explain WHEN to use each tool. Input parameters have types and descriptions. However, output schemas are not documented in the source code, the CallToolResult return type is opaque to the LLM. Error handling guidance is absent; tools do not indicate what to do on failure. No tool annotations (readOnlyHint, destructiveHint) despite all being marked ReadOnly=true in code. Parameter constraints (e.g., interval enum values, limit ranges) are mentioned in descriptions but not formalized in JSON Schema.
Runs guarded structured aggregations over PE Elasticsearch logs. Use it for one or more field groups, time buckets, per-day Top N, multi-metric summaries, slow-request ratio investigations, or other cases that still do not require raw Elasticsearch DSL. Prefer field-scoped queries to narrow the business scope; call discover_fields first when fields are uncertain.
Compares PE Elasticsearch log counts or metrics across two time windows. Use it to find abnormal increases, decreases, new request types, traffic distribution changes, or differences between today and yesterday.
Counts Elasticsearch log documents in the selected environment and index target. Use it when you need an exact read-only count before aggregating.
Finds PE Elasticsearch log index families matching an index pattern in the selected environment. Lists live indices grouped by logical prefix (date segments removed) and annotates each family with a description from the bundled index catalog. Use it to pick an index target before querying other tools; use discover_fields for field-level detail.
Fetches a small number of matching PE Elasticsearch log samples and returns only selected source fields. Use it after aggregation to inspect concrete examples while avoiding full payload downloads.
Output schemas not documented. CallToolResult return type is opaque; LLMs cannot infer what fields to expect or plan downstream calls.
No error handling guidance. Tools do not indicate what to do on failure (retryable vs user-fixable vs fatal), forcing LLMs to guess recovery strategy.
Parameter constraints (interval enum, limit ranges, size bounds) are documented in descriptions but not formalized in JSON Schema. LLMs cannot parse constraints from text alone.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 69 | <=2025-11-25 | v2 |
Aggregates PE Elasticsearch logs into time buckets. Use it to find peaks, valleys, daily distributions, hourly patterns, or to narrow an incident window; it can also split by a field. For slow-request investigations, use a query such as milliseconds:>10000.
Tool annotations missing. All tools are marked ReadOnly=true in code but do not expose readOnlyHint in the protocol, preventing clients from optimizing caching or safety policies.
Result limits mentioned in descriptions (e.g., 'up to 2000' for search_index, 'up to 100' for search_samples) but not enforced or validated in visible code. No pagination guidance for large result sets.