Skip to main content
Glama
yunusemregul

Kibana Bridge MCP

by yunusemregul
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

search_logs

Search Kibana/OpenSearch Dashboards logs via your active browser tab, exclude noisy loggers, and return relevant hits for investigation.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sizeNoMax hits to return (must be ≥ 1). Default 500. For counts only, use summarize_logs.
levelNoFilter on the level field (LEVEL_FIELD env, default logs.level; currently `logs.level`), e.g. 'ERROR' or ['ERROR','WARN']. Prefer this over putting ERROR in query, which also matches INFO messages containing the word error.
queryYesThe text to search for. Single term (e.g. 'OrderConfirmationJob') or multiple terms with AND (e.g. 'ORD-12345 AND payment'). An empty string or '*' matches all documents. The text is matched against these fields: message, logs.message, msg, log, logs.loggerName, logs.thread, logs.thrown.name, logs.thrown.message, logs.request, logs.requestFirstLine (override with the QUERY_FIELDS env var).
time_toNoAbsolute end time, ISO 8601. Without time_from, the window starts minutes_lookback before this.
query_dslNoRaw OpenSearch/Elasticsearch query DSL clause, AND-ed into the bool filter alongside `query` and the time range. Use for anything the plain text query can't express: numeric ranges ({range: {status: {gte: 500}}}), wildcards ({wildcard: {'url.keyword': '/api/*'}}), OR logic ({bool: {should: [...], minimum_should_match: 1}}), exists checks, etc.
time_fromNoAbsolute start time, ISO 8601 (e.g. '2026-09-23T10:28:00Z'). Without time_to, the window runs from here to now.
environmentNoWhich dashboard environment to search, as configured in the extension popup. The extension has not reported any environments yet, so omit this unless the user names one.
search_typeNo'phrase' (default) for exact phrase, 'best_fields' for fuzzy.
full_messageNoIf true, messages are shown in full without truncation/compacting. Use when you need complete response bodies.
display_fieldsNoFallback chain of dotted field paths used to render each hit's message. The first non-empty value wins per hit. Default ["message","logs.message","msg","log","logs.request","logs.requestFirstLine"]. Use available_log_fields to discover which paths exist in your data.
exclude_filtersNoDrop hits that match any of these {field, value} pairs (must_not + match_phrase). Use to silence noisy loggers, components, pods, etc. Example: [{field: 'logger', value: 'com.example.cache.CacheUtil'}, {field: 'kubernetes.labels.app', value: 'frontend'}].
include_filtersNoRequire hits to match all of these {field, value} pairs (OpenSearch filter + match_phrase). Use to scope to a specific service, pod, or status code.
timestamp_matchNoPin results to a specific @timestamp (e.g. '2026-02-14T14:58:02.793Z').
minutes_lookbackNoWindow length in minutes. Default 15. With neither time_from nor time_to it means the last N minutes up to now; with only time_to it means the N minutes ending at time_to; ignored when time_from is given. The response header always shows the resolved absolute UTC window.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.2

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations the description carries the full burden, and it does disclose key non-obvious traits: dependency on a Chrome extension bridge, the correct failure behavior (report the error rather than improvising browser automation), the fallback-chain rendering behavior, and that no environments are currently configured so 'environment' should be omitted. It stops short of disclosing rate limits, latency, or result-shape details, keeping it below a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads purpose, then numbers the workflow, then flags the browser-automation caveat in caps — good information architecture for a 14-parameter tool. It runs long and duplicates some schema content (e.g. the available_log_fields / display_fields guidance appears in both the workflow and the parameter descriptions).

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex, 14-parameter tool with no output schema, the description supplies workflow, dependency, failure handling, and rendering behavior. It omits what a returned hit looks like and roughly how expensive a search is, but nothing critical to calling it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. The description adds cross-parameter semantics the schema can't: the exclude_filters narrowing loop, the display_fields fallback rationale tied to empty renders, and the level-vs-query trade-off. Concrete example filter pairs are given, though several parameter details are still restated rather than extended.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb+resource+transport ('Searches logs in Kibana / OpenSearch Dashboards via the active browser tab and returns hits'). It also implicitly demarcates itself from siblings by defining search_logs as the narrowing step after summarize_logs, so an agent can distinguish the two without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides an explicit 5-step investigative workflow that names alternatives and the condition that selects each: start with summarize_logs for counts, use available_log_fields when messages render empty, pin a row with timestamp_match. It also states a when-not (do not attempt browser automation on failure) — unusually complete routing guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools