list_sourcesLABSCO SUMMARY
Numbers instead of haystacks, and a graph instead of a guess.
The topology pair is what you cannot get from a per-vendor server: blast radius is a graph question, and the README is candid that these tools help graph-shaped questions and do not help pure single-metric drill-downs. The anomaly engine is backtested in CI against a 64-case labelled suite at 100% precision and 87.5% recall, so the alerts it raises are not noise — the misses are at the noise floor by design.
What it is
A gateway that sits between an agent and your observability stack. Instead of a separate server and query language per vendor, it exposes one normalized surface, computes summaries and anomaly analysis server-side, and ships a web UI on port 3000 for wiring up sources. Every tool is marked read-only.
What you get
- Discovery —
list_sourcesfor configured backends and their connection status,list_servicesfor everything monitored across them query_metricsandquery_logs, both returning pre-computed summary stats and top error patterns rather than raw series the agent has to reduce itselfget_service_health— one score from 0 to 100 combining metrics and logsdetect_anomalies— cross-signal detection on a median/MAD baseline with trend detection for slow ramps and dwell time to stop flappingget_topologyfor the merged infrastructure graph, andget_blast_radius, which pivots on theRUNS_ONrelation to answer "if this host fails, who else fails?" for pod-to-node, vm-to-hypervisor and container-to-host- A
raw_queryargument onquery_metricsandquery_logsas an escape hatch for hand-written PromQL or LogQL — off by default, enabled globally withOMCP_RAW_QUERYor per credential - Every tool read-only, plus triage and postmortem prompts and an agent usage guide served as an MCP resource
- Log redaction on
query_logsoutput before it reaches the agent, and an Inspect view that graphs which identity called which tool against which backend
Requirements
No account. Node 20+, or just npx @thotischner/observability-mcp — it starts with zero sources and the web UI on http://localhost:3000. Point it at your backends with PROMETHEUS_URL and LOKI_URL, or add them through the UI, or write ~/.observability-mcp/sources.yaml for auth-bearing sources such as Grafana Cloud. Clients connect over Streamable HTTP at /mcp; stdio-only clients run it with --stdio or MCP_TRANSPORT=stdio. Also published as a multi-arch image at ghcr.io/thotischner/observability-mcp and as a Helm chart. Apache 2.0.
Setup effort
One command — npx @thotischner/observability-mcp
USE CASES
Working out what a failing node takes down with it
Pivot on the host relation and get the co-tenant list, instead of asking a model to infer it from metric labels.
Triaging an incident across metrics and logs at once
Run cross-signal anomaly detection and read the health score, rather than opening two dashboards and correlating by eye.
Giving a small local model a chance
Normalized tools remove the need to hand-write PromQL or LogQL, which is where non-frontier models fall down.
Letting an agent read logs without reading secrets
Redaction masks PII and secret patterns before the log output reaches the model.
11 tools
Listed in project docs. Your client may show a different list.
list_servicesquery_metricsquery_logsquery_tracesget_service_healthdetect_anomaliesget_anomaly_historyget_topologyget_blast_radiusenrich_ipsBEFORE YOU INSTALL
What to know first
Tools you get
11 tools named in the project's documentation.
Requires
npx on PATH
INSTALLATION
Connect your client
Server setup
npx @thotischner/observability-mcpMCP Clients
Claude Code
{
"mcpServers": {
"observability": {
"type": "http",
"url": "http://localhost:3000/mcp"
}
}
}Cursor
{
"mcpServers": {
"observability": {
"url": "http://localhost:3000/mcp"
}
}
}Any MCP client — stdio
npx @thotischner/observability-mcp --stdioMCP Inspector — test run
npx --yes @modelcontextprotocol/inspector \
--config <(npx --yes @thotischner/observability-mcp inspector-config)