Skip to main content
Glama
ThoTischner

observability-mcp

by ThoTischner

Related Servers

Alternatives to observability-mcp

  • A
    license
    Not graded
    quality
    A
    maintenance
    Seamlessly bring real-time production context—logs, metrics, and traces—into your local environment to auto-fix code faster.
    159 npm
    62
    Apache 2.0
  • A
    license
    A
    quality
    B
    maintenance
    A comprehensive Model Context Protocol (MCP) server for Grafana, Prometheus, Kafka UI, and Datadog. Features a secure "Bring Your Own Key" (BYOK) architecture where credentials stay local. Provides tools for metrics querying, dashboard inspection, Kafka lag monitoring, and unified health checks.
    23
    18 npm
    4
    MIT

Related Servers

  • A
    license
    A
    quality
    C
    maintenance
    An evidence-first Prometheus MCP server that lets AI agents query production telemetry with detailed receipts including exact PromQL, timing, series count, and explicit warnings for empty, high-cardinality, or unreliable data.
    4
    MIT
  • A
    license
    Not graded
    quality
    D
    maintenance
    Unified MCP server for observability and monitoring, providing tools to query metrics, logs, and traces through Prometheus, Grafana, Loki, and Jaeger.
    2
    Mozilla Public 2.0
  • A
    license
    A
    quality
    D
    maintenance
    MCP server that enables AI assistants to query Grafana/Loki logs and Thanos/Prometheus metrics directly from MCP-compatible clients like Cursor or Claude Desktop.
    8
    MIT
  • A
    license
    Not graded
    quality
    D
    maintenance
    MCP server for querying observability data from Elasticsearch, SkyWalking, and Prometheus/VictoriaMetrics, enabling AI models to search logs, traces, and metrics across environments.
    9
    MIT
  • A
    license
    Not graded
    quality
    D
    maintenance
    A lean MCP server that provides LLM agents with transparent access to multiple Prometheus instances for metrics analysis and SRE operations.
    4
    GPL 2.0

TDQS

A4.7/5.0

Scored across 12 tools

Disambiguation5/5

Every tool addresses a clearly distinct concern: source discovery, service discovery, metrics, logs, traces, health, anomalies, history, postmortem, topology, blast radius, and IP enrichment. Even adjacent tools like get_service_health and detect_anomalies are explicitly differentiated in their intended entry points and follow-up flow.

Naming Consistency5/5

All tool names consistently follow a verb_noun snake_case pattern with meaningful verbs (list, query, get, detect, generate, enrich). There is no mixing of naming conventions or vague generic tool names.

Tool Count5/5

Twelve tools is well within the ideal scope for a comprehensive observability server. Each tool earns its place, from low-level data fetching to higher-level aggregation tools like generate_postmortem, without feeling bloated or redundant.

Completeness4/5

The tool surface covers the primary observability workflows end-to-end: discovery, metrics, logs, traces, health, anomaly detection, history, topology, RCA, and postmortems. The main gap is the lack of explicit metadata enumeration tools, such as listing available metric names or log label keys, which would make raw querying easier without relying on descriptions or external knowledge.

Maintenance

ActivityActive
ResponsivenessResponsive