OAuth 2 redirect URL cursor:// not supported with vendor

I’m trying to add an MCP server to cursor, but the MCP does not allow redirect URLs to be configured that does not start with https or http.

Is there a workaround for this? Is there another URL not under the custom protocol?

Can you provide the MCP server you are trying to connect to?

Hi Chris,

This is a hosted MCP Server from Qlik, called Qlik Cloud MCP Server. It gives access to Qlik Cloud user to query analytics assets, data and everything hosted in the customer tenant for Qlik Cloud.

Here is the documentation: https://help.qlik.com/en-US/cloud-services/Subsystems/Hub/Content/Sense_Hub/QlikMCP/Qlik-MCP-server.htm
Specifically hooking up clients: https://help.qlik.com/en-US/cloud-services/Subsystems/Hub/Content/Sense_Hub/QlikMCP/Connecting-Qlik-MCP-server.htm

Unfortunately, the “limitation” on http/https is not explicitly stated, except the UI giving an error referencing an rfc: “redirecturis scheme needs to follow rfc8252 got “cursor” in “cursor://anysphere.cursor-mcp/oauth/callback”

I understand this is likely a vendor responsibility, but I’m looking for a workaround, or alternative https/https redirect uri for Cursor.

Cursor’s MCP OAuth flow registers cursor://anysphere.cursor-mcp/oauth/callback as its redirect URI. Qlik Cloud’s OAuth validator rejects single-word custom schemes. Per their official docs, Native clients only accept https://, http://localhost, or reverse-domain custom schemes (e.g. com.example.app://). There’s no way to override the redirect URI on Cursor’s side.

The real fix is on Qlik’s side. The pre-built Claude and ChatGPT OAuth clients use first-party https:// callback URLs (https://claude.ai/api/mcp/auth_callback). Cursor has no equivalent. The cleanest resolution would be for Qlik to either add http://localhost support to the MCP OAuth client, or document a supported redirect URI that Cursor’s native OAuth flow can use.

It’s worth raising with Qlik support directly.

A potential workaround is to try mcp-remote, a local stdio proxy that handles the OAuth flow using http://localhost, which Qlik does accept. In theory:

  1. Create a Native OAuth client in Qlik Cloud Administration → OAuth with scopes user_default + mcp:execute and redirect URL http://localhost:3334
  2. Configure Cursor to use it via mcp.json:
{
  "mcpServers": {
    "qlik": {
      "command": "npx",
      "args": ["mcp-remote", "https://<your-tenant>.qlikcloud.com/api/ai/mcp"]
    }
  }
}

However**, be aware of two real issues** before going this route:

  • Real-world reports (e.g. Atlassian MCP + Cursor) describe frequent re-authentication prompts — per window and every few hours — making it “really unusable” in practice
  • mcp-remote had a critical security vulnerability (CVE-2025-6514, CVSS 9.6) in versions 0.0.5–0.1.15 allowing arbitrary command execution via malicious MCP servers. Fixed in v0.1.16 — make sure you’re on a current version

The bottom line: Qlik needs to provide a fix on their end, and the only workaround is kind of hacky.

Actually, per their documentation, “Native” OAuth applications registered in Qlik Cloud should support custom uri schemes: “URLs must begin with https:// unless the domain is localhost, in which case it can start with http://. Native applications can also use the application-specific link format, for example, exampleapp://.” Source: Creating and managing OAuth clients | Qlik Cloud Help

However, I’m getting the same error, so this must be a bug with Qlik Cloud. I already have a ticket open, I’m gonna refer to that.

Hey, yes, you’ve nailed it. If Qlik’s docs say Native apps support custom URI schemes like exampleapp://, then cursor:// should work too. Sounds like a bug on their side.

Cursor uses cursor://anysphere.cursor-mcp/oauth/callback as the redirect URI for MCP OAuth, and there’s no way for us to change it to an https:// URL. So getting Qlik to fix their validation is the right move.

In the meantime, the mcp-remote workaround Chris mentioned is probably your best bet if you need this working now. Just make sure you’re on v0.1.16+ because of the security fix.

Let us know how it goes with Qlik support.