es-error-lens
Allows searching and analyzing Elasticsearch logs in ECS format, providing tools for error search, pattern detection, trend analysis, trace context, and error comparison.
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., "@es-error-lens search errors in the last hour for checkout-api"
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.
es-error-lens
An MCP server that gives LLM agents eyes on your Elasticsearch logs. Point it at a cluster holding ECS-format logs and any MCP client (Claude Desktop, Claude Code, or your own agent) can search errors, detect recurring patterns, analyze error-rate trends, and pull full trace context — the queries an engineer runs by hand during triage, exposed as tools.
Tool | What it answers |
| "What's failing right now?" — filtered by window, service, level |
| "Is this systemic or a one-off?" — message aggregation with occurrence counts |
| "Is it getting worse?" — time-series histogram, peak detection, trend verdict |
| "What led up to this?" — every log sharing the error's trace ID, in order |
| "Are these two failures related?" — attribute + fuzzy-message comparison |
| "Can I even reach the cluster?" |
Elasticsearch is spoken to over its plain REST API via httpx — no
Elasticsearch client dependency, and the HTTP layer is transport-injectable,
so the entire server runs offline against the bundled FakeElasticsearch
for tests and the demo.
Demo (offline, no cluster, no API keys)
git clone https://github.com/TerraCo89/es-error-lens && cd es-error-lens
python -m venv .venv && source .venv/bin/activate # .venv\Scripts\activate on Windows
pip install -e ".[dev]"
pytest # 22 tests, all offline, < 1 second
es-error-lens-demo # synthetic incident walk-throughThe demo mounts FakeElasticsearch with a deterministic 60-document ECS
corpus simulating a small incident — a steady payment-provider failure, an
escalating search-timeout problem, and background noise — then triages it:
[get_error_patterns] 2 recurring patterns in 57 errors:
42x [TimeoutError] Search query timed out after 30s (search-api)
13x [UpstreamHTTPError] Payment provider returned 502 Bad Gateway (checkout-api)
error types: TimeoutError=42, UpstreamHTTPError=13, TemplateError=1, ConnectionResetError=1
[analyze_error_trend] search-api: 42 errors, trend=INCREASING
peak: 8 errors at 2026-07-10T06:00:00Z
[get_error_context] trace-checkout-7f3a -> [UpstreamHTTPError] Payment provider returned 502 Bad Gateway
3 related logs on the same trace:
info POST /checkout started
info Cart validated: 3 items
warn Payment provider latency 4100ms exceeds SLO
Demo result: OKRelated MCP server: Kibana Log Analysis & API Dashboard MCP Server
Using it against a real cluster
export ELASTICSEARCH_URL=http://localhost:9200 # default
export ES_INDEX_PATTERN=logs-* # default
es-error-lens # stdio, for Claude Desktop / Claude Code
es-error-lens --transport streamable-http --port 8080 # HTTP clientsClaude Desktop / Claude Code config:
{
"mcpServers": {
"es-error-lens": {
"command": "es-error-lens",
"env": { "ELASTICSEARCH_URL": "http://localhost:9200" }
}
}
}Expected document shape — standard ECS fields, the ones Filebeat and the
ECS logging libraries emit by default: @timestamp, log.level, message,
service.name, error.type, error.stack_trace, trace.id, host.name.
Anything missing degrades gracefully (fields come back null).
Testing without a cluster
FakeElasticsearch (also exported) implements just enough of the _search
API for this server: bool queries with term/range clauses, sorting,
terms aggregations with top_hits sub-aggregations, and date_histogram
with fixed intervals. Mount it in your own tests:
from es_error_lens import FakeElasticsearch, set_transport, search_errors
set_transport(FakeElasticsearch(my_ecs_docs).transport())
result = await search_errors(time_range="1h", service="checkout-api")The test suite runs entirely through it — deterministic, offline, fast — and
a hygiene test enforces that all bundled demo data stays synthetic (hosts
under .example, no real domains or addresses).
Provenance
Extracted from a personal observability platform where it fronts the Elasticsearch instance that aggregates structured logs from a fleet of side-project services, letting coding agents triage production errors during development sessions. All demo and test data in this repository is synthetic.
License
MIT © 2026 Kris Cernjavic
Available Tools
6 toolsanalyze_error_trendA
Analyze error rate trends over time for a service.
Builds a time-series histogram of error counts to identify spikes, patterns, and direction of travel.
Inputs: service (required), interval, time_range. Returns: object
compare_errorsA
Compare two errors to find similarities and differences.
Useful for judging whether two failures are related or share a root cause.
Inputs: trace_id_1 (required), trace_id_2 (required). Returns: object
get_error_contextA
Get full context for an error using its trace ID (correlation ID).
Retrieves the error and all related logs sharing the same trace ID, providing complete request context for debugging.
Inputs: trace_id (required), include_related. Returns: object
get_error_patternsA
Detect recurring error patterns by aggregating similar error messages.
Groups errors by message and identifies the most common patterns — useful for separating systemic issues from one-off errors.
Inputs: service, time_range, max_patterns, min_occurrences. Returns: object
health_checkA
Check Elasticsearch connection health.
Returns: Dictionary with: - status: "healthy" or "unhealthy" - elasticsearch_url: Configured Elasticsearch URL - cluster_info: Cluster name/version (when healthy)
Inputs: no named parameters. Returns: object
search_errorsC
Search for errors in Elasticsearch logs.
Inputs: service, log_level, time_range, max_results. Returns: object
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
TDQS
Scored across 6 tools
Each tool has a clearly distinct purpose: trend analysis, comparison, context retrieval, pattern detection, health check, and search. No overlapping functionality.
Five tools follow verb_noun pattern (e.g., analyze_error_trend, search_errors); health_check is noun_verb, a minor deviation. Otherwise consistent snake_case.
Six tools is well-scoped for an error analysis server. Each tool contributes a distinct capability without bloat.
Covers error search, trend analysis, pattern detection, context retrieval, comparison, and health check. No obvious gaps for the observation/analysis domain.
Maintenance
Related MCP Connectors
Ingest and search LogsLoom logs from coding agents.
Query application logs, traces, and metrics from your AI coding assistant via Foam's MCP server.
MCP observability. Query live traffic, errors, duration, and alerts from your AI agent.
Query your app's logs, metrics and incidents from your AI assistant.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceEnables LLMs to autonomously query AWS CloudWatch Logs and perform structured root-cause analysis via natural language prompts, using MCP tools for log group listing and Insights queries.MIT
- AlicenseAqualityDmaintenanceEnables AI assistants to search Elasticsearch logs, retrieve log details, analyze service health, scan local codebases for APIs, and create Kibana dashboards.537 npmMIT
- FlicenseNot gradedqualityDmaintenanceRead-only MCP server for Elasticsearch log querying. Enables natural language search, filtering, context retrieval, and aggregation of logs.-
- FlicenseNot gradedqualityBmaintenanceEnables AI agents to query and analyze Graylog logs through MCP tools for search, aggregation, stream listing, and saved queries, with optional OpenAI-powered natural language orchestration and audit logging.-