Observability MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PROMETHEUS_PORT | No | Prometheus metrics server port | 9090 |
| OTEL_SERVICE_NAME | No | OpenTelemetry service name | observability-mcp |
| METRICS_RETENTION_DAYS | No | Metrics retention period (days) | 30 |
| OTEL_EXPORTER_OTLP_ENDPOINT | No | OTLP exporter endpoint (optional) |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| logging | {} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| extensions | {
"io.modelcontextprotocol/ui": {}
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| check_stack_statusA | Check the health and connectivity of the observability stack (Loki, Prometheus, Grafana). This diagnostic tool verifies if the underlying Docker-based services are reachable and correctly configured. |
| manage_alert_configsA | Manage metric alert configurations. Operations:
|
| show_status_dashboardA | Display a rich, premium status dashboard using Prefab UI. Provides a visual overview of stack health, system metrics, and active alerts. Hardened: operates in Degraded Mode when Docker or stack services are unreachable. |
| monitor_server_healthB | Perform real-time health check on an MCP server or web service. This tool uses OpenTelemetry for metrics collection and provides comprehensive health monitoring with detailed response analysis. |
| collect_performance_metricsA | Collect comprehensive performance metrics for the system or specific service. Uses OpenTelemetry for structured metrics collection and psutil for system monitoring. Metrics are persisted for historical analysis and trend detection. |
| trace_mcp_callsA | Record a trace for MCP call monitoring and distributed tracing. Creates OpenTelemetry spans for tracking MCP server interactions, enabling distributed tracing across multiple MCP servers. |
| generate_performance_reportsB | Generate comprehensive performance reports with automated analysis. Analyzes historical metrics data to provide insights, trends, and recommendations for optimizing MCP server performance. |
| alert_on_anomaliesB | Monitor for performance anomalies and trigger alerts. Uses statistical analysis and configurable thresholds to detect anomalies in MCP server performance metrics and trigger appropriate alerts. |
| monitor_system_resourcesB | Monitor system-wide resources and provide real-time status. Collects comprehensive system resource information including CPU, memory, disk, network, and process statistics for overall system health monitoring. |
| analyze_mcp_interactionsB | Analyze patterns in MCP server interactions and usage. Examines trace data and interaction patterns to provide insights into how MCP servers are being used and identify optimization opportunities. |
| export_metricsB | Export collected metrics in various formats for external monitoring systems. Supports Prometheus, OpenTelemetry, and JSON formats for integration with existing monitoring infrastructure. |
| send_logs_to_lokiB | Send custom log entries to Loki for centralized log aggregation. This tool allows manual log injection into the Loki log aggregation system, enabling correlation between custom events and system metrics. |
| query_loki_logsC | Query logs from Loki with advanced filtering and analysis. This tool provides powerful log querying capabilities using Loki's LogQL syntax, enabling correlation between logs, metrics, and traces. |
| analyze_log_patternsB | Analyze log patterns and anomalies using Loki queries. This tool identifies common log patterns, error spikes, and potential issues by analyzing log data over time windows. |
| correlate_logs_and_metricsB | Correlate log entries with metrics for comprehensive incident analysis. This tool combines Loki log querying with Prometheus metrics to provide unified observability insights and root cause analysis. |
| manage_grafana_dashboardsA | Manage Grafana dashboards. Operations:
|
| manage_grafana_datasourcesA | Manage Grafana datasources. Operations:
|
| provision_standard_dashboardsB | Provision standard SOTA industrial dashboards to Grafana. This tool sets up pre-configured dashboards for:
|
| agentic_observability_workflowB | Multi-step observability triage (stack → logs → health). Uses host LLM sampling when available; otherwise runs a fixed tool chain. |
| observability_stack_health_cardC | Prefab card: unified PLG stack health (Grafana, Prometheus, Loki). |
| observability_grafana_dashboards_cardB | Prefab card: Grafana dashboard list (read-only). |
| observability_capabilities_cardC | Prefab card: SOTA manifest and tool surface summary. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| observability_getting_started | |
| incident_triage |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| observability_capabilities | |
| observability_sota_manifest | |
| observability_prefab_manifest | |
| observability-expert/SKILL.md | Observability-MCP expert skill |
| observability-expert/_manifest | File listing for observability-expert |
TDQS
Scored across 22 tools
Several clusters of overlapping tools exist: check_stack_status, show_status_dashboard, observability_stack_health_card, and monitor_server_health all report health; collect_performance_metrics, monitor_system_resources, and generate_performance_reports all gather/analyze metrics; query_loki_logs, analyze_log_patterns, and correlate_logs_and_metrics all touch Loki. Descriptions add nuance but an agent can easily pick the wrong status/health/report tool.
Nearly all tools follow a clean verb_noun pattern (check_stack_status, query_loki_logs, manage_grafana_dashboards). The main deviation is the trailing observability_*_card tools plus agentic_observability_workflow, which are noun-style and break the pattern, though they read as a deliberate UI-card group.
22 tools is at the heavy end for an observability server; the core workflows (metrics, logs, traces, dashboards) are covered, but multiple near-duplicate reporting/status/card tools push it beyond a tight scope.
Strong coverage of the PLG stack: log ingestion/query/analysis, trace recording, alert config management, Grafana dashboard and datasource CRUD, and metric export. The notable gap is direct Prometheus/PromQL metric querying for ad-hoc exploration, plus no update/delete for dashboards beyond create-or-update.