MCP servers that can list dashboards

4 verified servers expose a tool that can list dashboards

Observability lives in dashboards, and an agent that needs to read one first has to find it. Listing dashboards returns what exists so the agent can pick the right view, the latency board, the error panel, before it reads or links to it.

These verified servers let an agent list the dashboards in an observability or analytics tool.

Top pick

Grafana

Grafana Labs

Official

Grafana Labs' official MCP server: query dashboards, Prometheus, Loki, incidents, alerts, and OnCall from your agent.

monitoring-observability3,083
Tool:
  • search_dashboards

Grafana searches by title or metadata: search_dashboards finds the board an agent wants among many, the discovery step before it reads the panels.

Pick 2

Metabase

Cognition

Community

A maintained Metabase MCP server from Cognition that lets an agent run questions, build dashboards, and query databases across your Metabase instance.

data-analytics57
Tool:
  • list_dashboards

Metabase's list_dashboards returns every dashboard in the instance, the full catalog for an agent working over BI dashboards.

Pick 3

SigNoz

SigNoz

Official

SigNoz's official MCP server gives agents full access to traces, logs, metrics, dashboards, and alerts in your OpenTelemetry-native stack.

monitoring-observability96
Tool:
  • signoz_list_dashboards

signoz_list_dashboards lists all dashboards in SigNoz, for teams running it as a single open-source observability store.

Pick 4

Better Stack

Better Stack

Official

Better Stack's official MCP server: query logs, metrics, and traces, manage monitors and incidents, and drive on-call from one remote endpoint.

monitoring-observability
Tool:
  • telemetry_list_dashboards

telemetry_list_dashboards returns the dashboards in Better Stack, the listing an agent uses alongside its uptime and incident tools.

What to know

A dashboard list is the index an agent navigates during ops and analytics work. To answer how a service is doing, or to drop a link in an incident channel, it needs the dashboard's id or slug, and listing is how it resolves a name like API latency to the thing it can open. The tools differ in how they find: Grafana searches by title or metadata, the others return the full set. What comes back is the same idea, a catalog of dashboards the agent can then read.

Dashboards are added and renamed slowly, so an agent that maps a name to its dashboard once can hold that rather than re-search every session. The few it actually uses are worth keeping a pointer to, so the next incident does not start with a search.

Questions

Why list dashboards before reading one?
Because the read and link tools want a dashboard id or slug, not a display name. Listing resolves a name like API latency to its id, so an agent opens the right board. On Grafana the listing is a search, which helps when there are hundreds.
Is this for metrics or BI dashboards?
Both, depending on the server. Grafana, SigNoz, and Better Stack are observability dashboards over metrics, logs, and uptime; Metabase is BI over your data. The list call is the same idea on each: return the dashboards so the agent can pick one.