Skip to content

Read-onlyModel Context Protocolstdio & HTTP

Kibana MCP ServerStructured Kibana investigations for agents and teams

A read-only MCP server that turns Kibana logs into sources an agent can discover, fields it can inspect and results it can read.

investigation tools
5
query modes
6
catalog stores
5
Synthetic investigation example
  1. discover{ "query": "checkout" }
    app-logs · Application logs · time_field=@timestamp
  2. describe_fields{ "source_id": "app-logs", "query": "service" }
    service.name (keyword, aggregatable)
  3. query{ "mode": "histogram", "text": "timeout", "histogram_interval": "5m" }
    412 matches, 318 of them between 12:25 and 12:35
agent

Get started

Connect it, name an index, investigate ​

Bootstrap verifies the connection and registers the server. It does not pick an index. The agent follows one rule: "Ask the user which exact Kibana index or index pattern to use." Only then does it call configure_index with that value.

bash
export KIBANA_BASE_URL='https://kibana.example.com'
export KIBANA_USERNAME='elastic'
export KIBANA_PASSWORD='use-a-secret-provider'

npx -y @havesomecode/kibana-mcp-server bootstrap --client codex
bash
npx skills add Havesomecode/kibana-mcp-server --skill kibana-log-investigation
bash
# One process for every caller of your gateway, each with their own catalog
kibana-mcp-server serve --http --config ./kibana.mcp.config.ts

Why this server

Kibana works for people. Agents need structure. ​

Sources, not raw indexes

An operator exposes a short catalog of named sources. The agent starts there instead of wandering through every index of the cluster.

Fields before filters

The agent sees which fields exist and which ones match exactly, so a filter on service.name means what it says.

Results it can reason about

Hits, counts, histograms and statistics come back typed. Query and filter responses include a query_echo of what was actually searched.

Nothing happens by accident

No source is configured until a person names the index, and nothing is ever written to Elasticsearch or Kibana.

Choose your path

Local tool or shared service ​

stdio · one caller

A local tool

agentserverKibana

  • Bootstrap it from Codex or any MCP client, in one command.
  • Credentials stay in the secret store of your operating system.
  • Also runs from a cloned repository (Repo + Codex).

Getting startedWork from a clone

HTTP · many callers

A shared service

agentsgatewayserverKibana

  • One process behind your gateway serves the whole team.
  • Each caller gets a source catalog of their own.
  • Catalogs live in Redis, PostgreSQL, MongoDB, SQLite or files.

HTTP transportIntegration examples

Looking for a tool input or an option? Go to the reference. Schema-aware features depend on the deployment: when Kibana does not expose field metadata, fields are sampled through search instead.

Built for agents

Documentation and tooling your agent can use ​

Docs as Markdown

The whole site is published for language models: an llms.txt index, one full file, and a Markdown twin of every page.

Plugin marketplaces

Install the skill and the MCP server together from the Claude Code marketplace, or register it in Codex with one command.

A skill for any agent

The investigation workflow and its safety rules, installable with skills.sh for Cursor, Gemini CLI and others.

Thank you

Built by these people ​

Every commit to the repository earns a place on this wall.

Released under the MIT License. Independent project, not affiliated with or endorsed by Elastic. Kibana and Elasticsearch are trademarks of Elasticsearch B.V.