Reported issues for observability-mcp
Pod holds 15 of 15 problems reported by people outside the maintainer team. Issues filed by the project's own owners, members and collaborators are excluded entirely — a maintainer's release checklist is not a warning to a prospective user.
Back to observability-mcp.
Most discussed
Agent usability: label-filtered + aggregated log queries, PromQL/LogQL passthrough, env filter
Context
Feedback from real-world use of observability-mcp v1.3.2 by an AI coding agent (Claude) driving an incident/traffic investigation against a Prometheus + Loki backend (Node/Express app, JSON access logs with extracted labels ip, method, status, url, tenant, environment).
The curated tools (query_metrics, detect_anomalies, get_service_health) are genuinely good for "is anything wrong / is it trending". The gaps below all surfaced while answering analytics-style
Read the thread · 2026-06-08 · closed · 8 comments
query_logs: count_over_time inherits high-cardinality labels; raw_query vector aggregations crash
Tested on 3.3.0 (Loki connector, Grafana Cloud). Two reproducible query_logs issues that together force a fallback to raw log parsing for "traffic over time".
1. aggregate: count_over_time returns per-request series instead of clean buckets
Repro:
query_logs { service, duration: "6h",
labels: { environment: "prod", url: "/" },
aggregate: { op: "count_over_time", step: "1h" } }
→ 12 series, each carrying the full | json label set (rid, ip, size, ms, status, …)
Read the thread · 2026-06-10 · closed · 4 comments
Prometheus: query_metrics returns empty/zero for app-exposed prom-client metrics
Problem
When an app exposes standard prom-client HTTP metrics on /metrics (e.g. http_requests_total, http_request_duration_seconds, custom counters like unhandled_error_total), query_metrics returns either empty time-series or all-zero samples for the synthetic metric names (request_rate, error_rate, latency_p99, latency_avg, latency_p50).
Repro: scrape job is up, target is healthy, raw /metrics produces real counters that increment under load — but `query_metrics(se
Read the thread · 2026-05-01 · closed · 3 comments
query_metrics zero-fills summary for no-data services (the #453A no-data principle, not yet applied here)
Gateway version
3.3.1 (serverInfo.version). Connectors: konfigurator-prom (Prometheus), konfigurator-loki (Loki). Sibling finding to #453A — which you fixed beautifully for get_service_health (honest no-data/unknown instead of false 0). query_metrics still zero-fills the same situation.
Exact call + repro
konfigurator-app is a logs-only service (per list_services, signalTypes:[logs]), so it has no cpu/latency_p99 metric:
query_metrics { service: "konfigur
[Read the thread](https://github.com/ThoTischner/observability-mcp/issues/462) · 2026-06-11 · closed · 2 comments
### initialize.instructions is empty — the agent-usage guide reaches the agent via no auto-injected channel
## Gateway version
`3.3.0` (serverInfo.version from MCP initialize). This is a meta-issue about the discoverability of the excellent ax surface shipped in 3.3.0 (#444/#448/#449), not about any single tool's behaviour.
## The gap
3.3.0 added a genuinely good agent-usage guide as MCP resource `omcp://guide/agent-usage` and as `/llms.txt`. But neither channel is auto-consumed by an agent at connect time, and the one channel that **is** auto-injected is left empty:
| Channel | Auto-loaded into age
[Read the thread](https://github.com/ThoTischner/observability-mcp/issues/455) · 2026-06-10 · closed · 2 comments
### Loki: fallback label discovery for query_logs and list_services
## Problem
`query_logs` and `list_services` currently rely on a single label (assumed `service_name`) to identify Loki streams. Streams shipped by setups that only carry alternative identifying labels (e.g. `container`, `service`, `job`, `app`) are invisible:
- `list_services` returns 0 log-services even though Loki has data.
- `query_logs(service="<container-name>")` returns 0 entries.
This makes historical logs from environments that pre-date a `service_name` label completely unreachable th
[Read the thread](https://github.com/ThoTischner/observability-mcp/issues/13) · 2026-05-01 · closed · 2 comments
### enrich_ips (RDAP): rate-limited lookups silently return found:false, indistinguishable from a true negative
### Gateway version
3.7.0 (`ghcr.io/thotischner/observability-mcp:3.7.0`)
### Observed tool surface
```json
{
"name": "enrich_ips",
"params": { "ips": ["<ipv4|ipv6>", "..."] },
"result_fields": {
"results[].found": "bool",
"results[].via": "rdap",
"results[].country": "string?",
"results[].org": "string?",
"summary": { "total": 0, "matched": 0, "unmatched": 0, "viaRdap": 0 },
"rdapEnabled": true,
"datasetSize": 0
}
}
Operator config: `OMCP_IP_ENRICH_RD
Read the thread · 2026-06-23 · closed · 1 comment
feat(enrich_ips): optional online RDAP backend for non-air-gapped deployments
What
Add an opt-in online IP-enrichment path using RDAP (modern WHOIS, RFC 9082) as an alternative to the offline OMCP_IP_ENRICH_FILE dataset, for deployments that aren't air-gapped.
Why — agent-usage finding
enrich_ips today requires an offline CSV built from a licensed MaxMind GeoLite2 export (account + license key + download + convert + mount). That's the right design for air-gapped/security deployments, but for the common non-air-gapped operator it's a lot of ceremony
Read the thread · 2026-06-11 · closed · 1 comment
Most recent
enrich_ips IPv6 works but the tool description/schema still advertises 'IPv4 addresses' only (3.4.0)
Gateway version
3.4.0 (serverInfo.version). Re: #469 (enrich_ips IPv6 support). The handler works — but the agent-facing description wasn't updated, so an agent can't tell IPv6 is supported. Same shape as the original #415 schema-advertise gap.
Verified: IPv6 lookup works
Configured a minimal CSV (network,country,city,asn,org,hosting) with an IPv6 CIDR and called the tool. All IPs below are RFC 5737 / RFC 3849 documentation ranges:
enrich_ips { ips: ["198.51.100.10", "2001
[Read the thread](https://github.com/ThoTischner/observability-mcp/issues/476) · 2026-06-11 · closed · 1 comment
### get_service_health + detect_anomalies report "healthy" for services with no metrics (incl. nonexistent ones)
## Gateway version
`3.3.0` (serverInfo.version from MCP initialize). Connectors: `konfigurator-prom` (Prometheus, up), `konfigurator-loki` (Loki, up). This deployment has **metrics and logs backends but no per-service metrics for the log-only app** — a very common Prom+Loki setup.
## Observed tool surface
`list_services` returns 3 services with explicit signal types:
integrations/unix sources:[konfigurator-prom] signalTypes:[metrics] prometheus.scrape.app sources:[konfigurato
Read the thread · 2026-06-10 · closed · 1 comment
Web UI: MCP endpoint URL is hardcoded to localhost:3000
Problem
The MCP endpoint URL shown in the web UI is hardcoded to http://localhost:3000/mcp in mcp-server/src/ui/index.html (line ~530):
<span>MCP Endpoint: <strong id="mcp-url">http://localhost:3000/mcp</strong></span>
When the server is accessed through an ingress or reverse proxy (e.g. https://observability-mcp.example.com), the displayed URL is incorrect and confusing — use
Read the thread · 2026-05-15 · closed · external user · 1 comment
Config loader substitutes ${VAR} placeholders inside YAML comments
Summary
substituteEnv() in the config loader scans the entire sources.yaml file as text and warns/substitutes on every ${...} it finds — including occurrences inside #-prefixed YAML comments. Comments are documentation, not config, and shouldn't trigger substitution or warnings.
Reproduction
sources.yaml:
# Note: ${VAR}-style substitution is resolved at runtime from .env.
sources:
- name: example
type: prometheus
url: "${PROM_URL}"
enabled: true
Sta
Read the thread · 2026-05-02 · closed · 1 comment
v1.3.0: 'Already connected to a transport' crash on reconnect (regression vs 1.2.2)
Summary
Running ghcr.io/thotischner/observability-mcp:1.3.0 crashes the Node process the moment a client reconnects to the /mcp HTTP endpoint. v1.2.2 with the same config does not.
Reproduction
- Start the container (HTTP transport, default config, any working source set).
- Connect any MCP client to
http://<host>:3000/mcp. First connection works. - Disconnect and reconnect — or let the client reopen the session for any reason.
- Server throws and exits.
Stack trace
f
[Read the thread](https://github.com/ThoTischner/observability-mcp/issues/16) · 2026-05-02 · closed · 1 comment
### query_metrics: support per-instance / groupBy breakdown for multi-target services
## Problem
`query_metrics` returns a single aggregated time-series per call. For services that are scraped on multiple hosts/VMs (or any setup with more than one `instance` behind the same `job`/service label), this collapses everything into one number with no way to tell the targets apart.
Concrete case: a service is scraped on two VMs (dev + prod). Both contribute to the same `job` label. The MCP returns one CPU curve and one memory curve, but no way to know which VM the value came from — or
[Read the thread](https://github.com/ThoTischner/observability-mcp/issues/15) · 2026-05-01 · closed · 0 comments
### Grafana Cloud (Mimir/managed Loki) Inkompatibilität: Health-Checks + listServices
## TL;DR
Drei Endpoints im Connector-Code zielen auf Pfade, die nur **Self-Hosted Prometheus/Loki** exponieren. Auf **Grafana Cloud (Mimir + managed Loki)** — und vermutlich auch AWS Managed Prometheus, Chronosphere etc. — antworten diese Pfade mit `404`.
Konsequenzen für Nutzer mit managed Backends:
- `Sources`-Page zeigt dauerhaft `❌ down`, obwohl Auth + URL korrekt sind
- `list_services` schlägt fehl (Prometheus-Connector); Loki-Variante funktioniert eigentlich
- Erstnutzer denken, ihr Setu
[Read the thread](https://github.com/ThoTischner/observability-mcp/issues/12) · 2026-05-01 · closed · 1 comment
The remaining reports are on [the project's issue tracker](https://github.com/ThoTischner/observability-mcp/issues).