observability-mcp
About
One MCP server that connects to any observability backend through pluggable connectors, normalizes the data, adds intelligent analysis, and provides a web UI for configuration.
Explore
Setting up with Highlight
This MCP is not yet compatible with Highlight’s one-click setup. However, you can still use it with Highlight by following these steps:
- Download and install Highlight from highlightai.com/download
- Navigate to the plugins tab and select "Add Custom Plugin"
-
Configure the plugin with the settings below
Plugin Name
observability-mcpCommand (node, npx, python, etc.)Please refer to the README for specific instructions on how to obtain API keys or other required environment variables.
- Enable "Start Automatically" if you want the plugin to start when Highlight launches
Claude Desktop / Cursor
Paste into your MCP client config file to install this server.
{
"mcpServers": {
"observability-mcp": {
"server": {
"command": "npx",
"args": [
"-y",
"@thotischner/observability-mcp"
],
"env": {
"MCP_TRANSPORT": "",
"PROMETHEUS_URL": "",
"LOKI_URL": ""
}
}
}
}
}McpServers
{
"server": {
"command": "npx",
"args": [
"-y",
"@thotischner/observability-mcp"
],
"env": {
"MCP_TRANSPORT": "",
"PROMETHEUS_URL": "",
"LOKI_URL": ""
}
}
}Transport
"stdio"Package
"@thotischner/observability-mcp"Registry
"npm"The unified observability gateway for AI agents.
One MCP server that connects to any observability backend through pluggable connectors, normalizes the data, adds robust anomaly analysis, and provides a web UI for configuration.
One MCP endpoint, every backend — so an agent triaging an incident asks one normalized question instead of juggling N vendor servers and their query languages.
0/10 → 10/10:the same 8B local model goes from hallucinating blast-radius answers to exactly correct ones once it gets this gateway's topology tools —measured, not asserted.
npx @thotischner/observability-mcp # start (UI on :3000) claude mcp add observability --transport http http://localhost:3000/mcp # wire into Claude
Twelve read-only tools (readOnlyHint: trueon every one) · server-side filter/aggregate so agents getnumbers, not haystacks·For-Agents guide
📖Full documentation site:https://thotischner.github.io/observability-mcp/
🔌Open in MCP Inspector— one-line interactive explorer:
npx --yes @modelcontextprotocol/inspector \ --config <(npx --yes @thotischner/observability-mcp inspector-config)
On a real Kubernetes-platform-team question ("which other pods share a node withpayment-serviceso we know what else falls over if that node goes down?"), the same local model produces wildly different answers depending on the tools you hand it:
Raw JSON for both arms, plus three more scenarios (single-service RCA, in-namespace blast radius, scenarios where topology doesnothelp), live indocs/benchmark-astronomy-shop.md. The harness is inscripts/benchmark-rca.mjs; re-run withmake benchmark-up && make benchmark-run.
We don't claim universal speedup — the doc spells out exactly where the topology tools help (graph-shaped questions) and where they don't (pure single-metric drill-downs).
npx @thotischner/observability-mcp # then open http://localhost:3000
Wire it into Claude Code with one CLI call:
claude mcp add observability --transport http http://localhost:3000/mcp
…or commit it to your repo as.mcp.json(works the same in Claude Desktop / Cursor):
{ "mcpServers": { "observability": { "transport": { "type": "http", "url": "http://localhost:3000/mcp" } } } }
The server starts withzero sources. Add Prometheus/Loki via the Web UI orPROMETHEUS_URL/LOKI_URLenv vars.
If you'd rather have the snippets above printed by a Make target — including custom-host / custom-port substitution — usemake connect-claude-codeormake connect-cursor.make doctorround-trips a real MCP handshake against a running server, reports the live governance posture (auth mode, redaction, audit-log persistence, per-identity rate cap), and tells you what to fix if it can't.
Multi-user / production?Seedocs/access-control.mdfor the opt-in basic-mode login + RBAC + audit log + per-identity rate limit setup. All off by default; the demo above is unchanged.
SSO via OIDC?make demo-oidcboots a Keycloak + an OIDC-flavored mcp-server on port3001with three pre-provisioned users (admin/operator/viewer, password = username, DEMO ONLY). Seedocs/auth-oidc.mdfor production Keycloak / Authentik / Auth0 / Azure AD setups.
External RBAC via OPA?make demo-opaboots an Open Policy Agent with an example Rego policy + an OPA-backed mcp-server on port3002. Seedocs/policy-engines.mdfor the built-in / file / OPA backend trade-offs and migration paths.
Curated MCP Products?SetOMCP_PRODUCTS_FILEto a YAML catalog (config/products.yaml.example) and ship per-tenant/per-agent tool bundles instead of "everything, all the time". RBAC-gated, audited, hot-editable. Details indocs/products.md.
Want the full chaos-engineering demo (Prometheus + Loki + 3 example services + the autonomous agent)? Clone and run:
make demo # equivalent to: docker compose --profile demo up --build --wait
Or run thesovereign quickstart— one command, fully on-prem, zero external calls: it starts the stack, injects a real incident, and shows side by side what an agent getswithoutvswiththe analysis layer (a wall of raw numbers vs a scored verdict that pinpoints the culprit). The optional agent reasons over it with alocalmodel (Ollama):
Seemake helpfor all canonical workflows.
Every observability vendor ships its own MCP server — Prometheus, Grafana, Datadog, Elastic, each siloed. An AI agent triaging an incident across systems must juggle N separate servers and learn each query language (PromQL, LogQL, …). There is no unified abstraction layer.
observability-mcpis that layer: one MCP endpoint that normalizes every backend and answers in plain service/metric/log terms, plus an analysis engine that flags anomalies the agent would otherwise have to reconstruct from raw queries itself.
Who it's for:SRE / platform teams running Prometheus + Loki who use an AI agent (Claude, local LLMs, …) for incident triage. The gateway's leverage is largest when the agent isnota frontier model — a smaller or local model that can't reliably hand-write PromQL/LogQL benefits most from normalized tools and pre-computed analysis. A strong frontier model can query raw backends competently on its own; there the value is consistency and the analysis engine, not query convenience. We state this honestly rather than claiming a universal speedup.
- 🔍 Inspect — see, learn & enforce agent behavior— a live service-mesh-style graph of every MCP tool call, an AppArmor-style learning workflow that derives a behavior profile from real traffic, and an enforce mode that blocks calls outside the accepted baseline.Jump to Inspect ↓
- Unified gateway— Single MCP endpoint for all your observability backends.
- Cross-signal analysis— Correlates metrics and logs automatically. Robust anomaly detection (median/MAD baseline, trend detection for slow ramps, warmup + dwell to suppress flapping) and weighted health scoring.
- Web UI— Sources, services, health monitoring, configuration. Real-time, dark theme.
- prom-client defaults— Works out of the box with the standard Node.js Prometheus instrumentation. Dynamic label resolution probesjob/service/app/service_nameso service filtering Just Works.
- Loki label fallback— Discovers services throughservice_name/service/job/app/container, including Docker-shipped streams with leading slashes.
- Pluggable connectors— One interface, any query language (PromQL, LogQL, Flux, KQL...). Seedocs/connectors.md.
- Auth & TLS— Basic, Bearer, custom CA, mTLS. See[docs/auth-and-tls.md.
- Multi-backend— Multiple instances of the same type, no problem.
Inspect — see, learn & enforce agent behavior
You handed an agent (or a CI bot, or a leaked credential) a key to your observability backends.Inspectanswers the question RBAC can't:is this callnormalfor this identity, compared to what it has actually been doing?
…
Sign in to leave a review
Use Google, GitHub, or an email account so ratings stay tied to real people.
No reviews posted yet.
