Grafana MCP vs Prometheus MCP vs Sentry MCP (2026)
A. Frans
Published August 21, 2026
Table of Contents
"Which observability MCP should I install?" is the wrong question, and the reason is visible the moment you look at what each one queries. Grafana MCP talks to dashboards and every datasource behind them. Prometheus MCP talks to a metrics endpoint. Sentry MCP talks to exception events. These are three different layers of the same incident, and on a mature stack you will end up running two of them.
What you need to decide is which one goes in first, because each one costs you context window on every single request, and the first one you install determines what your agent is good at during an outage.
Head to head
| Grafana MCP | Prometheus MCP | Sentry MCP | |
|---|---|---|---|
| Maintainer | Grafana Labs (official) | pab1it0 (community) | Sentry (official) |
| GitHub stars | 3,373 | 511 | 821 |
| Trust tier | Verified | Community | Official |
| License | Apache-2.0 | MIT | Apache-2.0 |
| Layer | Dashboards, alerts, incidents, 10+ datasources | Raw PromQL metrics | Exceptions, traces, releases |
| Tool count | Large: dashboards, Loki, alerting, OnCall, rendering | 6 tools | Search, inspect, triage |
| Auth | Grafana service account token | Optional: basic, bearer, mTLS | OAuth or user auth token |
| Write access | Yes (update dashboards, create incidents, manage silences) | No, read only | Yes (issue triage) |
| Runs as | uvx, Go binary, Docker, Helm | Docker container | npx, remote hosted, plugin |
Grafana MCP: the widest surface, and the biggest blast radius
Grafana Labs maintains this one, and the scope is unusually large: dashboard search and retrieval, panel queries, alert rule management, incident and OnCall integration, PNG rendering of panels, deeplink generation, plus first-class query support for Prometheus, Loki, InfluxDB, ClickHouse, CloudWatch, Elasticsearch, Snowflake, and Athena.
That last part is the strategic argument. If your Prometheus is already registered as a Grafana datasource, Grafana MCP queries it for you. You get PromQL access and Loki logs and dashboard context from one server. Installing Prometheus MCP alongside it is often redundant.
Install with uvx:
claude mcp add grafana --env GRAFANA_URL=http://localhost:3000 --env GRAFANA_SERVICE_ACCOUNT_TOKEN=your-token -- uvx mcp-grafana
Or Docker, if you'd rather not put a Go toolchain on the box:
docker run --rm -i -e GRAFANA_URL=http://localhost:3000 -e GRAFANA_SERVICE_ACCOUNT_TOKEN=your-token grafana/mcp-grafana -t stdio
There's also a Helm chart (grafana/grafana-mcp) if you want it running in-cluster. Grafana 9.0 or later is required for full functionality.
The security note nobody puts in the README loudly enough: that service account token carries whatever permissions you grant it, and the server exposes tools that update dashboards, patch panels, and manage alert silences. An agent that can silence alerts is an agent that can hide an outage from your on-call rotation. Create a dedicated service account with Viewer role first. Promote it to Editor only after you've watched what your agent does with it for a week.
Prometheus MCP: six tools, zero risk
health_check, execute_query, execute_range_query, list_metrics, get_metric_metadata, get_targets. That's the whole surface.
The narrowness is the feature. Six tools cost almost nothing in context, and there is no write path. The worst thing a confused agent can do is run an expensive range query. For a team that wants to try agent-assisted debugging without a security review, this is the lowest-friction entry point on the list.
claude mcp add prometheus --env PROMETHEUS_URL=http://your-prometheus:9090 -- docker run -i --rm -e PROMETHEUS_URL ghcr.io/pab1it0/prometheus-mcp-server:latest
Auth is optional and flexible: basic auth, bearer token, or mTLS via PROMETHEUS_CLIENT_CERT and PROMETHEUS_CLIENT_KEY. If your Prometheus sits behind an authenticating proxy, this server can get through it.
Two things to weigh. It's a community project at 511 stars with an unreviewed security status in our directory, so read the source before you point it at production. It's a small Python codebase and that's an afternoon, not a project. And if you already run Grafana with Prometheus as a datasource, you're duplicating capability you already have.
Where it wins outright: teams running Prometheus without Grafana, and teams who want a read-only metrics tool they can hand to an agent with no approval process.
Sentry MCP: the one that knows what broke
Sentry MCP is the only one of the three that starts from an exception rather than a metric. Stack traces, issue grouping, release attribution, trace analysis, and issue triage. These are the questions that start with "what is this error" rather than "is the graph going up."
It's also the most installed by a wide margin, at 18,000 installs against 821 GitHub stars, which tells you most people find it through Sentry's own docs rather than GitHub.
Three ways in. The plugin route is the cleanest for Claude Code:
claude plugin marketplace add getsentry/sentry-mcp
claude plugin install sentry-mcp@sentry-mcp
Stdio, if you're self-hosting Sentry:
npx @sentry/mcp-server@latest --access-token=your-sentry-user-token
Or the hosted remote service at https://mcp.sentry.dev/mcp, which uses an OAuth flow instead of a long-lived token.
Prefer OAuth where you can. A user auth token for this server needs org:read, project:read, project:write, team:read, team:write, and event:write. That's a broad credential to leave sitting in a shell config, and project:write means an agent can modify project settings, not just read errors.
One quirk worth knowing: the remote service expects Authorization: Sentry-Bearer ${TOKEN}, deliberately not the standard Bearer prefix. If you're wiring it into something custom and getting 401s, that's why.
So which one first
Backend or platform engineer with Grafana already deployed: Grafana MCP, scoped to a Viewer service account. It subsumes Prometheus MCP and gives you Loki logs in the same breath.
Application developer shipping features: Sentry MCP. Your incidents start as a stack trace in a pull request, not as a dashboard anomaly, and having the agent read the actual exception beats having it guess from metrics.
SRE evaluating this whole category with a skeptical security team: Prometheus MCP. Six read-only tools is the easiest thing in this space to get approved, and it proves the workflow before you ask for anything with write access.
Anyone running all three: Reconsider. Grafana MCP plus Sentry MCP covers nearly everything, and dropping Prometheus MCP buys back context window you'll want during a long debugging session. Every MCP server you connect ships its tool definitions into every request, which is a real recurring token cost, and the third server is usually where it stops being worth it.
What none of the three do
Worth naming the gaps, because the READMEs won't.
None of them give your agent a topology. It can query the checkout service's error rate and the payments service's latency, but nothing tells it that one calls the other. You supply that context in the prompt, every time, or the agent correlates on coincidence.
None of them handle continuous profiling. Grafana MCP renders panels and Sentry MCP reads traces, but if your question is "which function allocated all this memory," you're still opening Pyroscope by hand.
And none of them retain anything between sessions. Every debugging conversation starts from zero. If you resolved this same alert last Tuesday, your agent has no idea. Some teams paper over this by keeping a runbook file in the repo the agent can read, which works better than it should.
The part that isn't about the servers
An agent with observability access is fast at correlation and bad at judgment. It will happily connect a latency spike to a deploy that happened four hours earlier and state it as a conclusion. That's useful as a hypothesis and dangerous as a postmortem.
Treat these as query interfaces, not as analysts. The value is that your agent can pull the p99 for the checkout endpoint over the last six hours without you context-switching to a browser tab. The value is not that it knows why the number moved.
And keep the write tools off until you've earned trust with the read ones. Silenced alerts and edited dashboards are the two ways this category can hurt you.
FAQ
Can I run Grafana MCP and Prometheus MCP at the same time? Yes, and nothing breaks. But if Prometheus is a registered Grafana datasource, Grafana MCP already queries it, so you're paying context cost for duplicate capability. Pick one unless you have a specific reason.
Do any of these work with Datadog or New Relic? Not directly. Grafana MCP covers CloudWatch, Elasticsearch, ClickHouse, InfluxDB, Snowflake, and Athena among others, but Datadog and New Relic have their own separate integrations. See our full list for developers for the wider monitoring tool market.
Is the community-maintained Prometheus MCP safe to use in production? It's marked unreviewed in our directory, which means nobody has formally audited it, not that anything is wrong with it. It's a small codebase with no write path and no credential storage beyond environment variables. Read it, then decide. Our guide on reducing the risk of community skills covers the general process.
What's the difference between installing this as an MCP server and as a plugin? The plugin route (claude plugin install) bundles the MCP server with any accompanying skills and slash commands, and handles updates for you. claude mcp add wires up just the server. Sentry offers both; Grafana and Prometheus are MCP-only today. See MCP servers vs agent skills if the distinction is still fuzzy.
Which one should I install if I only get to pick one, ever? Grafana MCP, assuming you run Grafana. It's the only one whose scope grows with your stack instead of being fixed to a single backend.
Share this article
⚙Related Tools
📄Related Articles
Get More AI Tool Guides
New comparisons and guides every week. Join thousands of professionals staying ahead of the AI curve.