kibana-console-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a clearly distinct operation: querying (es_search, es_count, es_esql), discovery (es_list_indices, es_get_mappings, kbn_list_data_views), investigation (es_trace, es_find, es_patterns, es_why, es_overview), and administrative access (kbn_status, kbn_find_saved_objects, es_request). Overlapping-looking tools like es_find vs es_search are explicitly differentiated by purpose and guidance in their descriptions.
Naming Consistency4/5
The set follows a mostly consistent convention: es_ for Elasticsearch operations and kbn_ for Kibana operations, with verb_noun pairs like es_get_mappings, es_list_indices, kbn_find_saved_objects. A few tools use noun/adverb style names (es_patterns, es_why, es_overview), which breaks the verb-led pattern but remains predictable and readable.
Tool Count5/5
14 tools is well-scoped for a Kibana/Elasticsearch investigation console. Each tool covers a distinct capability — from low-level search, to aggregations, to incident-analysis helpers, to saved-object access — without feeling bloated or redundant.
Completeness5/5
The tool surface is comprehensive for its read-only investigation purpose: it covers index discovery, field mappings, query execution (DSL, count, ES|QL), log pattern analysis, trace following, statistical comparisons, overview generation, saved object lookup, and a general escape hatch for unlisted Elasticsearch APIs. No obvious dead ends remain.
Average 4.2/5 across 14 of 14 tools scored. Lowest: 3.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and does convey read-only, space-scoped search behavior. However, it does not disclose the return format, pagination behavior, or the fact that the schema's 'search' parameter only searches titles, which remains in the schema rather than the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence that names the action, resource, scope, and common types with no redundancy or filler. Every word carries meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only search tool with fully documented parameters, the description adequately covers scope and typical use. However, because there is no output schema, the description does not compensate by describing return values or result structure, leaving an agent to guess at the response shape.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with every parameter having a meaningful description, so the tool description adds little value beyond examples already provided in the schema. The baseline for full schema coverage is 3, and there is no reason to go higher.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the verb 'Search' and the resource 'Kibana saved objects in the active space', and it enumerates concrete object types such as dashboards, visualizations, index patterns, saved searches, and lens objects. It identifies a distinct resource category from the sibling ES tools, but it does not explicitly differentiate from the similar kbn_list_data_views sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the obvious use case—searching Kibana saved objects—but gives no explicit when-to-use guidance, no exclusions, and no alternatives. An agent can infer the purpose, yet there is no routing information to avoid overlap with sibling tools like kbn_list_data_views.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses a useful behavioral trait: this tool is cheaper than a search. However, it does not explicitly state that the operation is read-only, non-mutating, or what the response format is. For a simple count operation this is modest but not fully complete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that earns its place: it states what the tool does and when to use it. No wasted words and the key advantage is front-loaded.
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 simple two-parameter count tool, the description plus schema covers the purpose, the query semantics, and the main usage condition. It does not explicitly state that the return value is a count, but that is strongly implied by the name, title, and described behavior. The absence of an output schema is not a serious gap here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters (index and query) are already documented in the schema. The description only reinforces the role of the query clause ('matching a query') without adding new detail. Baseline 3 is appropriate when the schema handles parameter documentation.
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?
The description clearly states a specific action ('Count documents matching a query') and the resource. It also distinguishes itself from sibling tools like es_search by noting it is 'cheaper than a search' when only the total matters, so an agent can tell it apart without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to prefer this tool: 'Cheaper than a search when only the total matters.' This gives a clear condition for choosing it over a full search. It could be more explicit by naming alternatives like es_search, but the guidance is still clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool runs over a random sample and that counts are approximate, which is a critical behavioral trait. However, it does not explicitly state that the operation is read-only, nor does it describe output structure, permissions, or timeout behavior beyond what the schema already notes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: the core transformation, the intended questions it answers, and the critical sampling caveat. It is front-loaded with the action and avoids redundant or promotional language.
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 tool with 5 optional parameters and no output schema, the description covers the primary use case, the key behavioral caveat about sampling, and what kind of result to expect ('short list' with counts). It could mention exact output shape or edge cases, but schema descriptions fill most parameter-level gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already well documented. The description adds context about sampling and approximate counts, which relates to probability, but it does not significantly extend the schema's parameter-level guidance. A baseline of 3 is appropriate.
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?
The description opens with a specific verb and resource: 'Collapse a window of raw log lines into the handful of message templates behind them, with a count for each.' It clearly distinguishes itself from search/count siblings by framing the use case as answering 'what is in these logs' or 'what changed' without reading individual lines.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use it: to summarize logs into patterns and answer high-level questions about content or changes. It does not mention when not to use it or name alternative tools, but the context is clear enough to route an agent appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals that the tool performs a single Elasticsearch request, aggregates across namespaces/containers, shows time distribution, and returns a sample of lines. This goes well beyond the title and schema, though it does not discuss limits, edge cases, or error behavior, so it is strong but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. It front-loads the core purpose ('One-shot log search'), enumerates the output dimensions in a compact list, and closes with a concrete usage directive. Every sentence earns its place.
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?
The tool has 4 flat parameters and no output schema, but the description compensates by naming the key result groupings: match count, namespaces/containers, time distribution, and sample lines. Combined with the schema's parameter documentation, an agent has enough to call it effectively. It could have mentioned what happens when no matches are found, but that is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all four parameters and their meanings. The description adds strategic context about the one-shot nature and the window's impact on query time, but it does not need to repeat parameter-level semantics, so baseline 3 is appropriate.
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?
The description clearly states a specific verb and resource: one-shot log search that returns match count, source namespaces/containers, time distribution, and sample lines. It distinguishes itself from a generic search or discovery call by explicitly framing itself as an all-in-one alternative to discovery-plus-search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance: prefer this as the FIRST call for 'where/when/how often is X happening,' and it explains why (answers all three questions in one round trip). It stops short of naming sibling tools explicitly or stating when NOT to use it, but the usage context is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It states the read-only retrieval behavior and adds the important fallback to _field_caps when credentials cannot read _mapping directly. It does not describe error cases or output shape, but the disclosed behavior is honest and useful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: purpose, usage advice, and fallback behavior. Information is front-loaded and there is no filler.
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 low-complexity tool with one well-documented parameter and no output schema, the description is nearly complete. It explains what the tool returns, when to call it, and how it handles credential limitations. Minor missing detail is the exact response structure of the fallback.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers the single parameter fully with a description and example. The tool description adds context about mappings but not additional parameter-level syntax or constraints, so baseline 3 is appropriate.
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?
The description names a specific verb, resource, and scope: 'Return the field mappings for an index or index pattern.' This clearly differentiates it from sibling tools like es_search, es_count, and es_list_indices.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage guidance: 'Read this before writing a query so field names and types are correct.' It does not spell out when-not-to-use or name alternative tools, but the intended context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full behavioral disclosure burden. It does disclose an important constraint: only GET/HEAD and search-shaped POST paths are permitted in read-only mode. However, it does not mention response format, error behavior, authentication requirements, or how the 'read-only mode' is determined, leaving meaningful gaps for a raw passthrough tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences: the first establishes purpose and gives examples, the second states the critical restriction. No filler or redundant restatement; it earns its length.
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 an escape-hatch tool with three parameters and no output schema, the description plus schema covers the essentials: what the tool is for, example paths, and the method allowlist. It does not explicitly state that the response is the raw Elasticsearch response, but 'Raw' in the title and the escape-hatch metaphor make this reasonably inferable.
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?
Since schema description coverage is 100%, the schema already documents path, body, and method. The description adds value by giving representative path values and clarifying which method/body combinations are allowed ('search-shaped POST paths'), which is beyond what the schema states.
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?
The description clearly identifies the tool as an 'escape hatch' for Elasticsearch APIs that sibling tools do not cover, and reinforces this with concrete examples like '_cluster/health' and '_cat/aliases?format=json'. This distinguishes it from specialized siblings such as es_search and es_get_mappings without needing to open schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: for Elasticsearch APIs not covered by other tools. It also gives clear exclusions by limiting what is permitted in read-only mode ('only GET/HEAD and search-shaped POST paths'). It could name specific sibling alternatives, but the general routing guidance is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the disclosure burden and does it well: it explains the wider-baseline comparison, statistical over-representation, p-value ranking, and background noise filtering. It stops short of declaring read-only status or the exact result format, but the core runtime behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no filler. The core action is front-loaded, usage scenarios come second, and the statistical ranking detail is last. Each sentence earns its place.
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 tool with no annotations and no output schema, the description covers purpose, use cases, comparison mechanism, and noise filtering. It could be more complete by noting the exact output shape or read-only behavior, but nothing essential for invoking it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents all five parameters at 100% coverage, so the baseline is 3. The description adds useful framing by clarifying the window-vs-baseline comparison and what fields are reported, but it does not need to restate parameter-level syntax.
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?
The description opens with a specific verb and resource: comparing a window to a wider baseline and reporting which namespaces, containers, and pods are statistically over-represented. It clearly separates this analytical spike-explanation tool from siblings like es_search or es_count by naming its purpose and 'why did logs spike' use case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides concrete when-to-use triggers: 'why did logs spike', 'what changed at 14:00', and narrowing an incident to a service before reading lines. It stops short of naming sibling alternatives or saying when not to use it, so it earns a 4 rather than a5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, and it does well by detailing the exact contents of the response and the baseline comparison behavior. It does not discuss authorization, latency, or cost, but the 'Everything needed in one request' framing plus the enumerated outputs gives the agent a solid behavioral model.
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?
The description is two sentences with no filler and front-loads the tool's purpose in the first sentence. The first sentence is a dense list, but it earns its length by enumerating all the value the tool provides; the second sentence is directly actionable.
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 tool with 5 parameters, no output schema, and no annotations, the description covers the essential context: what the tool returns, when to use it, and which sibling tools to turn to next. It does not mention potential caveats like index availability or permission requirements, but the parameter schema and clear usage guidance make this a nearly complete definition.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds conceptual context, such as the baseline being used for the 'unusual' ranking and the window being the investigation period, but it does not substantially extend the parameter-level meaning beyond what the schema already provides.
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?
The description clearly identifies es_overview as the first-request investigation tool, listing exactly what it returns: log volume over time, error count/rate, source namespaces/containers, unusual containers relative to a baseline, and sample error lines. It also distinguishes itself from siblings by positioning itself as the opening move before es_patterns, es_why, or es_trace.
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?
The description explicitly tells the agent when to call this tool: FIRST for 'what is going on', 'is anything wrong', or the start of an incident. It also names the sibling tools to use afterward for narrowing down, giving clear routing guidance without ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the behavioral burden. It discloses the return format (columns/values table), gives a realistic example that shows aggregation behavior, and warns that leading-wildcard LIKE/RLIKE are rejected because they cannot use the index. It does not mention pagination, limits, authentication, or whether the query is constrained to read-only operations, but the core call behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences that front-load the core action and return format, then add practical usage guidance and a key pitfall. Every sentence earns its place with no filler or repetition of schema details.
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 tool with two parameters and no output schema, the description covers the essential operational context: what the tool does, what it returns, when it is preferred, and common text-matching pitfalls with an example. It could further clarify behavior of the optional filter or result limits, but an agent has enough to invoke it successfully.
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?
The schema already documents both parameters at 100% coverage, providing the baseline of 3. The description adds meaningful semantics for the query parameter with an example, shows how to express status filtering and aggregation, and clarifies text-matching syntax. The optional filter parameter is not elaborated in the description, but the schema covers it and the additional ES|QL guidance adds real value.
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?
The description states a specific verb and resource: 'Run an ES|QL query' and explicitly defines the return shape as a 'columns/values table.' It also differentiates the tool from siblings like es_search and es_count by positioning it as the fastest way to aggregate, with a concrete ES|QL example.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: use it for aggregation and ES|QL pipelines, and it provides specific guidance for text matching (MATCH/QSTR) and a warning against leading-wildcard LIKE/RLIKE. It does not explicitly name alternative sibling tools or state when to choose those over this tool, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description discloses important runtime behavior: it tries _cat/indices when the credential has the monitor privilege and falls back to _resolve/index otherwise. This privilege-dependent fallback is exactly the kind of behavioral detail that helps an agent understand what will happen on invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences, no filler. The main purpose is stated first, followed by route behavior, then usage guidance. Every sentence contributes distinct information.
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?
The description covers the tool's purpose, auth-dependent routing, and fallback strategy. It does not describe the differing output formats of _cat/indices versus _resolve/index, but since there is no output schema, an agent may still lack full clarity about response shape.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the pattern parameter with a default and examples (100% coverage). The description only restates that indices are matched by pattern, adding little semantic value beyond the schema.
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?
The description starts with a specific verb and object: 'List Elasticsearch indices matching a pattern.' It also positions itself as the starting point for index discovery, which distinguishes it from sibling tools like es_get_mappings or kbn_list_data_views.
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?
The description gives explicit guidance: use this tool when you do not know which index holds the data, and name the fallback tool (kbn_list_data_views) if both API routes are forbidden. This clearly tells an agent when to select this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It discloses that responses get truncated when oversized, that logs are large, and that field selection via source is strongly recommended. It does not disclose pagination limits (e.g., default max 10000 hits) or what happens on query errors, but the truncation warning is meaningful and directly applicable to agent behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The most important operational guidance is front-loaded: pass query body as object, keep size small, use source. Every clause earns its place.
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 parameter-rich tool with no output schema and no annotations, the description addresses the most critical operational risks: large documents, truncation, and field selection. It is slightly limited by not covering pagination beyond size, total hits, or error behavior, but for an Elasticsearch query tool it provides enough for an agent to invoke it correctly in typical cases. The 100% schema coverage compensates for many missing details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds a few behavioral notes: 'source' is aliased as '_source', and the 'size' guidance is reinforced. But it doesn't explain how aggregations, sort, or track_total_hits interact with the truncation warning or how to combine them with the query clause. The description does not go beyond what the schema descriptions already provide for most parameters.
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?
The description clearly states a specific verb ('Run'), a resource ('an Elasticsearch Query DSL search'), and the essence of how to invoke it (pass the query body as an object). It also adds concrete guidance to distinguish the tool's behavior: it targets log documents that are large and may be truncated. This is more than enough to differentiate it from siblings like es_count, es_esql, or es_request.
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?
The description gives explicit invocation guidance: pass the query body as an object, keep size small, and use source/_source to select fields. It also explains the rationale (large log documents, oversized responses get truncated), which helps the agent decide when to use this tool vs alternatives. It doesn't name alternative siblings explicitly, but the context is clear and practical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 meaningful work: it discloses that results are a compact timeline, that each JSON log line is parsed down to structured fields, and that it aggregates across every service that logged the id. It does not mention potential limitations like pagination or index coverage, but it gives a clear behavioral model of a read-only log correlation query.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wordiness: the first states the core action and output, the second gives a direct comparison that helps selection. The key routing guidance is front-loaded and every clause earns its place.
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 4-parameter tool with no output schema or annotations, the description covers the core behavior, the return shape, and the main alternative. It does not describe edge-case behavior or auth/rate concerns, but the schema already documents parameters and defaults, so the description is sufficiently complete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds some semantic color by listing common correlation-id forms (sessionId, transactionId, x-request-id, MSISDN) and the extracted output fields, but it does not explain the size, indeex, or window parameters beyond what the schema already clearly states.
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?
The description states a specific verb ('Follow') and a precise resource (one correlation id across services), and it names the output form: a compact timeline. It explicitly distinguishes itself from es_search by explaining that it parses log lines to time/pod/level/action/detail rather than returning whole documents.
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?
The description directly tells the agent when to choose this tool: 'Prefer this over es_search for what happened to this request.' This is an explicit routing instruction naming the alternative and the condition that selects the trace tool instead of a raw search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden, and it discloses the key behavioral constraint: 'works with Kibana-level privileges only' and the reliability context when ES cluster APIs are forbidden. It doesn't detail output fields or error behavior, but for a zero-parameter read-only list operation, the core behavioral traits are covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no filler: the first names the operation and resource, the second adds the privilege and use-case context. The key scoping phrase 'active space' is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple no-parameter list operation, the description covers what is listed, where it runs, and when to prefer it over cluster-level tools. No output schema exists, but the verb 'List' sufficiently implies the return value, and no further configuration or parameter details are needed.
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?
Input schema has zero properties, so there are no parameter semantics to clarify; per baseline this is a 4. The description's mention of 'active space' provides the only relevant scope context an agent needs.
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?
The description uses a specific verb and object: 'List the Kibana data views (index patterns) available in the active space.' It also distinguishes itself from ES cluster-index tools by noting it relies on Kibana-level privileges, so an agent can tell it apart from siblings like es_list_indices.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear context: this works under Kibana privileges and is 'the reliable way' when Elasticsearch cluster APIs are forbidden. It does not explicitly name an alternative tool or list exclusions, but the implied when-to-use condition is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It clearly indicates a read-only connectivity check and specifies the exact state reported (Kibana version, active space, read-only/index-allowlist settings). It does not cover failure behavior or side effects, but for a parameterless status tool the disclosed behavior is adequately transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads the primary purpose ('Check connectivity') before listing the reported items. Every word contributes to the agent's understanding; there is no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless status tool with no output schema, the description covers the operation, the scope ('this MCP server'), and the content of the result (version, active space, settings). Nothing needed to call 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?
The tool has zero parameters, so the description has no parameter meanings to clarify. With no required or optional inputs, the baseline for a no-parameter tool applies; the description adequately focuses on the operation rather than inputs.
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?
The description names a specific action ('Check connectivity') on a specific resource ('Kibana' / 'this MCP server') and enumerates the exact information returned: version, active space, and read-only/index-allowlist settings. Among sibling tools focused on Elasticsearch queries, mappings, and data views, this is the only status/health tool, so it is readily distinguishable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Check connectivity' provides clear context for when to call this tool: to verify the server is reachable and inspect its current configuration. It does not explicitly list alternatives or exclusions, but as the sole status tool among the siblings, the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

kibana-console-mcp MCP server — quality and maintenance score on Glama

Copy to your README.md:

[![kibana-console-mcp MCP server — quality and maintenance score on Glama](https://glama.ai/mcp/servers/ePotok22/kibana-console-mcp/badges/card.svg)](https://glama.ai/mcp/servers/ePotok22/kibana-console-mcp)

Score Badge

Copy to your README.md:

[![kibana-console-mcp MCP server — quality and maintenance score on Glama](https://glama.ai/mcp/servers/ePotok22/kibana-console-mcp/badges/score.svg)](https://glama.ai/mcp/servers/ePotok22/kibana-console-mcp)

shields.io Endpoint

For READMEs with an existing badge row. Append &style=flat-square (or any other shields.io style) to match the rest, and &metric=tools, &metric=maintenance or &metric=claim to badge a different dimension.

[![kibana-console-mcp MCP server — quality and maintenance score on Glama](https://img.shields.io/endpoint?url=https%3A%2F%2Fglama.ai%2Fmcp%2Fservers%2FePotok22%2Fkibana-console-mcp%2Fbadges%2Fshields.json)](https://glama.ai/mcp/servers/ePotok22/kibana-console-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ePotok22/kibana-console-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server