MCP servers that can query metrics and logs
5 verified servers expose a tool that can query monitoring metrics and logs
When an agent is debugging a production problem, it needs the same thing an on-call engineer reaches for: the metric that spiked, the log line around the error, the time window where things changed. Several observability MCP servers expose exactly that, so a model can pull telemetry instead of asking you to paste it.
These verified servers let an agent query metrics, logs, and related signals from your monitoring stack.
Grafana
Grafana Labs
Grafana Labs' official MCP server: query dashboards, Prometheus, Loki, incidents, alerts, and OnCall from your agent.
query_loki_logslist_prometheus_metric_nameslist_prometheus_metric_metadata
Reaches across the Grafana stack: Loki for logs and Prometheus for metrics, through one server. Reach for it when your telemetry already lives in Grafana.
Prometheus
pab1it0
A maintained Prometheus MCP server: run PromQL instant and range queries, discover metrics and metadata, and inspect scrape targets from your agent.
execute_querylist_metricsget_metric_metadata
Runs PromQL directly and lists the available metric names and metadata, so an agent can discover what is being measured before it queries a value.
SigNoz
SigNoz
SigNoz's official MCP server gives agents full access to traces, logs, metrics, dashboards, and alerts in your OpenTelemetry-native stack.
signoz_query_metricssignoz_list_metricssignoz_list_alerts
Queries metrics and surfaces active alerts from SigNoz, which suits teams running it as a single open-source store for metrics, traces, and logs.
SonarQube
Sonar
Sonar's official MCP server brings SonarQube code quality, security, and coverage analysis into your AI agent.
get_system_logs
Returns the SonarQube server's own process logs through get_system_logs. Narrow, but the way to have an agent debug a misbehaving SonarQube instance rather than the code it scans.
Argo CD
Argo Project (argoproj-labs)
The Argo CD MCP server lets an agent inspect and manage GitOps applications — list and sync apps, read resource trees and workload logs, and run resource act...
get_application_workload_logs
Returns workload logs for an Argo CD application, which puts deploy-time log access next to the GitOps state the agent is reasoning about.
What to know
There is a real split here between metrics and logs, and most servers lean one way. Metric servers (Prometheus, SigNoz, the Prometheus side of Grafana) answer questions like what was p99 latency at 14:05. Log servers answer what was the error text, and tend to live closer to CI and deploy tooling. A few span both. Pick by signal: a metric server to find when p99 moved, a log server to read the stack trace at that timestamp.
The harder problem is continuity across an incident. Debugging is iterative: the agent forms a hypothesis, queries, refines, queries again. If each session starts cold with no memory of what was already ruled out, it re-runs the same dead-end queries. Telemetry is stateless and fast to fetch; the reasoning trail across an investigation is what you do not want to lose.
Questions
- Can an agent run PromQL or LogQL through these servers?
- Yes for the metric-native ones. Prometheus exposes execute_query for PromQL, and Grafana can reach both Prometheus metrics and Loki logs. The agent still needs to know the metric or label names, which is why these servers also expose list and metadata tools to discover what exists.
- Are metrics and logs the same capability?
- Related but not identical. Metrics are numeric time series (latency, error rate, CPU). Logs are text events. Some servers here focus on one, some span both. For incident work an agent usually wants both: a metric to find when something broke and logs to find why.