Cursor MCP OAuth redirect URL: which one to allow

Cursor's MCP OAuth redirect URL is fixed: https://www.cursor.com/agents/mcp/oauth/callback for the web and Cursor Agents, and http://localhost:8787/callback for the desktop app. If an MCP provider makes you whitelist a redirect URL, register both when your users sign in from both places. Sume's hosted MCP server does not ask you to register anything by hand.

Cursor's values come from its MCP page, read 2026-09-29. The Sume side comes from MCP OAuth and API keys and, where marked, current code.

Which redirect URL does Cursor use?

The page adds that the server is identified through the OAuth state parameter, so these two URLs work for every MCP server. It lists this under providers that give you a fixed client ID and require whitelisting a redirect URL, for example Figma or Linear.

Do I have to register them with Sume?

No. In current code, Sume's authorization server exposes a registration endpoint and takes public clients only. It allows any https redirect URI, an http redirect on localhost or 127.0.0.1, and Cursor's own cursor://anysphere.cursor-mcp/oauth/callback. Both URLs in the table fit the first two rules, so there is no allow-list to edit.

A redirect that fits none of those rules is refused with OAuth redirect_uri is not allowed, and one that differs from what the client registered is refused with OAuth redirect_uri is not registered for this client.

How do I connect Cursor to Sume?

Add the hosted endpoint to Cursor's MCP config and let Cursor run OAuth. The consent page then shows Permissions with Read locked on and Write off by default, per MCP OAuth and API keys. For unattended use, an API key in the headers field works instead, using Cursor's ${env:NAME} syntax, which expands a variable inside the header value.

{
  "mcpServers": {
    "sume": {
      "url": "https://mcp.sume.com/mcp"
    }
  }
}

When does Cursor need static OAuth at all?

Cursor's page describes static OAuth for remote servers in mcp.json as the option for three cases: the provider gives you a fixed client ID and optionally a secret, the provider requires whitelisting a redirect URL, or the provider does not support OAuth 2.0 Dynamic Client Registration. You add an auth object with CLIENT_ID, an optional CLIENT_SECRET and optional scopes to a url entry. If scopes is omitted, Cursor discovers scopes_supported from /.well-known/oauth-authorization-server.

None of those cases describes Sume's hosted server in current code: it supports registration, and it accepts the redirects above. Sume registers public clients only, so a client secret does not apply. Leave the auth block out and let dynamic registration do the work.

What should I check if the redirect is refused?

The two messages above point at different causes. not allowed means the URI itself fits none of the accepted forms, for example a plain http address on a non-loopback host. not registered for this client means the client id is known but this exact redirect URI was not among the ones it registered. In current code, that comparison is an exact match against the client's registered list, so a changed port or path on a returning client id fails it.

If a returning client keeps hitting the second message, removing the server in Cursor and adding it again is a reasonable thing to try, since a new add registers its redirect afresh. Sume's docs describe the API-key path as the one for automation that does not speak OAuth, so for an interactive Cursor session keep to OAuth.