Provides access to query Elasticsearch data through Kibana's API, enabling log searches and data retrieval with support for custom queries, sorting, and filtering.
Enables AI assistants to interact with Kibana dashboards, visualizations, data views, and saved searches, with tools for executing searches, exporting dashboards, and querying Elasticsearch data through Kibana's REST API.
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., "@Kibana MCP Server show me the top 5 error logs from the last hour"
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.
A Model Context Protocol (MCP) server that enables AI assistants to interact with Kibana dashboards, visualizations, and Elasticsearch data through a standardized interface.
Resources: Read-only access to Kibana dashboards, visualizations, data views, and saved searches
Tools: Execute searches, export dashboards, and query Elasticsearch data
Dual Transport: Supports both stdio (local) and HTTP/SSE (containerized) transports
Docker Support: Production-ready containerization with Docker and Podman
Authentication: API key and username/password authentication
Type-Safe: Built with TypeScript for enhanced reliability
Related MCP server: kibana-mcp
┌─────────────────┐
│ AI Assistant │
│ (Claude, etc.) │
└────────┬────────┘
│ MCP Protocol
│
┌────────▼────────┐ ┌─────────────┐
│ MCP Server │─────▶│ Kibana │
│ (This Server) │ │ REST API │
└─────────────────┘ └──────┬──────┘
│
┌──────▼──────┐
│Elasticsearch│
└─────────────┘Docker Compose is the preferred way to run this server. Credentials are passed via shell environment variables so nothing is hard-coded.
Export your Kibana credentials (API key or username/password):
# Option A: API key
export KIBANA_API_KEY=your_api_key_here
# Option B: Username/password
export KIBANA_USERNAME=your_username
export KIBANA_PASSWORD=your_passwordBuild and start:
docker compose up --build -dVerify it's running:
curl http://localhost:3000/healthView logs / stop:
docker compose logs -f
docker compose downThe KIBANA_URL defaults to https://localhost:5601 and can be overridden:
export KIBANA_URL=https://your-kibana-instance.comInstall dependencies:
npm installConfigure environment:
cp .env.example .env
# Edit .env with your Kibana credentialsRun in development mode:
# Stdio mode (for Claude Desktop)
npm run dev
# HTTP mode (for testing)
npm run dev:httpBuild and run production:
npm run build
npm start # stdio mode
npm start:http # HTTP modeCreate a .env file based on .env.example:
# Kibana Configuration (required)
KIBANA_URL=https://your-kibana-instance.com
KIBANA_API_KEY=your_api_key_here
# Alternative: Username/Password Authentication
# KIBANA_USERNAME=your_username
# KIBANA_PASSWORD=your_password
# Server Configuration
MCP_TRANSPORT=http # or stdio
HTTP_PORT=3000 # Port for HTTP server
LOG_LEVEL=info # debug, info, warn, errorAPI Key (Recommended):
KIBANA_URL=https://kibana.example.com
KIBANA_API_KEY=your_base64_encoded_api_keyUsername/Password:
KIBANA_URL=https://kibana.example.com
KIBANA_USERNAME=admin
KIBANA_PASSWORD=your_passwordkibana://dashboards - List all dashboards
kibana://dashboard/{id} - Get specific dashboard
kibana://visualizations - List all visualizations
kibana://data-views - List all data views
kibana://saved-searches - List saved searches
list_dashboardsList dashboards with optional search and pagination.
{
"search": "security",
"page": 1,
"perPage": 20
}get_dashboardGet detailed information about a specific dashboard.
{
"id": "dashboard-id-here"
}export_dashboardExport dashboard with all dependencies.
{
"id": "dashboard-id-here",
"includeReferences": true
}search_logsQuery Elasticsearch data through Kibana.
{
"index": "logs-*",
"query": {
"match": {
"message": "error"
}
},
"size": 10,
"sort": [{"@timestamp": "desc"}]
}list_visualizations - List visualizations
get_visualization - Get visualization details
list_data_views - List available data views
This server supports two transports. They share the same core server logic (src/server.ts) but differ in how the client communicates with it:
HTTP/SSE ( | stdio ( | |
How it works | Long-running HTTP server. Clients connect via Server-Sent Events (SSE) and send JSON-RPC over POST requests. | Client spawns the server as a child process. JSON-RPC messages flow over stdin/stdout. |
When to use | Remote/containerized deployments, Claude Code, any network-based MCP client | Local-only usage, Claude Desktop app |
Run with |
|
|
Entry point |
|
|
Claude Code connects to MCP servers over SSE. Start the HTTP server first, then register it with Claude Code.
# Start the server
docker compose up -d
# Add as a user-scoped MCP server
claude mcp add --scope user --transport sse kibana http://localhost:3000/sse.mcp.json)Create .mcp.json in your project root (shared with the team via version control):
{
"mcpServers": {
"kibana": {
"type": "sse",
"url": "http://localhost:3000/sse"
}
}
}Verification: In Claude Code, type /mcp to see available servers. You should see "kibana" listed with its resources and tools.
For the Claude Desktop app, use stdio transport.
Add to your Claude Desktop configuration (~/Library/Application Support/Claude/claude_desktop_config.json on macOS):
{
"mcpServers": {
"kibana": {
"command": "node",
"args": ["/path/to/jb-kibana-mcp/dist/index.js"],
"env": {
"KIBANA_URL": "https://your-kibana.com",
"KIBANA_API_KEY": "your-api-key"
}
}
}
}Any MCP client that supports SSE transport can connect to:
http://localhost:3000/sseThe SSE handshake flow:
Client opens GET /sse — receives an endpoint event with a session-specific message URL
Client sends JSON-RPC messages via POST /message?sessionId=<id>
Server streams responses back over the SSE connection
Additional endpoints:
GET /health — Health check (returns JSON status)
GET /info — Server metadata and capabilities
docker build -t kibana-mcp:latest .docker run -d \
--name kibana-mcp \
-p 3000:3000 \
-e KIBANA_URL=https://your-kibana.com \
-e KIBANA_API_KEY=your-api-key \
kibana-mcp:latest# Start
docker compose up -d
# View logs
docker compose logs -f
# Stop
docker compose downjb-kibana-mcp/
├── src/
│ ├── index.ts # Stdio transport entry point (Claude Desktop)
│ ├── http-server.ts # HTTP/SSE transport entry point (Claude Code, Docker)
│ ├── server.ts # Core MCP server logic
│ ├── kibana/
│ │ ├── client.ts # Kibana API client
│ │ ├── types.ts # TypeScript types
│ │ └── auth.ts # Authentication
│ ├── resources/
│ │ └── index.ts # MCP resources
│ └── tools/
│ └── index.ts # MCP tools
├── Dockerfile
├── docker-compose.yml
└── package.jsonDefine the tool schema in src/tools/index.ts
Implement the handler in the tools/call request handler
Add corresponding Kibana client method if needed
Unit tests (no external dependencies, mocked Kibana):
npm test # run once
npm run test:watch # watch mode
npm run test:coverage # with coverage reportIntegration tests (require a live Kibana instance):
Integration tests start an in-process MCP server, connect over SSE, and exercise
every tool and resource against real Kibana. They are kept separate from unit
tests so npm test stays fast and offline.
Set environment variables — the tests load .env via dotenv, so values
already in .env (like KIBANA_URL) are picked up automatically. Shell
environment variables take precedence. You need:
# Already in .env:
KIBANA_URL=https://your-kibana-instance.com
# Set in your shell (or add to .env):
export KIBANA_API_KEY=your-api-key
# — or —
export KIBANA_USERNAME=you@example.com
export KIBANA_PASSWORD=your-passwordRun:
npm run test:integrationIf KIBANA_URL or credentials are missing, the tests skip automatically
(no failures).
What the integration tests cover:
Area | Tests |
MCP handshake | SSE connect, initialize, initialized notification |
| All 7 tools registered |
| All 4 resources registered |
| Pagination, search filtering |
| Fetch by ID |
| NDJSON export with references |
| Listing |
| Fetch by ID |
| Listing |
| match_all, size limits, sort |
| Read dashboards, data-views, dashboard by ID |
Error handling | Nonexistent dashboard, unknown tool |
Manual testing:
# Health check
curl http://localhost:3000/health
# Server info
curl http://localhost:3000/info
# Test with MCP Inspector
npx @modelcontextprotocol/inspector dist/index.jsContainer Isolation: Runs as non-root user (mcpuser)
Minimal Base Image: Uses node:20-slim to reduce attack surface
Secret Management: Environment variables for credentials
API Authentication: Supports API keys and basic auth
RBAC: Respects Kibana's role-based access control
# Check if Kibana is accessible
curl -I https://your-kibana.com/api/status
# Verify authentication
curl -H "Authorization: ApiKey YOUR_KEY" \
-H "kbn-xsrf: true" \
https://your-kibana.com/api/status# View logs
docker logs kibana-mcp-server
# Shell into container
docker exec -it kibana-mcp-server /bin/sh
# Rebuild without cache
docker compose build --no-cacheA GitHub Actions workflow runs on every pull request targeting main and on pushes to main. It builds the project and runs unit tests across Node.js 20 and 22. See .github/workflows/ci.yml.
Contributions are welcome! Please follow these guidelines:
Use TypeScript for all new code
Follow existing code style
Add tests for new features
Update documentation
Ensure CI passes — the build and unit tests must succeed before merging
MIT
Export a dashboard with all its dependencies (visualizations, data views, etc.)
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Dashboard ID to export | |
| includeReferences | No | Include all referenced objects (default: true) |
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 mentions exporting with dependencies but doesn't cover critical aspects like output format (e.g., file type, download method), permissions required, whether it's a read-only or destructive operation, or any rate limits. This leaves significant gaps for an agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It front-loads the core action and resource, and every word earns its place by specifying the scope ('with all its dependencies'). No unnecessary details or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of an export operation with no annotations and no output schema, the description is incomplete. It lacks information on what the export produces (e.g., a file, JSON), how to handle the output, permissions, or error conditions. For a tool that likely involves data transformation and output, this is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 both parameters ('id' and 'includeReferences') thoroughly. The description adds no additional meaning beyond what the schema provides, such as clarifying dependency types or export implications. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Export') and resource ('a dashboard'), including the scope of dependencies. It distinguishes from sibling tools like 'get_dashboard' or 'list_dashboards' by specifying an export operation rather than retrieval. However, it doesn't explicitly differentiate from potential export-related siblings if they existed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing the dashboard ID), exclusions, or comparisons to sibling tools like 'get_dashboard' for viewing instead of exporting. Usage is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific dashboard
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Dashboard ID |
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 states the tool retrieves 'detailed information,' which implies a read-only operation, but doesn't specify what 'detailed' includes, whether it requires authentication, potential rate limits, or error handling. This is a significant gap for a tool with no structured safety hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that directly states the tool's function without any unnecessary words. It is front-loaded with the core purpose, making it efficient and easy to parse, which is ideal for an AI agent selecting tools.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 is insufficient. It doesn't explain what 'detailed information' includes in the return value, nor does it cover behavioral aspects like permissions or errors. Given the complexity of retrieving dashboard data, more context is needed to guide the agent effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'id' parameter documented as 'Dashboard ID.' The description adds no additional semantic context beyond this, such as format examples or where to obtain the ID. Given the high schema coverage, a baseline score of 3 is appropriate, as the schema handles the parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get') and resource ('detailed information about a specific dashboard'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'list_dashboards' or 'get_visualization', which would require mentioning it retrieves a single dashboard by ID rather than listing multiple or fetching visualization data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention that 'list_dashboards' should be used for listing multiple dashboards or that 'get_visualization' is for visualization-specific data, nor does it specify prerequisites like needing a dashboard ID. This leaves the agent to infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific visualization
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Visualization ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a 'get' operation which implies read-only behavior, but doesn't specify authentication requirements, rate limits, error conditions, or what format the 'detailed information' returns. The description adds minimal behavioral context beyond the basic operation type.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point without unnecessary words. It's appropriately sized for a simple retrieval tool, though it could potentially be more specific about what 'detailed information' includes to be more helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 is insufficiently complete. It doesn't explain what information is returned, error handling, authentication needs, or how this tool fits into the broader visualization/dashboard ecosystem with its siblings. The description leaves too many behavioral questions unanswered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage with the single parameter 'id' clearly documented as 'Visualization ID'. The description doesn't add any parameter semantics beyond what the schema already provides, but with complete schema coverage, the baseline score of 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'Get detailed information about a specific visualization' clearly indicates a retrieval operation with a specific target, but it's somewhat vague about what 'detailed information' entails. It distinguishes from list_visualizations by focusing on a single item, but doesn't explicitly contrast with get_dashboard or other siblings beyond the resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. While it's implied this is for retrieving a single visualization when you have its ID, there's no mention of when to choose this over list_visualizations or how it relates to get_dashboard, export_dashboard, or other sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all Kibana dashboards with optional search filtering
| Name | Required | Description | Default |
|---|---|---|---|
| search | No | Optional search term to filter dashboards by title | |
| page | No | Page number for pagination (default: 1) | |
| perPage | No | Number of results per page (default: 20, max: 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'optional search filtering' but doesn't disclose important behavioral traits like whether this is a read-only operation, what permissions are needed, whether results are paginated (implied by parameters but not stated), or what the return format looks like. The description is minimal and lacks behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's appropriately sized and front-loaded with the core purpose, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a tool with 3 parameters and list functionality. It doesn't explain what the tool returns (dashboard objects, IDs, metadata?), doesn't mention authentication or rate limits, and provides minimal behavioral context. For a list tool with zero structured coverage, this is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents all three parameters. The description adds no additional parameter semantics beyond what's in the schema (e.g., doesn't explain search syntax or pagination behavior). Baseline 3 is appropriate when schema does all the work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List all Kibana dashboards') and resource ('Kibana dashboards'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'get_dashboard' or 'list_visualizations', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through 'optional search filtering' but doesn't explicitly state when to use this tool versus alternatives like 'get_dashboard' (for single dashboard details) or 'search_logs' (for different resource types). No explicit when-not or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all data views (index patterns) in Kibana
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 states this is a listing operation, implying it's likely read-only and non-destructive, but doesn't confirm this or add any context about permissions, rate limits, pagination, or return format. This leaves significant gaps for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without any wasted words. It's appropriately sized for a simple listing tool with no parameters, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is minimally adequate. It states what the tool does but lacks behavioral details and usage guidance. For a basic listing operation, this might suffice, but the absence of annotations means more context would be helpful for reliable agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, and since there are none, it doesn't need to compensate for any gaps, earning a baseline score above the minimum.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List all') and resource ('data views (index patterns) in Kibana'), making the purpose immediately understandable. However, it doesn't differentiate this tool from sibling tools like 'list_dashboards' or 'list_visualizations' beyond naming the specific resource type, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context for selecting this over other listing tools, or any exclusions, leaving the agent to infer usage based solely on the tool name and resource type.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all Kibana visualizations
| Name | Required | Description | Default |
|---|---|---|---|
| search | No | Optional search term to filter visualizations by title | |
| page | No | Page number for pagination (default: 1) | |
| perPage | No | Number of results per page (default: 20, max: 100) |
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 states the action ('List') but doesn't mention whether this is a read-only operation, if it requires authentication, what the output format looks like, or any rate limits. For a listing tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core purpose and appropriately sized for a straightforward listing tool, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (a simple list operation) and the schema's full parameter coverage, the description is minimally adequate. However, without annotations or an output schema, it fails to explain what the returned data looks like (e.g., structure, fields) or any behavioral nuances, leaving room for improvement in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, clearly documenting all three parameters (search, page, perPage) with their types, defaults, and constraints. The description adds no additional parameter information beyond what the schema provides, so it meets the baseline for adequate but not exceptional coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('all Kibana visualizations'), making the purpose immediately understandable. However, it doesn't distinguish this tool from its sibling 'get_visualization' (singular vs. plural), which suggests a potential overlap in functionality that isn't clarified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get_visualization' or 'list_dashboards'. It lacks any context about prerequisites, typical use cases, or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Elasticsearch data through Kibana using Elasticsearch query DSL
| Name | Required | Description | Default |
|---|---|---|---|
| index | Yes | Index pattern or name to search | |
| query | No | Elasticsearch query DSL (e.g., {"match_all": {}} or {"term": {"field": "value"}}) | |
| size | No | Number of results to return (default: 10, max: 100) | |
| from | No | Starting offset for pagination (default: 0) | |
| sort | No | Sort specification (e.g., [{"@timestamp": "desc"}]) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It mentions using Elasticsearch query DSL but doesn't cover critical aspects like authentication requirements, rate limits, error handling, or what happens on execution (e.g., whether it's read-only or has side effects). For a search tool with complex parameters, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function. It's front-loaded with the core action and avoids unnecessary words. However, it could be slightly more structured by explicitly separating purpose from context or constraints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, nested objects, no output schema, and no annotations), the description is incomplete. It doesn't explain return values, error conditions, or behavioral traits like pagination or query limitations. For a search tool with rich input schema but no output schema, more context is needed to guide effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 parameters thoroughly. The description adds minimal value beyond the schema by mentioning 'Elasticsearch query DSL' and 'Kibana', but doesn't provide additional syntax, format details, or examples beyond what's in the schema descriptions. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Search') and target resource ('Elasticsearch data through Kibana'), making the purpose evident. However, it doesn't differentiate this tool from its siblings (like list_data_views or get_dashboard), which are related but distinct operations. The description is specific but lacks sibling comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing valid indices or query knowledge), exclusions, or comparisons to sibling tools like list_data_views for browsing available indices. Usage context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0export_dashboardget_dashboardget_visualizationlist_dashboardslist_data_viewslist_visualizationssearch_logsScored across 7 tools
Most tools have distinct purposes targeting specific Kibana resources like dashboards, visualizations, data views, and logs. However, get_dashboard and get_visualization are structurally similar (both retrieve details), which could cause minor confusion if an agent needs to differentiate between resource types without clear context. The other tools are well-separated by action and resource.
All tools follow a consistent verb_noun naming pattern using snake_case (e.g., list_dashboards, get_visualization, search_logs). The verbs (export, get, list, search) are appropriately chosen for their actions, and there are no deviations in style or convention throughout the set.
With 7 tools, this server is well-scoped for Kibana operations, covering key areas like dashboards, visualizations, data views, and log searches. Each tool serves a clear purpose without redundancy, making the count appropriate for the domain and not overwhelming for agents to navigate.
The toolset covers listing and getting resources, plus exporting dashboards and searching logs, but lacks CRUD operations for creating, updating, or deleting dashboards, visualizations, or data views. This is a notable gap that could limit agents from performing full lifecycle management, though basic retrieval and search workflows are supported.
Query your team's drift, vulnerability, and upgrade data from any AI assistant. OAuth 2.1, 51 tools.
Read and write KukGit repositories, files, issues and pull requests from an AI assistant.
Read-only AI access to HAVN properties, leads, tasks, files, media, and analytics.
Read-only finance and operations controls for AI agents with evidence and safe next actions.
