Summary
Installing the OutSystems MCP server in Cursor (following the "Install - other AI assistants" path in the README) fails during OAuth Dynamic Client Registration. The server rejects Cursor's registered cursor://... callback URI, blocking the handshake before any tool listing happens. As a result, no outsystems tools surface in the harness.
A mcp-remote stdio bridge works around it (because the bridge opens its own http://localhost:PORT/callback), but native Cursor wiring per the README is non-functional.
Environment
- Harness: Cursor (desktop, macOS),
anysphere.cursor-mcp extension
- Cursor MCP wiring: streamable HTTP transport (
mcpServers.outsystems.url pointing at https://<tenant>/mcp), per the README "other AI assistants" recipe
- Tenant:
morpheus-qa.outsystemsrd.dev
- Cursor MCP OAuth callback scheme:
cursor://anysphere.cursor-mcp/oauth/callback
Steps to reproduce
-
In Cursor, add to ~/.cursor/mcp.json:
{
"mcpServers": {
"outsystems": {
"url": "https://<tenant>/mcp"
}
}
}
-
Restart Cursor.
-
Wait for MCP initialization. Observe that the outsystems server transitions initializing → error and no tools register.
Actual log output
From Cursor's per-server MCP log (exthost/anysphere.cursor-mcp/MCP user-outsystems.log):
[V2 FSM] connection:connect_start: conn=idle,auth=unknown -> conn=connecting,auth=unknown
MCP OAuth provider initialized
MCP HTTP exchange completed
MCP HTTP exchange completed
MCP HTTP exchange completed
Registration lock acquired after stale cleanup — this provider will register
No stored client information found
MCP HTTP exchange completed
Transient error connecting to streamableHttp server: redirect_uri "cursor://anysphere.cursor-mcp/oauth/callback" rejected: redirect_uri must use scheme http for loopback
Connection failed: redirect_uri "cursor://anysphere.cursor-mcp/oauth/callback" rejected: redirect_uri must use scheme http for loopback
[V2 FSM] connection:connect_failure: conn=connecting,auth=unknown -> conn=failed,auth=unknown
CreateClient completed, connected: false, statusType: error
The DCR redirect_uri validation strictly enforces http:// for loopback addresses and rejects Cursor's custom URL scheme.
Expected
The OAuth authorization server accepts Cursor's cursor://anysphere.cursor-mcp/oauth/callback redirect URI during Dynamic Client Registration so that the install path from the README's "Install - other AI assistants" section works end-to-end in Cursor — matching how Claude Code and Kiro currently work.
OAuth 2.1 / RFC 8252 § 7.1 explicitly permits private-use URI scheme redirects for native apps (as an alternative to loopback HTTP and claimed https:// URIs). Custom schemes like cursor://, cursor-vscode://, vscode://, code-oss://, etc. are the standard pattern for desktop IDEs that don't want to spin up an ephemeral local HTTP server per OAuth flow.
Suggested fix
In the AS's redirect_uri validation, accept private-use URI schemes (anything with a .-containing reverse-DNS-style scheme name, per RFC 8252 § 7.1) in addition to http:// loopback. At minimum, allowlist the known scheme(s) used by harnesses the README claims to support best-effort: cursor://, plus whatever Continue / Cline / Codex CLI / Cursor use.
Workaround
Bridging through mcp-remote works:
{
"mcpServers": {
"outsystems": {
"command": "npx",
"args": ["-y", "mcp-remote", "https://<tenant>/mcp"]
}
}
}
This shifts the OAuth flow into mcp-remote's local http://127.0.0.1:PORT/callback loopback, which the AS accepts. But it adds a runtime npm dependency and an extra hop, which the "other AI assistants" install instructions specifically try to avoid.
Impact
Any Cursor user following the README's documented install path hits this on first restart with no surfaced auth UI to recover (the failure happens during DCR, before the lazy authenticate tool would have a chance to run). The error is only visible by reading per-server MCP logs.
Summary
Installing the OutSystems MCP server in Cursor (following the "Install - other AI assistants" path in the README) fails during OAuth Dynamic Client Registration. The server rejects Cursor's registered
cursor://...callback URI, blocking the handshake before any tool listing happens. As a result, nooutsystemstools surface in the harness.A
mcp-remotestdio bridge works around it (because the bridge opens its ownhttp://localhost:PORT/callback), but native Cursor wiring per the README is non-functional.Environment
anysphere.cursor-mcpextensionmcpServers.outsystems.urlpointing athttps://<tenant>/mcp), per the README "other AI assistants" recipemorpheus-qa.outsystemsrd.devcursor://anysphere.cursor-mcp/oauth/callbackSteps to reproduce
In Cursor, add to
~/.cursor/mcp.json:{ "mcpServers": { "outsystems": { "url": "https://<tenant>/mcp" } } }Restart Cursor.
Wait for MCP initialization. Observe that the
outsystemsserver transitionsinitializing → errorand no tools register.Actual log output
From Cursor's per-server MCP log (
exthost/anysphere.cursor-mcp/MCP user-outsystems.log):The DCR
redirect_urivalidation strictly enforceshttp://for loopback addresses and rejects Cursor's custom URL scheme.Expected
The OAuth authorization server accepts Cursor's
cursor://anysphere.cursor-mcp/oauth/callbackredirect URI during Dynamic Client Registration so that the install path from the README's "Install - other AI assistants" section works end-to-end in Cursor — matching how Claude Code and Kiro currently work.OAuth 2.1 / RFC 8252 § 7.1 explicitly permits private-use URI scheme redirects for native apps (as an alternative to loopback HTTP and claimed
https://URIs). Custom schemes likecursor://,cursor-vscode://,vscode://,code-oss://, etc. are the standard pattern for desktop IDEs that don't want to spin up an ephemeral local HTTP server per OAuth flow.Suggested fix
In the AS's
redirect_urivalidation, accept private-use URI schemes (anything with a.-containing reverse-DNS-style scheme name, per RFC 8252 § 7.1) in addition tohttp://loopback. At minimum, allowlist the known scheme(s) used by harnesses the README claims to support best-effort:cursor://, plus whatever Continue / Cline / Codex CLI / Cursor use.Workaround
Bridging through
mcp-remoteworks:{ "mcpServers": { "outsystems": { "command": "npx", "args": ["-y", "mcp-remote", "https://<tenant>/mcp"] } } }This shifts the OAuth flow into
mcp-remote's localhttp://127.0.0.1:PORT/callbackloopback, which the AS accepts. But it adds a runtime npm dependency and an extra hop, which the "other AI assistants" install instructions specifically try to avoid.Impact
Any Cursor user following the README's documented install path hits this on first restart with no surfaced auth UI to recover (the failure happens during DCR, before the lazy
authenticatetool would have a chance to run). The error is only visible by reading per-server MCP logs.