Connecting the HubSpot marketplace plugin fails because Cursor sends
redirect_uri=cursor://anysphere.cursor-mcp/oauth/callback.
HubSpot MCP Auth Apps only allow redirect URLs, so the connection dies with “redirect URL is invalid.” Adding the cursor:// URI in HubSpot is impossible.
Steps to Reproduce
Create HubSpot MCP Auth App with redirects http://localhost:8787/callback and
Install HubSpot plugin; set Client ID / Secret
Connect / OAuth
HubSpot error: redirect URL cursor://anysphere.cursor-mcp/oauth/callback is invalid
Expected Behavior
Desktop MCP OAuth should use the documented loopback callback: http://localhost:8787/callback
(as in Cursor MCP docs and HubSpot plugin README).
Hey, thanks for the detailed report. What you registered in HubSpot, http://localhost:8787/callback (RFC 8252 loopback), is exactly the correct redirect for desktop MCP OAuth. So your setup is correct, it’s not the issue.
cursor:// as a redirect_uri shows up as a fallback when Cursor can’t start the loopback server on port 8787, for example if that port is already in use by another process. A common culprit is Cloudflare wrangler dev, which listens on 8787 by default.
What to try:
Check if port 8787 is in use (lsof -i :8787 on macOS) and stop the process if something is running there.
Click Connect again on the HubSpot plugin. If the port is free, Cursor will use the loopback callback instead of cursor://.
Also, it’s possible the connection is already up. Check the plugin status, there’s a good chance it’s connected after a retry.
Retried with lsof -i :8787 empty (no wrangler). HubSpot still fails: redirect URL cursor://anysphere.cursor-mcp/oauth/callback is invalid. So this isn’t the port-conflict case.
Thanks for checking. Since port 8787 is free and you still get cursor://, this isn’t a port conflict. Your HubSpot setting http://localhost:8787/callback is correct, so it’s not on your side.
This is a known issue with HTTP(S)-only providers where Cursor falls back to cursor:// instead of using the loopback callback. We’re tracking it, but I can’t share an exact ETA yet.
A couple things to try right now:
Fully quit Cursor with Cmd+Q (not just closing the window), reopen it, then click Connect in the plugin again. Sometimes the loopback server isn’t ready right after launch, and a clean restart plus a retry uses the right callback.
As an alternative to the Marketplace plugin, set up HubSpot MCP manually via mcp.json as a Streamable HTTP server. In some cases this uses the loopback callback instead of cursor://. Manual setup guide: Model Context Protocol (MCP) | Cursor Docs
Let me know if either of these helps. I’ll post here once we have an update on the main issue.
Update: after a full quit (Cmd+Q) and reconnect, Local is Connected — HubSpot tools work (e.g. get_user_details returns my user/hub).
Cloud still shows Needs Authentication; Authenticate fails with: redirect URL cursor://anysphere.cursor-mcp/oauth/callback is invalid.
So desktop/local is OK for now; Cloud Agents remain blocked by the cursor:// fallback.
Good news that Local came back up after a full restart. That means the local desktop flow is using the loopback callback, which is what it should do.
For Cloud, you’re hitting the same thing. For http(s)-only providers like HubSpot, the cloud flow currently falls back to cursor:// instead of using the loopback callback, and HubSpot rejects that redirect. This isn’t about your setup. You registered http://localhost:8787/callback correctly. Right now the user can’t force the cloud redirect, there’s no setting in mcp.json to switch it.
This is a known issue with http(s)-only providers. We’re tracking it, but I can’t share an exact ETA yet.
For now, the workaround is to use HubSpot MCP locally since Local is already Connected, and you’ll need to hold off on Cloud for this provider until an update. If the local flow breaks again, let me know.
+1 from another team. Cloud Agents are still blocked. Local is fine.
Team: UpMerch. We use HubSpot with Cursor Cloud Agents.
Date: 2026-08-18
What works
Desktop / Local HubSpot is Connected after a full quit (Cmd+Q) and reconnect. The HubSpot MCP Auth App redirect is the localhost 8787 callback, as staff confirmed.
What is still broken
Cloud Agents show Needs Authentication. Authenticate fails with: redirect URL cursor://anysphere.cursor-mcp/oauth/callback is invalid. HubSpot MCP Auth Apps only accept http or https. We cannot add a cursor:// URL.
We also tried the documented Cloud callback
Cursor docs say Cloud / web should use this:
We added that https URL in HubSpot. HubSpot can store it. Cloud still sent cursor://, so HubSpot still rejected the request. There is no mcp.json field to force the Cloud redirect. Dean already confirmed that.
Second Cloud bug while we were debugging
One Cloud auth attempt built an authorize URL with a literal placeholder: client_id=${CLIENT_ID} (shown as percent-encoded ${CLIENT_ID}). Cloudflare then blocked the HubSpot page. Local does not do this.
Why this matters
We run sales quota work in Cloud Agents. They need live HubSpot deal, invoice, and New Customer pipeline data. Until Cloud can send an http or https callback, we have to split the work: Cloud Agent for analysis, desktop chat for the live HubSpot pull.
Ask
Please count us as another team waiting on a Cloud OAuth fix for http-only providers like HubSpot. Happy to retest the same day a build ships.