Grafana for observability
Grafana Labs' official server is our second pick for observability, and it is the natural fit when your stack is built on the open Grafana layer. It connects an agent to dashboards, Prometheus, and the Loki and alerting datasources you already run, so an unplanned question, why is latency up, which panel shows the regression, becomes a query instead of dashboard archaeology.
It sits second of four because it is strongest for teams already standardized on Grafana, and the slot reflects the roundup's spread across stacks. Datadog, Honeycomb, and Prometheus each fit a different observability shape.
How Grafana fits
The querying tools do the work. list_datasources and get_datasource resolve which backend holds the data, query_prometheus runs PromQL directly against a Prometheus datasource, and run_panel_query replays a dashboard panel's query over a custom time range. The dashboard tools, search_dashboards, get_dashboard_by_uid, get_dashboard_summary, get_dashboard_property, and get_dashboard_panel_queries, let the agent find the relevant view and reuse the query it was built with rather than inventing one.
Honest limits: run_panel_query and get_query_examples are disabled by default, and the primary query path here is PromQL for metrics, so high-cardinality trace exploration is not its strength. Honeycomb is the stronger pick when you need to slice traces and events by arbitrary dimensions to find the outlier; Datadog fits teams wanting a single full-platform vendor; Prometheus is the lean choice when metrics and PromQL are all you need. Reach for Grafana when your dashboards and metrics already live in the open stack and you want the agent querying them where they sit.
Tools you would use
| Tool | What it does |
|---|---|
| search_dashboards | Finds dashboards by title or metadata. |
| get_dashboard_by_uid | Retrieves the full details of a dashboard by UID. |
| get_dashboard_summary | Gets a compact overview of a dashboard. |
| get_dashboard_property | Extracts parts of a dashboard via a JSONPath expression. |
| get_dashboard_panel_queries | Gets the queries and datasource info for a dashboard's panels. |
| update_dashboard | Modifies or creates a dashboard. |
| patch_dashboard | Applies targeted changes to a dashboard without sending full JSON. |
| run_panel_query | Executes a dashboard panel's query over a custom time range (disabled by default). |
| list_datasources | Lists all configured datasources. |
| get_datasource | Gets a datasource by UID or name. |
FAQ
- Can the Grafana MCP server explore high-cardinality traces?
- Not as its strength. Its primary query tool is query_prometheus for PromQL metrics, with run_panel_query for dashboard panels. For slicing traces and events by arbitrary dimensions, Honeycomb is the stronger pick.
- Does the Grafana server work without dashboards already set up?
- Partly. query_prometheus runs ad-hoc PromQL against a datasource without a dashboard, but much of the value comes from reusing existing panel queries via get_dashboard_panel_queries and run_panel_query, which is disabled by default.