mcp-for-kibana
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| KIBANA_URL | No | Kibana base URL the server connects to. Can also be set as KIBANA_MCP_KIBANA_URL. | http://localhost:5601 |
| KIBANA_API_KEY | No | stdio mode: the API key used for every request. HTTP mode: ignored unless KIBANA_MCP_ALLOW_ENV_KEY_HTTP=true — each caller sends their own key. Can also be set as KIBANA_MCP_KIBANA_API_KEY. | |
| KIBANA_MCP_TIER | No | Max tool tier to register: read, write, or destructive. | write |
| KIBANA_PUBLIC_URL | No | URL used to build human-clickable dashboard links, if different from the URL the server itself reaches Kibana on (e.g. behind a proxy). Defaults to KIBANA_URL. Can also be set as KIBANA_MCP_KIBANA_PUBLIC_URL. | |
| KIBANA_MCP_TOOLBOXES | No | Comma-separated list of toolboxes to register. | dashboards,data-management |
| KIBANA_MCP_EXPORT_DIR | No |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| logging | {} |
| prompts | {
"listChanged": true
} |
| resources | {
"subscribe": false,
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| search_dashboardsA | Search dashboards by title/description. Empty query lists all.
|
| get_dashboardA | Get a dashboard summary: title, description, and its panels.
|
| search_visualizationsA | Search library visualizations (from create_visualization) by title. Empty query lists all.
|
| get_visualizationB | Get a library visualization: title, chart type, data view, metrics, group_by and filter query.
|
| create_dashboardA | Create a dashboard from one or more visualization specs. Idempotent:
creating with the same title (case-insensitive,
whitespace/punctuation-normalized) updates that dashboard instead of
duplicating it, replacing its panels (filters, query, tags and display
options are preserved); the return's
|
| create_visualizationB | Create a reusable visualization in the library (not on a dashboard).
|
| update_visualizationA | Replace a library visualization with a new spec; its id stays the same. Dashboards that show it through add_library_panel change too; panels added with add_panel or create_dashboard are separate copies and do not.
|
| add_library_panelA | Show a library visualization on an existing dashboard. The panel is linked, not copied: update_visualization changes it on every dashboard.
|
| add_panelB | Add a visualization panel to an existing dashboard.
|
| add_esql_metric_panelA | Add an ES|QL metric panel to an existing dashboard: run an ES|QL
query and show one of its output columns as a single-number metric.
|
| add_esql_table_panelA | Add an ES|QL table panel to an existing dashboard: show a query's
output columns as a table.
|
| add_esql_xy_panelA | Add an ES|QL bar/line/area panel to an existing dashboard:
|
| update_panelA | Replace the visualization at panel_index (see get_dashboard for indexes).
|
| list_data_viewsA | List Kibana data views (the datasets you can visualize).
|
| describe_data_viewA | Get a data view's fields and types. Call this before creating a visualization so you use real field names.
|
| resolve_short_urlA | Resolve a Kibana short-URL slug to its locator and target app path. (Short URLs are a Technical-Preview API.)
|
| export_saved_objectsA | Export saved objects (dashboards, data views, …) as an NDJSON file
on the server, and return a summary + an opaque
|
| import_saved_objectsA | Import a previously-exported set of saved objects, identified by the
|
| create_data_viewA | Create a Kibana data view over an index pattern (e.g. 'logs-*'). Optionally set a display name and a time field (for time-series data). The time field must be a date field of the indices the pattern matches: a field they do not have, or one that is not a date, is refused with the pattern's date fields listed, and no data view is created. A pattern that matches no index yet is accepted, but its time field cannot be checked. The name (it defaults to the index pattern) must be unused; to change an existing view, call update_data_view.
|
| update_data_viewA | Edit an existing data view in place, by id (from list_data_views):
its display
|
| create_short_urlA | Create a Kibana short URL. Supports
locator_id='LEGACY_SHORT_URL_LOCATOR' with params={'url': '/app/...'}
(a Kibana app path). (Technical-Preview API.) A slug created in a space
resolves under
|
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| user-guide | Full getting-started guide: setup, first dashboard, safety rails. |
| tools | Tool reference: tiers, inputs, return shapes, error behavior. |
| troubleshooting | The user guide's Troubleshooting section, extracted. |
TDQS
Scored across 21 tools
Most tools have clearly distinct purposes, but add_panel and add_library_panel overlap (both add a visualization to a dashboard), and the three add_esql_*_panel tools could be seen as variants of one operation. Their descriptions do help clarify the intended use cases.
All tools use snake_case with a predictable verb_noun pattern (add_*, create_*, update_*, get_*, search_*, list_*, describe_*, export_*, import_*, resolve_*). There are no mixed conventions or inconsistent verb styles.
21 tools is heavy for this surface; the three ES|QL panel tools and separate export/import saved-object tools add niche operations that could be consolidated. While each tool has a purpose, the set is over-segmented relative to typical scoped MCP servers.
Core create/read/update workflows exist for dashboards, visualizations, data views, and panels, but deletion is entirely absent (no delete_dashboard, delete_visualization, delete_data_view, delete_panel, delete_saved_objects). There is also no explicit update_dashboard by id, leaving lifecycle gaps.