(now fixed) Cloud Agent custom MCP connects but cannot authenticate Axiom via OAuth

[SeanCorc (Sean Corcoran)]

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

A custom Axiom MCP added at cursor.com/agents appears connected and enabled, but Cursor Cloud Agents do not complete the OAuth flow.

The MCP endpoint is:
https://mcp.axiom.co/mcp

The UI shows a green connected status, but calling listDatasets fails with:

user token not found or expired

The Axiom MCP works when authenticated locally in Cursor, but that local authentication is correctly separate from Cloud Agents. The problem is that the Cloud Agent configuration provides no functioning way to establish its own OAuth session.

Steps to Reproduce

1. Open https://cursor.com/agents.
2. Create a new Cloud Agent.
3. Open MCP Servers → Add MCP.
4. Add a URL-based MCP:
   Name: Axiom
   URL: https://mcp.axiom.co/mcp
5. Save and enable the MCP.
6. Observe that Cursor reports the MCP as connected/green.
7. Ask the Cloud Agent to use Axiom’s listDatasets tool.
8. Observe: “user token not found or expired.”
9. Attempt to authenticate/reconnect the Axiom MCP.
10. Observe an Internal Server Error instead of an OAuth browser flow.

Removing and re-adding the MCP does not resolve the issue.

Expected Behavior

Authenticate via OAuth and have the MCP server work

Operating System

MacOS

Version Information

Version: 3.11.19
VS Code Extension API: 1.125.0
Commit: bf249e6efb5b097f23d7e21d7283429f0760b740
Date: 2026-07-12T21:39:24.175Z (3 days ago)
Layout: Agent Window
Build Type: Stable
Release Track: Default
Electron: 40.10.3
Chromium: 144.0.7559.236
Node.js: 24.15.0
V8: 14.4.258.32-electron.0
xterm.js: 6.1.0-beta.256
OS: Darwin arm64 25.5.0

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

[SeanCorc (Sean Corcoran)]

It randomly just started working… not sure what changed. Tried for like 20 minutes and then it randomy decided to try and connect via oauth then it did not connect for awhile (the callback didn’t work) and now finally works.

Sorry if confusing wording it’s hard to explain - this is for cloud agent MCP oauth. I think that flow can be smoother when you get to it.

Appreciate it,

Sean

[mohitjain (Mohit)]

Remote MCPs like Axiom only require auth when a tool actually runs, so cursor.com/agents marks the server green as soon as the connection check passes (before there’s a valid token). That’s why the authenticate step doesn’t always surface cleanly, and why a reconnect can error out instead of reopening the OAuth flow. It’s a known rough edge on our radar for cloud-agent MCPs.

If you’d rather not lean on that interactive OAuth flow in cloud agents, Axiom also supports header-based auth, which is more reliable for headless runs. Create an Axiom token, then set these as headers on the MCP entry instead of OAuth:

• Authorization: Bearer <your-token>
• x-axiom-org-id: <your-org-id>

(If you can only set one header, Axiom accepts the org as a URL parameter: https://mcp.axiom.co/mcp?org-id=``<your-org-id>.) Setup details are in Axiom’s MCP server docs. Cursor cloud agents support custom headers on HTTP MCP servers, so the token gets used directly and skips the OAuth handshake. If the OAuth path acts up again, that should keep you unblocked.

[SeanCorc (Sean Corcoran)]

Thanks Mohit! Was able to get everything working eventually, just a bit of a rough UX for the setup.

I also had to use Composio to integrate with GSuite which is not a huge deal but that was another point of friction that Cursor does not have native plugins for GSuite.

At this point though my cloud agents are rockin & rolling with access to everything they need so I’m pretty hype abt that.

One final piece to make my cloud agent workflow truly elite is this: Slack Assistant pane: every message spawns a new cloud agent, with no way to follow up on an existing one

I know I can have a private channel but then I cannot take advantage of the agent pane