MCP field guide / Grafana
// mcp field guide · observability
Like Sentry and Datadog, Grafana's MCP is overwhelmingly read — an agent querying metrics, logs and dashboards to explain a spike. For that dominant use a guard adds little. But Grafana has a dangerous edge most observability servers lack: alerting. Delete an alert rule and detection is gone; change routing or mute timings and a real outage goes unpaged.
GUARD FIT · READ / OBSERVE (dominant)
WEAKQuery Prometheus/Loki, fetch dashboards, list incidents/on-call. Idempotent and safe — gating is friction.
GUARD FIT · ALERTING
STRONGDelete an alert rule (removes detection) or change routing/mute timings (hides an outage) — the sharp tail.
Overall fit: WEAK → STRONG — weak for the read majority; strong on the narrow alerting tail. And --disable-write often removes the job entirely.
grafana/mcp-grafana (Grafana Labs, Apache-2.0) connects an agent to a Grafana instance — self-hosted binary/Docker/Helm, or a Grafana Cloud-hosted remote endpoint. It queries metrics and logs (Prometheus, Loki, and many optional datasources), reads/writes dashboards, renders panels, manages alert rules and notification routing, and works with Grafana Incident, OnCall, Sift and annotations. Tools are grouped into categories that can be individually enabled or disabled, and --disable-write puts the whole server in read-only mode.12
| Tier | Tools |
|---|---|
| read-only (dominant) | search_dashboards, get_dashboard_by_uid, get_panel_image, query_prometheus, query_loki_logs, query_pyroscope, list_incidents, get_current_oncall_users, list_alert_groups, alerting_manage_rules (list/get/versions) |
| mutating | update_dashboard/patch_dashboard (Grafana keeps version history → recoverable), alerting_manage_rules (create/update), create_incident, create_annotation, create_snapshot |
| destructive / safety-hiding | alerting_manage_rules (delete) — removes detection entirely; alerting_manage_routing — notification policies / mute timings can suppress alerts (route them to nowhere); delete_snapshot |
Correcting a common assumption: the current tool set has no delete_dashboard or delete_datasource tool, and no dedicated one-off "silence" tool — alert suppression is achieved via alerting_manage_routing time intervals (mute timings). Overwriting a dashboard (update_dashboard) is recoverable via version history. So the real destructive/safety-hiding surface is narrow: delete an alert rule and route/mute notifications.
Incident triage / RCA. Pull dashboards, run PromQL/LogQL, inspect Loki patterns and Pyroscope profiles, read Sift investigations to explain a spike — all read-only.
Dashboard authoring. Generate or update a dashboard from a prompt, hand back a deep link.
Alerting ops. List/inspect alert rules, create or tune a rule, or adjust routing during a maintenance window — the sharp tail.
Reads → weak — say it plainly. Querying metrics/logs, fetching dashboards and rendering panels are idempotent and safe. For an agent investigating a problem, a guard mostly adds friction — the same weak fit as Sentry and Datadog. Reads dominate, and reads don't need approval.
Alerting → strong, and it's the one thing that matters here. An agent "cleaning up noisy alerts" can blind on-call:
alerting_manage_rules (delete) — silently removes detection; a real condition simply stops being alerted on. Confirm every time.alerting_manage_routing — changing notification policies or mute-timing intervals can hide a real outage by routing/muting alerts. The strongest argument for a guard on this server.delete_snapshot and dashboard overwrites are lower-stakes (snapshots are disposable; dashboards keep history) — "show the impact diff" candidates more than hard gates.
Honest scoping: Grafana already ships the right control for most cases — --disable-write (read-only) plus per-category disabling. For most observability agents, running read-only removes the guard's job entirely. The guard's differentiated value appears only when writes must be enabled and the tools in play are delete-alert-rule and routing/mute changes — because those hide or destroy the ability to detect problems, which is the "irreversible-in-effect" case to flag, not pretend to undo.
ChronoMCP passes Grafana's read surface through and holds delete-alert-rule and routing/mute changes for a human — so an agent can't silently blind on-call.
Read the quickstart → More MCP profilesgrafana/mcp-grafana (tool names, --disable-write, categories): github.com/grafana/mcp-grafanaProfiles describe third-party software from its public sources; ChronoMCP is not affiliated with Grafana Labs. Tool names are quoted from the repo/docs; no delete_dashboard/delete_datasource or dedicated one-off silence tool was found (suppression is via routing/mute timings). Default-disabled category membership drifts by version. Risk groupings are our classification. Sources current as of Aug 2026 — check the source links.