An MCP server for Kibana that lets an LLM use composable, tiered toolboxes to build dashboards and manage Kibana resources.
Build/update dashboards from declarative visualization specs, including linked library panels and ES|QL metric/table/XY panels.
Search, inspect, create, and update dashboards, visualizations, and data views; describe data-view fields before charting.
Export/import saved objects via handles and create/resolve Kibana short URLs.
Manage alerting rules and connectors, and Kibana Cases.
Manage security detection rules, exception lists, and value lists.
Manage Fleet agents, policies, integrations, outputs, and enrollment.
Work with Streams, Observability/Synthetics/Uptime/APM, spaces/roles/upgrade readiness, and platform health.
Run over stdio or streamable HTTP/container, with selectable toolboxes and read/write/destructive tier caps.
Allows interaction with a Kibana deployment, providing tools for building Lens visualizations and dashboards from declarative specs, as well as managing data views, alerts, cases, security detections, Fleet, streams, observability, and platform administration/health.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-for-kibana Create a dashboard showing average ticket price by carrier for the last 7 days."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server for Kibana: composable toolboxes over a hexagonal core, powered by kibana-py.
Savings study: on one Kibana job, Claude Code with this server cost 24–69% less and finished 32–65% faster than calling Kibana's REST API directly (600 runs, three models). Results, limits and data · Project site.
Disclaimer: This is an independent, community-driven project and is not officially affiliated with, endorsed by, or supported by Elastic N.V. or any of its subsidiaries. "Kibana" and "Elasticsearch" are trademarks of Elastic N.V. This project is provided "as is", without warranty of any kind. See LICENSE. The name "mcp-for-kibana" uses "Kibana" referentially — this is an MCP server for Kibana, per Elastic's trademark guidelines on referential use — and does not imply origin or endorsement.
The distribution is mcp-for-kibana; the Python import package is kibana_mcp.
Technical Preview: the dashboards toolbox is built entirely on Kibana 9.4's new public Dashboards API and Visualizations API, both marked
x-state: Technical Previewby Elastic — their request/response shapes may still change in a later Kibana release without notice, and they carry no support SLA. This server supports Kibana 9.4 and 9.5; earlier versions don't expose these APIs publicly at all.
Every tool this server registers works on a Basic (free) Kibana license, and that is the boundary: functionality that needs a paid Elastic subscription is out of scope and stays out. Kibana's own per-type gates still apply to the values you pass — a Gold+ connector type stays Gold+.
The corollary is deliberate. Kibana ships its own MCP server as part of Agent Builder, whose APIs require an Enterprise subscription. A deployment on that tier already has an official one, so the Enterprise-gated surfaces are not worth duplicating here.
Related MCP server: Kibana Dashboard Builder
v0.4.0 + unreleased — 10 toolboxes, 184 tools, live-tested. The server exposes 184 tools across 10 composable toolboxes (dashboards, data management, alerting, cases, security detections, fleet, streams, observability, platform admin, and platform health), each classified read / write / destructive and contract-tested against live Kibana 9.4.8 and 9.5.5. It's packaged as a stdio and container-runnable server. See the Tool reference below.
The flagship path is dashboards from plain English: an LLM goes from a request
("average ticket price by carrier, last 7 days") to a real Kibana dashboard through
the read → validate → translate → write flow. That path passed its end-to-end gate
3/3 on 2026-07-10: a real local LLM in LM Studio (openai/gpt-oss-20b) drove it
autonomously — plain English in, correct live dashboard out, verified against the
stored Lens payload and cleaned up — three consecutive runs (16s/9s/7s wall). See
docs/e2e-setup.md for the one-time LM Studio setup
(permission toggles + API token) and tests/e2e/test_lmstudio.py for the
harness. Model note: gpt-oss-20b's parser-enforced tool grammar made it
3/3 reliable; qwen2.5-coder-14b completes the flow too but corrupts its
tool-call markers about one run in three.
Lets an LLM work with Kibana through a small, reliable, purpose-built tool surface instead of ~610 raw endpoints — 184 tools grouped into 10 composable toolboxes you enable per deployment. The flagship dashboards toolbox lets a user describe the chart they want, and the server translates a simple declarative spec into real Kibana Lens visualizations and dashboards via the modern Dashboards API (Kibana 9.4+). The other toolboxes cover data management, alerting, cases, security detections, fleet, streams, observability, and platform admin/health.
Design pillars:
Composable toolboxes — groups of tools enabled/disabled per deployment via configuration; small local models get a small surface, big models can get more.
Hexagonal core — pure domain logic (spec → Lens translation) isolated from both the MCP adapter and the kibana-py gateway; every layer independently testable.
Two run modes, one codebase — stdio for a local single user, streamable HTTP in a container for multiple users. Stateless: each request carries the caller's own Kibana API key, so Kibana RBAC and audit logging stay per-user. No multi-tenancy. Exception: saved-objects export handles live in one server-side directory shared by all callers — a handle is a bearer token for that export, and the 20-file retention cap is global, so concurrent HTTP callers can expire each other's handles.
Tiered write safety — every tool is classified read / write / destructive; deployment config caps the tier, and tools above the cap are never advertised to the model or callable by it (registered like every other tool, then hidden via FastMCP's visibility API — not just denied at call time).
Python 3.12+ (the server itself is pure Python and OS-independent)
For the dev workflow (Makefile, scripts, local stack): a POSIX shell, GNU make, and Docker with ~5 GB free memory for the Elasticsearch + Kibana stack. Windows: use WSL2.
A Kibana 9.4 or 9.5 deployment (or the bundled disposable local stack).
New here? The User Guide walks you from zero to your first talked-into-existence dashboard in ~10 minutes, on a disposable local Kibana with sample data.
export KIBANA_URL=https://your-kibana.example.com
export KIBANA_API_KEY=<your Kibana API key>
uvx mcp-for-kibana
# or from a local checkout:
uv run mcp-for-kibanaRuns stdio by default — one process per user, talking to Kibana as that user's own API key. See Configuration for every setting.
claude mcp add kibana --env KIBANA_API_KEY=<your key> -- uv --directory /path/to/checkout run mcp-for-kibanaAdd an entry to ~/.lmstudio/mcp.json — see
docs/examples/mcp.json for a stdio and an HTTP
example. For the full local E2E setup (real model, real Kibana, real
dashboard), see docs/e2e-setup.md.
Point the client at http://<host>:8000/mcp with header
Authorization: ApiKey <your Kibana API key> — see Docker below
for running the HTTP server.
184 tools across 10 toolboxes, each tool classified by tier — read / write /
destructive (74 / 71 / 39). Enable toolboxes per deployment with
KIBANA_MCP_TOOLBOXES; cap the tier with KIBANA_MCP_TIER. A tool above the cap
is not merely denied at call time — it never appears in the tool list (registered,
then hidden via FastMCP's visibility API).
Toolbox | Tools | What it does |
| 17 | Build Lens visualizations + dashboards from a declarative spec — the flagship plain-English → dashboard path. |
| 17 | Data views (with runtime fields and the space's default), short URLs, and saved objects (find, get, export, import). |
| 22 | Alerting rules and connectors: create, edit, mute, snooze. |
| 6 | Kibana Cases: create, comment, update status. |
| 30 | Detection rules, exception lists (incl. copy, export, import), value lists. |
| 41 | Fleet agents (tags, diagnostics), agent/package policies, integrations (install, uninstall), outputs, enrollment. |
| 12 | Streams list / summary / ingest config + processing (Tech Preview). |
| 22 | Synthetics monitors, parameters and private locations (read, create, edit, run, delete), Uptime settings, APM agent config (read, create or replace, delete) (no SLOs — Platinum-gated, out of scope). |
| 14 | Spaces, roles, upgrade readiness, saved objects between spaces (copy, share). |
| 3 | Cluster and Kibana status / health reads. |
A tier includes everything below it: read registers only read tools, write
(the default) adds write, destructive adds destructive. The default toolbox set
is dashboards,data-management (coupled — building a viz needs a data view).
See the full per-tool reference for every tool's arguments and return shape.
All settings are read once, in kibana_mcp.config.Settings, and are set via
env vars (prefix KIBANA_MCP_ for the deployment-shaped ones; KIBANA_URL,
KIBANA_API_KEY, and KIBANA_PUBLIC_URL are recognized both bare and
prefixed, matching how Kibana's own tooling names them):
Var | Default | Meaning |
|
| Kibana base URL the server connects to. |
| (falls back to | URL used to build human-clickable dashboard links, if different from the URL the server itself reaches Kibana on (e.g. behind a proxy). |
| (none) | stdio mode: the API key used for every request. HTTP mode: ignored unless |
|
| Comma-separated list of toolboxes to register (of the 10 available). |
|
| Max tool tier to register: |
| (none — off) | Comma-separated allow list of tool names. When set, the server publishes exactly the listed tools the tier allows and nothing else, and |
| (none — off) | Path to a TOML file of your own named tool lists, used as |
| (none — a fresh, unguessable 0700 temp dir per run) | Directory where saved-objects export/import NDJSON files are written. An explicit path is created 0700, a symlink there is refused, and a pre-existing directory is tightened to 0700. |
|
|
|
|
| Bind host (HTTP transport only). |
|
| Bind port (HTTP transport only). |
|
| HTTP mode only: opt in to letting |
| (none) | Path to a |
|
| Export an OpenTelemetry span per tool call. Off by default (spans are non-recording, no SDK imported); needs the |
The container always runs HTTP transport (KIBANA_MCP_TRANSPORT=http is
baked into the image), stateless, on port 8000. KIBANA_API_KEY is not
needed at the container level: HTTP mode expects each caller to send their
own key per request, and by default ignores KIBANA_API_KEY even if it's
set (set KIBANA_MCP_ALLOW_ENV_KEY_HTTP=true to opt back into it as a
shared fallback):
docker run -p 8000:8000 -e KIBANA_URL=https://your-kibana.example.com \
ghcr.io/pedro-angel/mcp-for-kibana
curl http://localhost:8000/mcp \
-H 'Authorization: ApiKey <your Kibana API key>' \
-H 'Content-Type: application/json' \
-H 'Accept: application/json, text/event-stream' \
-d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'The image runs as a non-root user (mcp-for-kibana, uid 10001).
make setup # uv sync + git hooks (uv-native path)
make help # every dev task, self-documentedNo uv on the machine? ./bootstrap.sh installs just the git hooks
(prek / pre-commit fallback chain).
The engineering conventions this project holds itself to are in CONTRIBUTING.md, and every one of them is enforced by a gate rather than by convention alone — see the Definition-of-Done gate below. Git & CI discipline comes from git-controls-starter.
Seven tiers, from fastest/most-isolated to slowest/most-real:
make test # unit — fakes only, no network; the default selection
make test-contract # starts + seeds the docker Kibana stack itself, then -m contract
make test-e2e-replay # replays RECORDED model turns (every toolbox) through a real MCP client
make test-e2e # REAL Claude (claude -p, default haiku) with only this server's tools
make test-e2e-local # a REAL local model in LM Studio — see docs/e2e-setup.md
make streams-ephemeral # destructive streams path on its own throwaway stack
make fleet-ephemeral # agent lifecycle on a throwaway 2-agent fleet stack
make fleet-unaware-ephemeral # uninstall_package's guards on Fleet with space awareness offEverything except the two live-model tiers (test-e2e, test-e2e-local)
runs in CI. The three ephemeral tiers own their
stack's whole lifecycle (up → test → down): their paths are destructive (they
delete every wired stream, or mutate real enrolled agents), or need a Fleet
booted with space awareness off, so they cannot share the dev stack. They also cannot run beside it — see
scripts/fleet_ephemeral.sh for the measured memory headroom.
On the two e2e tiers. They are not redundant, and one is not a substitute for the other:
|
| |
Who picks the tool calls | a real LLM (Claude / a local model) | a recorded transcript |
Server, MCP transport, Kibana, ES | real | real |
Runs in CI and in | no — on demand (D61): needs a Claude sign-in / a GPU + loaded model | yes |
Proves a model can reason to the calls | yes | no |
Proves the model-facing surface still works | yes | yes, per-PR |
The replay tier exists because the surface a model actually touches was
otherwise certified only on a maintainer's laptop. It replays a turn recorded
from a live gpt-oss-20b run — including the three failures that run recovered
from — and asserts the tools still exist, that arguments a real model produced
still validate against the live input schemas, and that the error guidance
survives. That guidance is load-bearing: a model has no other way to learn
your data's field names, and degrading "field 'price' does not exist … did you mean 'Carrier'?" to a bare 400 breaks self-correction for every LLM using this
server. Four mutation tests confirm the tier fails when each guard is broken.
Since D61 every toolbox has at least one recorded turn — Claude runs of the
per-toolbox tasks (not pre-registered) for cases, security-detections,
observability, streams, fleet and platform-health — and a toolbox without one
fails the unit tier. The gate replays them three ways: from the checkout, from
the built wheel, and from the built Docker image over HTTP with the key in an
Authorization: ApiKey header (image_replay_green, D62).
(Raw commands underneath: uv run pytest [-m contract|-m e2e_claude|-m e2e|-m e2e_replay] —
the suites load elastic-start-local/.env.seed + .env.local in-process; the
Makefile is a thin facade.)
The docs site is a CI gate too: uv sync --group docs once, then
uv run mkdocs build --strict must pass with zero warnings
(uv run mkdocs serve to preview locally).
Before claiming a change "done" — and always before a release — run the
Definition-of-Done gate, which certifies completion from dod.config
instead of letting the author self-certify:
make dod # GO/NO-GO over all declared criteria (definition-of-done.sh)Every tier needing infrastructure is excluded from the default selection
(addopts in pyproject.toml), so a bare pytest never silently depends on a
stack. CI splits accordingly: checks.yml runs the content gates (lint, types,
audit, SAST, unit across Python 3.12–3.14, docs, image build+smoke), and
integration.yml provisions real stacks for the live tiers and certifies them
through this same gate script with per-tier configs in .github/dod/ — so CI
verdicts and make dod cannot drift.
Each verdict names what it certified: the header and the VERDICT: line give
HEAD, the content tree id (uncommitted and untracked files included) and
clean/dirty, a tree edited during the run is NO-GO, and the run is recorded
in /tmp/dod-<repo>/verdict.json. A "GO at <sha>" claim checks out when
git rev-parse <sha>^{tree} equals the recorded tree id.
make dod needs the dev stack up for contract/e2e_replay/wheel_replay/image_replay and down for
the ephemeral tiers, so a plain run cannot satisfy both halves. To get a
one-shot GO, let the gate cycle the stack for you (default-off, so it never
touches infrastructure unasked):
scripts/stack.sh up && scripts/stack.sh seed
KIBANA_MCP_DOD_CYCLE_STACK=1 make dode2e_green — a real model choosing the calls — is n/a in every config
since D61 (superseding D42): the live model runs on demand. Run
make test-e2e (Claude via claude -p, model CLAUDE_E2E_MODEL, default
haiku, D38; needs a signed-in claude CLI) when a change touches tool
names, descriptions or schemas; a pass certifies only the model that ran.
make test-e2e-local runs three of its tasks (the flights, space and
alerting ones) as LM Studio tests on a small local model.
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.
esql is the query (e.g. 'FROM logs | STATS total = COUNT(*)') and
column names the output column to display (e.g. 'total'). For
field-based charts use add_panel with a VizSpec instead. The query is
NOT validated server-side — a wrong query or column yields an empty
panel, so write both carefully.
space targets a Kibana space by id (default: the default space).
Inputs: esql (required), title (required), column (required), dashboard_id (required), +1 more. Returns: object
Add an ES|QL table panel to an existing dashboard: show a query's
output columns as a table. columns are the grouping/dimension
columns — one table row per distinct value (e.g. ["status"]);
metric_columns are the numeric value columns shown per row (e.g.
["count"]). esql is the query. It is NOT validated server-side — a
wrong query or column name yields an empty panel, so write them
carefully. For field-based charts use add_panel with a VizSpec.
space targets a Kibana space by id (default: the default space).
Inputs: esql (required), title (required), columns (required), dashboard_id (required), +2 more. Returns: object
Add an ES|QL bar/line/area panel to an existing dashboard:
x_column on the x axis, each of y_columns a plotted series, and an
optional breakdown_column to split each series. esql is the query.
It is NOT validated server-side — a wrong query or column name yields
an empty panel. For field-based charts use add_panel with a VizSpec.
space targets a Kibana space by id (default: the default space).
Inputs: esql (required), title (required), x_column (required), y_columns (required), +4 more. Returns: object
Show a library visualization on an existing dashboard. The panel is linked, not copied: update_visualization changes it on every dashboard.
space targets a Kibana space by id (default: the default space).
Inputs: dashboard_id (required), visualization_id (required), space. Returns: object
Add a visualization panel to an existing dashboard.
space targets a Kibana space by id (default: the default space).
Inputs: panel (required), dashboard_id (required), space. Returns: object
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 status is
created or replaced. Call describe_data_view first to learn real
field names.
space targets a Kibana space by id (default: the default space).
Inputs: title (required), panels (required), space, time_range, +1 more. Returns: object
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.
space targets a Kibana space by id (default: the default space).
Inputs: index_pattern (required), name, space, time_field. Returns: object
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 /s/<space>/goto/<slug> and via
resolve_short_url(slug, space=…). When space is set, pass the app path
WITHOUT a /s/<space> prefix — the space parameter chooses the space,
not the path. A /s/<id>-prefixed path passed without space creates
the slug in the default space.
space targets a Kibana space by id (default: the default space).
Inputs: params (required), locator_id (required), space. Returns: object
Create a reusable visualization in the library (not on a dashboard).
space targets a Kibana space by id (default: the default space).
Inputs: spec (required), space. Returns: object
Get a data view's fields and types. Call this before creating a visualization so you use real field names.
space targets a Kibana space by id (default: the default space).
Inputs: data_view (required), space. Returns: object
Export saved objects (dashboards, data views, …) as an NDJSON file
on the server, and return a summary + an opaque handle — NOT the
content — that you pass to import_saved_objects. Select EITHER types
(e.g. ["dashboard"], or ["*"] for the whole space) OR objects
(a list of {"type":…, "id":…}), not both. This is a sensitive export
surface; what can actually be read is bounded by the API key's
privileges, not by this tool.
space targets a Kibana space by id (default: the default space).
Inputs: space, types, objects, include_references_deep. Returns: object
Get a dashboard summary: title, description, and its panels.
space targets a Kibana space by id (default: the default space).
Inputs: dashboard_id (required), space. Returns: object
Get a library visualization: title, chart type, data view, metrics, group_by and filter query.
space targets a Kibana space by id (default: the default space).
Inputs: visualization_id (required), space. Returns: object
Import a previously-exported set of saved objects, identified by the
handle returned from export_saved_objects, as NEW copies (regenerated
ids — a clone into the current space, not an in-place restore). Existing
objects are never touched. Returns which objects were created (source id
-> new destination id). A missing/expired handle errors. To restore in
place instead, use overwrite_saved_objects (destructive). A handle
carries no space — importing it with space="b" clones its content into
b (new ids), regardless of which space it was exported from.
space targets a Kibana space by id (default: the default space).
Inputs: handle (required), space. Returns: object
List Kibana data views (the datasets you can visualize).
space targets a Kibana space by id (default: the default space).
Inputs: space. Returns: result
Resolve a Kibana short-URL slug to its locator and target app path. (Short URLs are a Technical-Preview API.)
space targets a Kibana space by id (default: the default space).
Inputs: slug (required), space. Returns: object
Search dashboards by title/description. Empty query lists all.
space targets a Kibana space by id (default: the default space).
Inputs: query, space. Returns: result
Search library visualizations (from create_visualization) by title. Empty query lists all.
space targets a Kibana space by id (default: the default space).
Inputs: query, space. Returns: result
Edit an existing data view in place, by id (from list_data_views):
its display name, its index_pattern (e.g. 'logs-*') and/or its
default time_field. Only the fields you pass change. The time field
must be a date field of the view: when you change the index pattern,
the time field (the one you pass, or the current one) is checked
against the NEW pattern's fields, and on a mismatch nothing changes.
A pattern that matches no index yet is accepted, but its time field
cannot be checked (field_count is then 0). A name that defaulted to
the old pattern stays as it is; pass name to change it too. The
time field cannot be removed. Dashboard panels built by this server
keep the pattern and time field they were built with; rebuild one
with update_panel to use the new ones. Returns id, name,
index_pattern, time_field and field_count.
space targets a Kibana space by id (default: the default space).
Inputs: view_id (required), name, space, time_field, +1 more. Returns: object
Replace the visualization at panel_index (see get_dashboard for indexes).
space targets a Kibana space by id (default: the default space).
Inputs: panel (required), panel_index (required), dashboard_id (required), space. Returns: object
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.
space targets a Kibana space by id (default: the default space).
Inputs: spec (required), visualization_id (required), space. Returns: object
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
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.
Access Pollinations models and API capabilities through agent tools.
Discover, compare, route, and execute machine-accessible capabilities for AI agents.
Astra DB tools for agents: schema, find, vector search, guarded writes, and interactive views.
AI Agent Utility Layer for agent safety, web monitoring, crypto research and tool discovery.
