Cursor using wrong url for token exchange when authorizing an MCP server

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

We have reports of users not being able to install the RevenueCat MCP (https:// mcp.revenuecat. ai/mcp) server as it fails to run the authorization.

It fails to perform the authorization code exchange as it is using an invalid url for the token endpoint, https:// api.revenuecat. com/token instead of https:// api.revenuecat. com/oauth2/token as exposed by the authorization server metadata (https: // mcp.revenuecat. ai/.well-known/oauth-authorization-server): "token_endpoint":"https: // api.revenuecat. com/oauth2/token"

(had to add spaces to the urls as it complained about being too many…)

Steps to Reproduce

Install the mcp (https: //cursor. com/en/install-mcp?name=revenuecat&config=eyJ1cmwiOiJodHRwczovL21jcC5yZXZlbnVlY2F0LmFpL21jcCJ9)

{
“mcpServers”: {
“revenuecat”: {
“url”: “https: // mcp.revenuecat. ai/mcp”,
“headers”: {}
}
}
}

and authorize it, it will fail when invoking to the token endpoint which answers with a 404

Expected Behavior

It should use the right token exchange url exposed in the authorization metadata

Operating System

Linux

Version Information

Version: 3.1.14
VSCode Version: 1.105.1
Commit: d8673fb56ba50fda33ad78382000b519bb8acb70
Date: 2026-04-14T01:39:23.679Z
Layout: editor
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Darwin arm64 25.3.0

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

Hi @German_Lena,

Thanks for the detailed report and the pointer to the authorization server metadata. You’ve correctly identified the issue: when the token endpoint is on a non-default path (like /oauth2/token), Cursor isn’t using the token_endpoint value from the authorization server metadata and instead falls back to an incorrect URL.

This is a known issue affecting MCP servers that use a separate authorization server with custom token endpoint paths. You can see similar reports from users of other MCP providers in this thread.

Our engineering team is actively working on a fix. Unfortunately there isn’t a client-side workaround available right now since the issue is in the internal token exchange logic.

We’ll make sure this report is tracked alongside the fix effort. Apologies for the inconvenience.

Thank you for confirming it. Is there any ETA on the fix?

Hey @German_Lena!

Please give it a try in v3.2 and let us know if it’s working now.

Is there any update? Becase Cursor is at 3.3 but RC MCP is not working still.

Could you share what specific error you’re seeing and your exact Cursor version (Help > About)? For example, does the authorization flow open in the browser, and does it fail with a 404 during the token exchange step?

Several OAuth improvements have shipped since this thread was opened, but there may still be cases that need additional work. Could you please create a new thread with the specifics so we’re able to better track and address the issue?

Hi,
I am using 3.3.0 and after I added RevenueCat MCP as described at their web site ( RevenueCat MCP Server Setup | In-App Subscriptions Made Easy – RevenueCat , only change was servers should be mcpServers according to linter) I can see RevenueCat at MCP List with a button Connect.
After pressing Connect button, RevenueCat web page opens and I click Authorize button than returning back to cursor.

This time Cursor says Error - Show output below RevenueCat listing at MCP list.

And here is the output.

2026-05-10 15:33:08.407 [warning] MCP HTTP exchange completed

2026-05-10 15:33:08.408 [error] OAuth fallback failed after MCP server returned 401 for configured Authorization header; surfacing original 401 Streamable HTTP error: Server returned 401 after successful authentication

2026-05-10 15:33:08.409 [warning] Connection failed: HTTP 401 Unauthorized from MCP server while using configured Authorization header

2026-05-10 15:33:08.409 [warning] [V2 FSM] connection:connect_failure: conn=connecting,auth=unknown → conn=failed,auth=unknown

2026-05-10 15:33:08.409 [info] ReloadClient completed, connected: false, statusType: error

Looking at your error logs, this is actually a different issue from what this thread originally tracked. The original bug was a 404 during the token exchange step (wrong URL), which has since been fixed. Your error is a 401 after the OAuth flow completes — meaning the token exchange itself succeeds, but the token is then rejected by RevenueCat’s server when Cursor tries to connect.

Could you create a new thread for this so our team can properly track it? Please include:

  1. Your full Cursor version (Help > About — paste the full block)

  2. The MCP output logs you shared here

  3. Your exact mcp.json / MCP config

  4. Whether this is your first time trying RevenueCat MCP, or if it worked before on an earlier version

That will help us investigate the 401 specifically rather than it getting lost in this resolved thread.

I was able to authenticate and perform tool calls without issues using v3.3.30

But I see the request still being made to https :// api.revenuecat.com/ oauth2/ token instead of oauth/token