Check connectivity and report the Kibana version, the active space, and the current read-only / index-allowlist settings of this MCP server.

List Elasticsearch indices matching a pattern. Uses _cat/indices when the credential has the "monitor" cluster privilege, and falls back to _resolve/index (index-level privileges only) when it does not. Start here when you do not know which index holds the data; if both routes are forbidden, use kbn_list_data_views.

List the Kibana data views (index patterns) available in the active space. This works with Kibana-level privileges only, so it is the reliable way to discover which indices are queryable when Elasticsearch cluster APIs are forbidden.

Return the field mappings for an index or index pattern. Read this before writing a query so field names and types are correct. Falls back to _field_caps when the credential may not read _mapping directly.

Run an Elasticsearch Query DSL search. Pass the query body as an object. Keep "size" small and pass "source" (aliased as "_source") to select fields — log documents are large and oversized responses get truncated.

Count documents matching a query. Cheaper than a search when only the total matters.

Run an ES|QL query and return a columns/values table. Usually the fastest way to aggregate, e.g. FROM logs-* | WHERE status >= 500 | STATS n = COUNT(*) BY host. For text matching use MATCH(field, "phrase") or QSTR("field: phrase") — a leading-wildcard LIKE/RLIKE cannot use the index and is rejected.

Search Kibana saved objects in the active space — dashboards, visualizations, index patterns, saved searches, lens objects.

Escape hatch for Elasticsearch APIs the other tools do not cover, e.g. "_cluster/health", "_cat/aliases?format=json", "_resolve/index/logs-*". In read-only mode only GET/HEAD and search-shaped POST paths are permitted.

Follow one correlation id — sessionId, transactionId, x-request-id, MSISDN — across every service that logged it, returned as a compact timeline. Prefer this over es_search for "what happened to this request": it parses each JSON log line down to time/pod/level/action/detail instead of returning whole documents.

One-shot log search: given a phrase, returns the match count, which namespaces and containers produce it, how it is distributed over time, and a sample of lines — in a single Elasticsearch request. Prefer this as the FIRST call for "where/when/how often is X happening", instead of a discovery call followed by a search: it answers all three questions at once and costs one round trip.

Collapse a window of raw log lines into the handful of message templates behind them, with a count for each. Use this to answer "what is in these logs" or "what changed" without reading individual lines — it turns millions of documents into a short list. Runs over a random sample, so counts are approximate.

Compare a window against a wider baseline and report which namespaces, containers and pods are statistically over-represented in it. Use this for "why did logs spike", "what changed at 14:00", or to narrow an incident to a service before reading any lines. Ranked by p-value, so ordinary background noise is filtered out.

Everything needed to start an investigation, in one request: log volume and its shape over time, error count and rate, which namespaces and containers the errors come from, which containers are statistically unusual versus a baseline, and a few sample error lines. Call this FIRST for "what is going on", "is anything wrong", or the start of an incident; then narrow with es_patterns, es_why or es_trace.