Hi,
I’m trying all different ways to have grafana mcp working with cursor cloud agents to fully automate my personal AI SRE but I’m stuck. Our Grafana instance is behind cloudflare ZTNA and despite passing the right headers with all the service tokens to call the mcp (I tested from multiple places outside of ZTNA and it’s working) cursor is just ignoring it and says that the MCP is not even available. What am I missing here?
Am I the only one stuck with this? Thank you.
The issue you’re hitting is a known bug where team-configured command-based (stdio) MCP servers fail to start in cloud agent sessions. Our team is actively working on MCP reliability in cloud agents and this is being tracked.
Regarding the Cloudflare ZTNA piece: since mcp-grafana runs as a process on the cloud agent VM and uses your GRAFANA_EXTRA_HEADERS to authenticate requests, the Cloudflare service tokens should handle access correctly once the MCP process starts. So ZTNA shouldn’t be a separate blocker here.
A few things to check in the meantime:
-
Verify cloud agent access is enabled for the MCP: On cursor.com/settings, make sure the grafana MCP server has the “Cloud Agents” toggle enabled (not just the IDE toggle)
-
If you need this urgently, the Cursor TypeScript SDK supports passing MCP servers via inline config. You can configure your MCP directly in the SDK call, bypassing the dashboard resolution entirely.
I’ll follow up here once the underlying fix ships. Let me know if you have any questions.
Verify cloud agent access is enabled for the MCP: On cursor.com/settings, make sure the grafana MCP server has the “Cloud Agents” toggle enabled (not just the IDE toggle)
Hi, I don’t see this option. When I go to https://cursor.com/settings it redirects me to https://cursor.com/dashboard and I don’t see that option anywhere. As I showed above this is a STDIO mcp I have and there’s no option anywhere to enable a "“Cloud Agents” toggle.
For team-level stdio MCPs configured via the admin dashboard, there isn’t a separate “Cloud Agents” toggle to flip. Your MCP should be available automatically once it’s configured at the team level.
The core issue here is the bug I mentioned: the cloud agent runtime isn’t properly starting team-configured stdio MCPs, even though they show as configured. A fix for this has been implemented internally and is working through review. I expect it to ship soon.
In the meantime, the SDK inline config approach (option #2 from my earlier reply) remains the only reliable workaround if you need this unblocked now. I’ll post back here once the fix is live.
Hey @Bruno_Ferreira!
We’ve made changes to how team-configured stdio MCPs get started in cloud agents. Could you give your Grafana MCP another try in a fresh cloud agent run?
Hi! yes I can confirm this is working now! thank you
This worked for some time… now it’s broken again and it just can’t use the grafana mcp having exactly the same behaviour as before
The pattern here looks like the Grafana MCP’s connection dropping and then not coming back for the rest of the session, rather than an auth problem. That usually means the mcp-grafana process itself is exiting - and when the server can’t reach Grafana (for example a Cloudflare Access service-token issue), it often surfaces as the connection closing rather than an auth prompt.
Could you grab the server log right after it fails and paste it? Output panel (Cmd+Shift+U) → pick “MCP: grafana” from the dropdown. That’ll show whether the process is erroring out and why. A Request ID from the failing chat helps too (three-dot menu on the message → Copy Request ID).
Also quick: is this in your local Cursor IDE, a cloud agent run, or both? If a cloud run, drop the agent link and I’ll trace it directly.
here’s an example of a failed one: https://cursor.com/agents/bc-56c298a3-cdf8-4dc8-88a7-2abda8758699
any news on this @mohitjain @Colin ? would be really nice to have this working so I can use cursor agents as the main tool to automatically troubleshoot OOMs etc.
Thanks for confirming this is on cloud agents - that lines up with something we’ve been looking into.
What’s going on: your Grafana MCP is starting before the network path to it (your Cloudflare ZTNA tunnel) is ready, so the first check finds it unreachable and the agent then keeps it as “not available” for the rest of that session instead of retrying.
Two things to try that should unblock you:
- Start a fresh cloud agent and check again - a recent update should help stdio MCPs pick up your configured headers/service tokens, which was one part of this.
- Gate the MCP on readiness - wrap your MCP command in a small script that waits until the ZTNA endpoint is actually answering, then exec the real server, and set that wrapper as the MCP
command. Keep the wait under ~a minute so it doesn’t hit the startup timeout.
The remaining piece (having it retry and recover on its own, without the wrapper) is an issue we’re tracking. I’ll post here when there’s an update.
@mohitjain seems to be working again. I didn’t have to change anything, just spawned a new cloud agent to test.
Regarding the wait, what you said is not exactly accurate because the CF tunnel is already up on our infra, grafana just needs to pass the service token to be able to invoke it.
