This is a known bug. When Cursor connects to HTTP-based MCP servers, it automatically starts an OAuth flow even for localhost servers that don’t need it. That’s why it works through npx using stdio transport, but not through an HTTP URL.
The team is aware of the issue. I can’t share an exact ETA for a fix, but your repeated report helps with prioritization.
For now, the workaround is to use stdio transport via npx, like you’re already doing. If your server supports passing auth via headers, you can try this in mcp.json:
But if your server uses full OAuth2 with DCR like you described earlier, the headers workaround most likely won’t help, and stdio is the only working option for now.
Can you share the MCP logs from the current version using View > Output and then selecting MCP user-{server-name}? I want to confirm it’s the same error and not something new in v3.0.16.
It seems can’t keep a real issue open due to bot-auto-closure… hence the re-posting. To add a fixed token is not secure, API tokens and static access tokens are a non-starter in professional work.
Thanks for the logs. Sadly, they show the same error pattern as the first file. Every connection attempt ends with Error POSTing to endpoint right after connect_success. What you see as “connected” in the screenshot is most likely a brief moment between a successful handshake and the POST request failing, the UI just doesn’t update in time.
So there isn’t a stable HTTP connection in any of the logs. The bug is confirmed and the data has been shared. Until there’s a fix, stdio via npx is still the working option.
Let me know if you see a case where tools actually run over HTTP, then the situation might be different.
The agent does find the tools and resources when it is in connect status. So the whole DCR, authorization server discovery and server all seems to work fine, except the consent flow on the webpage and cursor connecting when call back is called.
Here is what user-localhost-direct exposes for resource_1 and what came back when it was fetched.
Descriptor (resource_1)
URI: https://www.resources.com/resources_1
Name: resource_1
Description: fake resource
Fetched content
MIME type: text/plain
Body:
Just a piece of text
So…. dunno what assumption was made on an existing bug that MCP does not run over http ?
Server response:
{“jsonrpc”:“2.0”,“id”:39,“result”:{“contents”:[{“uri”:“file:///home/user/documents/readme.txt”,“mimeType”:“text/plain”,“text”:“Just a piece of text”}]}}
and BTW would expect Cursor to give some kind of HTTP response in the browser that the connection was successful , that would help, but all these vscode apps seems to have the same issue and probably based on the same kind of library .
P.s: Not sure why localhost server don’t need Oauth2. over http. This is a way to develop and test server before deployment on other servers. Like any servers on the local network don’t need Oauth2 either, that would be real security issue. Why would one be forced to need two computers or a VM or docker instance to develop an MCP server ? its not preferred someone or something that has access to my PC and steal any static tokens which may result the resources the MCP server is connected to are being accessed or changed.
You’re right, new info changes the picture. I can see the HTTP transport is working, and tools and resources are returning data. My previous conclusion was based on the first set of logs.
From your description, the issue is specifically in the consent flow. DCR and discovery work, but Cursor doesn’t handle the OAuth callback correctly during the initial connection. That explains the pattern error, open settings, close, connected. The reconnect likely reuses already issued tokens and skips the broken callback step.
I also agree about localhost plus OAuth2, that’s a standard setup for developing MCP servers. We don’t think localhost servers don’t need OAuth. The problem is the callback flow implementation on our side.
About showing an HTTP response in the browser after a successful connection, I noted it as feedback. I agree it’d be useful.
So what’s next to fix this ? Cursor can confirm this as a bug ? what the milestone / date / version to fix this ? The same thing happens after clearing all the tokens. So it’s not reusing token I assume. Sorry, to ask, but I feel like talking to a AI bot ? (AI is so smart now, it’s hard to differentiate, please don’t feel insulted if you are human)
Confirmed, this is a bug on our side in the OAuth callback flow for HTTP-based MCP servers. Your logs and repro steps made it really clear, and I’ve updated our internal ticket with the new details from this thread.
On timing, I can’t share a specific ETA or version number. I don’t want to promise something I don’t control.
If there are any updates on the fix, I’ll post them here.
Thanks a lot. Looking forward for the fix. Wondering why no one else reported this issue perhaps everyone else is using insecure local stdio / npx instead of secure direct streaming http or does not use localhost.
About the fact that not many users report it, most MCP server developers are probably using stdio and npx for local development. But that doesn’t mean the issue isn’t important. HTTP transport with OAuth on localhost is a valid and correct workflow. This is a bug on our side, and your detailed repro steps really helped. Thanks.
Many thanks, and BTW, Some other products do work with HTTP but fail with HTTPS self signed certificates. Sometimes this can be fixed by separate setting. This may be an added condition to consider when fixing this .
Hey @bug,
The OAuth callback issue for HTTP-based MCP servers on localhost has been addressed and the fix should be available on the nightly release channel. If you’d like to try it out before it hits stable: open Cursor Settings > About and switch the Release Track to Nightly, then restart Cursor. Let me know if that resolves it!
Still does not work. Something so simple so hard to fix ? After moving to another window and then coming back to settings, it’s then shows connected same as before. Now way to cleat the token, it start and agent to do this, but does not work either. IHMO after manually disconnecting the access and refresh tokens should be removed from memory and disk for the sake of security.
