Good question, and you phrased it exactly right.
Yes, this is an architectural detail of the cloud path, not a misconfig on your side. Grok Bot is a cloud agent, so the connection to the remote MCP and the OAuth discovery run from Cursor’s infrastructure, not from your machine. That means the endpoint must be publicly reachable over HTTPS from the open internet. For now, you can treat public endpoint only as the rule for the cloud path. In the IDE, URL-based MCP does OAuth locally in a process on your machine, which is why the network path is different.
Separately, there are ways for cloud agents to access private networks, like Tailscale, Cloudflare Tunnel, and AWS PrivateLink. This is mostly for Team or Enterprise, for private code and internal services. It’s not the same as local browser OAuth in the IDE, but if you need the cloud path to reach a private host, check this doc: Private Connectivity | Cursor Docs.
About a host-local bridge for Grok Bot, similar to the stdio mcp-remote flow in the IDE, I can’t confirm it’s planned or share an ETA. There’s a related feature request if you want to add your use case: Host-local MCP for external orchestrators (bots / daemons) — REST vs SDK gap.
On the unclear error text, fetch failed doesn’t distinguish between a pre-auth fetch failure and an IdP rejection due to redirect_uri. I’ve already passed that to the team and we’re tracking it.
For now, the working option is what you already found: keep this MCP in Cursor IDE mcp.json and use local OAuth. Let me know if anything else comes up.