Grafana MCP server: Cloud vs open source, setup and read-only mode

When an alert fires, the first questions are always the same: what does the dashboard show, what do the logs say, who is on call, has this happened before? The Grafana MCP server lets an AI agent answer them from Claude Code, Claude Desktop or Cursor, using Prometheus, Loki, dashboards and alerting through Grafana's own permissions. This guide explains the two official servers, how to set each up, the tools, and how to keep it read-only. If MCP is new to you, start with what an MCP server is.

Facts are from Grafana Labs' documentation and the grafana/mcp-grafana repository as of October 2026.

Two official servers: which one?

On Grafana Cloud, start with the hosted server: no process to run, and access follows each user's Grafana role. On self-managed Grafana, mcp-grafana is the only option, and it is also the one to choose when you want full control over which tools exist.

Grafana Cloud MCP

The hosted server speaks Streamable HTTP. Point it at your stack either with a header, X-Grafana-URL: https://<stack>.grafana.net, or in the path, https://mcp.grafana.com/mcp/<stack>.grafana.net.

Claude Code:

claude mcp add grafana --transport http https://mcp.grafana.com/mcp/acme.grafana.net

Run /mcp in a session to sign in. Claude Desktop and other clients use a JSON entry with "type": "http", the URL and the X-Grafana-URL header. Grafana also documents Cursor, VS Code, Windsurf and Goose.

Who can use it: users need the role Assistant Cloud MCP User or the permission grafana-assistant-app.cloud-mcp:access. Editors and above have it by default, so if Viewers should not use it, check that before rollout. Read-only, query or write access is granted per connection, on top of the user's normal RBAC.

Cost: usage counts toward Grafana Assistant active users. Grafana says read-only use does not consume Assistant tokens; writes that invoke models do.

mcp-grafana (open source)

Install it the way that suits you:

uvx mcp-grafana                     # recommended
docker run grafana/mcp-grafana -t stdio
go install github.com/grafana/mcp-grafana/v2/cmd/mcp-grafana@latest

There is also a Helm chart, grafana/grafana-mcp, for running it inside a cluster. The Docker image defaults to SSE, so pass -t stdio for a local client.

It authenticates with a service account:

export GRAFANA_URL=https://grafana.example.com
export GRAFANA_SERVICE_ACCOUNT_TOKEN=glsa_...

GRAFANA_API_KEY is deprecated. Grafana's docs suggest the Editor role for full functionality, or fine-grained RBAC scopes (for example dashboards:* or a specific datasources:uid:...). Give the service account only the scopes the agent's job needs; Editor is more than most investigating agents require.

Claude Code (stdio):

claude mcp add grafana \
  -e GRAFANA_URL=https://grafana.example.com \
  -e GRAFANA_SERVICE_ACCOUNT_TOKEN=glsa_... \
  -- uvx mcp-grafana --disable-write

The README has Claude Desktop JSON for uvx, the binary and Docker. To share one instance across a team, run it with -t streamable-http (port 8000) and protect it with --server-auth-token.

The tools

Some groups are off by default in mcp-grafana and must be enabled: admin, cloudwatch, elasticsearch, clickhouse, snowflake, athena, graphite and others. The hosted Cloud server exposes 50+ tools across the same areas plus Tempo, Pyroscope and panel rendering.

Read-only, and why it is the right default

mcp-grafana's --disable-write removes every write tool and also the raw SQL tools. That one flag covers most of what an investigating agent should not do: edit dashboards, silence alerts, change routing. Add back exactly what you need:

uvx mcp-grafana --disable-write --enable-write-tools=<tool-name>

--enabled-tools=<categories> and --disable-<category> narrow it further. Fewer tools also leaves more of the model's context for the actual investigation.

Silencing an alert or patching a dashboard should be a human decision. If you do enable writes, keep a confirmation on them in your AI client, and remember that log lines are untrusted input: an agent that reads a crafted log message and can also write is the combination MCP security best practices warns about.

What people use it for

• Alert triage. "The checkout latency alert is firing. Show the p95 for the last hour, the error logs for checkout in Loki, and who is on call."
• Dashboard reading. "Summarise the Payments dashboard: which panels look abnormal compared with last week?"
• Log patterns. "What are the most common error patterns in the api namespace since the last deploy?" (query_loki_patterns)
• Incident write-up. With write access: "Create an incident for this, add the queries we ran as activity."

A standard triage procedure belongs in a skill so the whole rotation investigates the same way.

Running it for a team

The hosted server gives each user their own OAuth connection; the open-source one is easy to run centrally behind a token. Either way, a team rollout needs the same tools enabled, the same write policy, and one log across Grafana, Sentry, GitHub and the rest. That is the job of an MCP gateway. Walma AI Hub runs approved MCP servers behind one policy and one audit log, with the models in the customer's own Azure tenant in an EU region. Related guides: Datadog MCP and Sentry MCP.