Adding a custom remote MCP server (HTTP URL, web OAuth) in Grok Bot fails before any OAuth UI appears. The same URL works in Cursor IDE via mcp.json (“url”: “https://…”), where the browser OAuth flow completes and tools load.
In Grok Bot, the server ends up with 0 tools. Status flips between Failed to load MCP server and needsAuth / Authentication required. Calling Authenticate returns:
Sign-in for “” never started. The server or its configuration failed the check: “fetch failed”
This looks related to Grok Bot: IBKR MCP OAuth fails (redirect_uri), but the failure mode is different: we never get an IdP redirect_uri rejection. Auth dies earlier on fetch failed.
Steps to Reproduce
In Grok Bot, add a custom MCP server pointing at a remote HTTPS MCP gateway that requires OAuth (URL-only config, no stdio).
Observe server status: Failed to load MCP server and/or needsAuth, tools=0.
Trigger Authenticate on that server (default account).
Sign-in / connect card never opens; error is fetch failed.
On the same machine, add the identical URL under Cursor IDE mcp.json as a URL MCP → OAuth works and tools are available.
Expected Behavior
Grok Bot should open the OAuth/connect flow for custom remote MCP servers (same as Cursor IDE URL MCPs / marketplace connectors), then expose the server’s tools to the agent.
Cursor IDE workaround that works today: URL MCP in ~/.cursor/mcp.json (browser OAuth).
Grok Bot cannot use the stdio mcp-remote bridge pattern Mohit mentioned in the IBKR thread (remote HTTP only).
From the agent/box side, probing the gateway also failed (connection timeout and/or HTTP 500), which may indicate Grok Bot’s MCP proxy can’t reach or complete OAuth discovery against this host.
Ask: fix OAuth for custom remote MCPs in Grok Bot (discovery + compliant redirect URI), and surface a clearer Settings error when the pre-auth fetch fails vs when the IdP rejects redirect_uri.
Hey, thanks for the detailed report, and for pinpointing the difference between the IDE and Grok Bot yourself. That’s the key part.
The difference is where the OAuth handshake runs. In Cursor IDE, a URL-based MCP connects locally. The process on your machine calls the gateway and opens the browser OAuth flow, so servers on a local network, behind a VPN, or on a private host can work. Grok Bot is a cloud agent, and the connection to a remote MCP plus OAuth discovery runs from Cursor’s infrastructure, not from your machine. Because of that, the endpoint has to be publicly reachable over HTTPS from the open internet.
fetch failed before the connect card shows up means the initial fetch to your gateway from our side didn’t work DNS or connection. Your note that direct probing of the gateway times out or returns 500 points the same way. The host likely isn’t reachable from outside.
What will help:
Check that the MCP endpoint responds publicly over HTTPS, not only from your local network or VPN, and that the OAuth discovery endpoints /.well-known/... are reachable from the open internet.
Share the server URL, or at least the host, and I’ll check reachability from our side.
On the error text, I agree. It doesn’t distinguish between a pre-auth fetch failure and the IdP rejecting the redirect_uri. I passed this to the team as a request for a clearer message in Settings.
For now, the working option is what you already found. Keep this MCP URL in Cursor IDE mcp.json with local browser OAuth. Send the URL and we can dig in further.
Why Cursor IDE works and Grok Bot doesn’t (as I understand it): In the IDE, a URL-based MCP runs the connection and browser OAuth on my machine, so anything my laptop can reach (corp network, VPN, private DNS) can work. Grok Bot runs that handshake from Cursor’s cloud infrastructure, so the MCP host has to be reachable over public HTTPS from the open internet. Same URL, different network path.
Question: is that split by design for Grok Bot (cloud agents only talk to public remote MCPs), or is local/VPN-reachable MCP OAuth something you expect to support later (e.g. a host-local bridge, like stdio mcp-remote in the IDE)? Right now it reads as an architectural limitation of the cloud path, not a misconfig on our end, just want to confirm so we know whether to wait on a product change or treat “public endpoint only” as the permanent rule.
We won’t post hostnames or other identifying details here. For now we’ll keep this MCP in Cursor IDE mcp.json with local OAuth.
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.
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.
