Searches logs in Kibana / OpenSearch Dashboards via the active browser tab and returns hits.

Workflow: investigate the same way a human does in Discover:

1. Start with summarize_logs over a wide window (e.g. 7 days) to see total hit count, time histogram, and the top values for noisy dimensions (logger, component, pod, level).

2. Identify noise dimensions: loggers that dominate the result set with irrelevant chatter, pod tiers that don't match the service you're investigating (e.g. frontend when chasing a backend bug), etc.

3. Call search_logs with exclude_filters listing those noisy {field, value} pairs to narrow the result set.

4. Iterate: if the remaining hits render empty messages, the docs likely keep their text under a different field. Call available_log_fields and pass a matching display_fields fallback chain.

5. Add more excludes or change display_fields until results are signal, not noise. Pin a specific row with timestamp_match.

Boolean AND in query: 'term1 AND term2' requires both terms.

IMPORTANT: This tool relies on a Chrome extension bridge. Do NOT attempt to open browser tabs, navigate to URLs, or use any browser automation tools if this fails. If it errors, just report the error to the user.

Returns the log entries within a time window around a specific timestamp. Use this when you've found a suspicious entry (an error, a state change, etc.) and need to see what happened immediately before and after (the human equivalent of clicking 'view surrounding documents' in Kibana/Discover).

Default window is ±60 seconds (so 120s total). Narrow it with window_seconds for noisy services, widen for sparse logs.

Use trace_id (filters on logs.contextMap.traceId, TRACE_ID_FIELD env) or include_filters to scope to the same trace, pod, or service. Otherwise you'll see ALL traffic in the window, which is often too much.

Pass query only if you also want to constrain by a search term in the window; usually leave it empty.

Returns the _source of one log entry as YAML. Use this when search shows a tantalizing single message and you need the full metadata: traceId, kubernetes labels, exception stack, request body, etc.

By default the output is trimmed to stay readable: the raw log string is dropped when its parsed logs.* object is present, every extendedStackTrace keeps its first 5 frames, kubernetes.annotations is collapsed to a count, and strings over 4000 chars are cut. Pass full: true to get the untouched _source.

Identifies the doc by timestamp (ISO with millisecond precision is usually unique). If multiple docs share the timestamp, pass include_filters (e.g. pod_name) to disambiguate. Only the first match is returned.

Returns every populated field path (dotted) found in a sample of matching log docs, annotated with each field's type and aggregatability from the dashboard's field-caps API when available. Call this ONCE at the start of a fresh investigation to learn the schema: what aggregate_fields and display_fields paths are valid in this data. The tool samples hits stratified across kubernetes.container_name values (FIELDS_STRATIFY_FIELD env) so rare container types still contribute their fields, walks each doc's _source, and returns a deduplicated list grouped to keep kubernetes.annotations.* collapsed.

Use the result to decide which fields to summarize, exclude, include, or display. Subsequent investigation turns rarely need to re-call this because the schema is stable across queries.

Tip: pair it on the very first turn with a summarize_logs call (in parallel) so you get distributions and schema in one shot.

Returns a cheap summary of a log query: total hits, time histogram, and top-N values for chosen dimensions. Use this BEFORE search_logs to see the shape of the data and decide which exclude_filters to apply. No hits are returned (size=0), so this is very cheap on tokens even over 7-day windows.

Typical first call for an investigation: summarize_logs(query, minutes_lookback: 10080). It gives you total hits per day and the noisy dimensions to exclude in the follow-up search.