Cursor does not send 'application_type': 'native' when registering MCP OAuth clients

[EDjur]

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Hi,

When attempting to connect to an MCP OAuth server with DCR, cursor does not seem to send ‘application_type’: ‘native’, despite using a custom scheme URI:

{“url”:“cursor://anysphere.cursor-mcp/oauth/appname/callback”}

This causes client registration to fail for certain providers that follow the spec a bit more closely, e.g. node-oidc-provider will reject this client here: node-oidc-provider/lib/helpers/client_schema.js at e487fc33ac6030f89b9e93704eeb1c3bd83cc21f · panva/node-oidc-provider · GitHub

application_type is OPTIONAL in the spec, but web is the default, which leads to the above rejection.

So I agree it’s a bit of a grey area due to the field being optional. But native applications should be using ‘native’ as their application_type.

Thanks!

Steps to Reproduce

Register an MCP Oauth server with DCR support

Expected Behavior

Cursor to send ‘application_type’: ‘native’ as is customary for native applications with custom redirect URIs

Operating System

MacOS

Current Cursor Version (Menu → About Cursor → Copy)

Version: 1.7.38
VSCode Version: 1.99.3
Commit: fe5d1728063e86edeeda5bebd2c8e14bf4d0f960
Date: 2025-10-06T18:18:58.523Z
Electron: 34.5.8
Chromium: 132.0.6834.210
Node.js: 20.19.1
V8: 13.2.152.41-electron.0
OS: Darwin arm64 24.6.0

Does this stop you from using Cursor

No - Cursor works, but with this issue

[deanrie]

Hey, thanks for the report. You’re absolutely right that Cursor should be sending application_type: 'native' when registering MCP OAuth clients with custom scheme URIs like cursor://.

This is a legitimate issue - while the field is optional in the OAuth spec, native applications using custom redirect URIs should indeed specify native as their application type, and some providers (like node-oidc-provider) are stricter about this.

I’ll make sure this gets flagged with the team. The fix should be straightforward - just need to include that field in the DCR request when using custom scheme callbacks.

In the meantime, if you’re running your own OAuth server, you could probably work around this by configuring it to be more lenient about the application_type validation, but I understand that’s not always an option with third-party providers.

[EDjur]

Hey, thanks for the swift reply. And thank you for flagging it internally!