Kibana Log Investigation MCP

Synthetic investigation example

From source discovery to structured query output

This public example uses invented services and counts. It follows the supported flow from source selection to structured results without exposing an operator's logs.

Discover the sources you can trust

Start from named sources instead of hunting through raw Kibana index structure.

Inspect fields before tightening the query

When schema endpoints are available, agents can validate exact-match fields before pushing into grouped or filtered analysis.

Run focused queries that return structured results

Ask for hits, counts, histograms, terms, stats, or grouped top hits. The response keeps the query bounds and filters visible beside the result.

Why it exists

Kibana works for humans. Agents need structure.

Kibana is powerful, but repeatable agent workflows break down when every investigation depends on UI state, local conventions, or one-off wrappers. This MCP adds a structured path on top of the log sources you already expose.

Read-only by design

No writes to Kibana, Elasticsearch, or data views.

Real install paths

Use `npx` directly or the repo-local Codex plugin workflow.

Maintained release path

Install from the package, inspect tagged releases, or review the repo directly.

Built for real investigation workflows

Capabilities that matter during an investigation

Discover sources

Start from logical sources, not raw index details

The operator controls a bounded catalog of sources, names, tags, and field hints. Agents investigate within that catalog instead of starting from raw index details.

Inspect fields

Check exact-match fields before tightening filters

describe_fields helps when the deployment exposes schema metadata. Without it, the rest of the query workflow still works.

Run tighter queries

Move from broad search to grouped, filtered, or statistical output

Query and filter responses include a query_echo with the selected sources, time bounds, filters, and mode, so their scope remains inspectable.

Reuse saved setup

Install once, keep a default machine profile for later threads

Guided setup saves machine-level profile state so new threads do not need a manual configure step just to get back to investigation work.

Install

Choose the path that matches your workflow

Both paths work. Pick the one that matches how you work today. Bootstrap creates an empty catalog. Ask the user which exact Kibana index or index pattern to use. Only then call configure_index with that value.

npx

Best for direct machine setup

npx -y @havesomecode/kibana-mcp-server bootstrap --client codex

Verifies only the Kibana connection, creates an empty catalog, and registers Codex without prompts.

Repo + Codex

Best for repo-local plugin use in Codex

git clone https://github.com/Havesomecode/kibana-mcp-server.git
cd kibana-mcp-server
npm install
npm run build
node dist/src/index.js bootstrap --client none

Install the local plugin, bootstrap a verified profile, and let Codex threads reuse it.

Agent Skill

Best for agent-led installation from skills.sh

npx skills add Havesomecode/kibana-mcp-server --skill kibana-log-investigation --agent codex --global --yes

Teaches the agent to ask for an exact index before calling configure_index.

View npm package Open INSTALL.md

Environment notes

What to expect in your environment

The main workflow works across deployments. Some features depend on schema metadata being exposed.

What it handles well

Read-only source discovery, field inspection, exact-field filtering, and structured queries over Kibana-backed logs.

What it will not do

It does not write to Kibana or Elasticsearch, and it does not try to turn log investigation into a broader automation product.

What depends on your setup

Schema-aware features depend on the deployment. If metadata endpoints are blocked, those features may be limited or unavailable.

README INSTALL Support policy GitHub Releases

Ready to use it?

Install it or inspect the repo

Use the package Open the repository