Fix Cursor MCP NetSuite OAuth Redirect URI Errors

Cursor's switch from the cursor:// redirect scheme to http://localhost broke many NetSuite AI Connector setups. The error appears when you try to authorize the MCP server: the browser opens, spins, then hits "Retry" with no NetSuite tools appearing in Cursor.

The root cause isn't that NetSuite rejects loopback redirects. NetSuite's OAuth server accepts http://localhost redirect URIs under the RFC 8252 loopback exception. The real problem is that Cursor now grabs a random ephemeral port each time it starts the auth flow, and NetSuite requires an exact redirect URI match on the integration record.

Why the Redirect URI Mismatch Happens

RFC 8252 requires native apps to use loopback redirects with dynamic ports. Cursor follows this spec, which means the redirect URI changes on every authorization attempt. Your integration record has one static redirect URI saved. When Cursor redirects to http://localhost:52341/callback but your record says http://localhost:8080/callback, NetSuite rejects the handshake.

This is where most integrations break. The NetSuite documentation says HTTP isn't supported, yet the auth server happily accepts loopback redirects. The docs lag behind the implementation, which makes troubleshooting harder than it should be.

Step 1: Install mcp-remote as a Proxy

The cleanest workaround routes Cursor's MCP connection through mcp-remote, which handles the OAuth flow with a stable redirect URI.

npm install -g mcp-remote

This package acts as a bridge between Cursor and the NetSuite MCP endpoint. It manages the OAuth handshake and presents a consistent redirect target to NetSuite's authorization server.

Step 2: Enable Dynamic Client Registration

NetSuite supports Dynamic Client Registration (DCR) for the AI Connector Service. This lets Cursor register itself as an OAuth client at runtime, which bypasses the static redirect URI requirement.

1. Go to Setup > Integration > Manage Integrations
2. Open your existing integration record (or create a new one)
3. Check Dynamic Client Registration (DCR)
4. Enter Client Name as Cursor
5. Save the record

The client name must match what Cursor sends during registration. If you're using a different MCP client, use that client's name instead.

Step 3: Update Cursor's MCP Configuration

Edit your mcp.json file in Cursor to route through mcp-remote:

{
  "mcpServers": {
    "netsuite": {
      "command": "npx",
      "args": [
        "mcp-remote",
        "https://<account-id>.suitetalk.api.netsuite.com/services/rest/ai-connector/mcp"
      ]
    }
  }
}

Replace <account-id> with your NetSuite account ID from Setup > Company > Company Information.

Step 4: Test the Connection Flow

1. Restart Cursor completely
2. Open the MCP server list
3. Click Authorize on the NetSuite server
4. Complete the OAuth consent in your browser
5. Return to Cursor and verify the tools appear

The validation step: run a simple MCP tool call that reads a NetSuite record. If the tools load and return data, the handshake between systems is working.

What About the Grok Bot Limitation?

The Grok Bot custom MCP has a separate constraint. Its AddMcpServer function only accepts a name, URL, and optional headers. There's no way to attach OAuth client credentials or scopes. This blocks Grok Bot from completing the NetSuite authorization flow regardless of redirect URI configuration.

The NetSuite AI Connector requires a pre-registered public OAuth client with authorization-code plus PKCE. Grok Bot's MCP client can't supply those parameters. This isn't a NetSuite limitation; it's a missing feature in Grok Bot's MCP implementation.

Checking the Integration Record Automatically Created

When a user connects an AI client for the first time, NetSuite creates an integration record automatically under Setup > Integration > Manage Integrations. This record has:

• Public Client enabled
• Redirect URI populated
• OAuth Authorization Code Grant enabled
• NetSuite AI Connector Service scope enabled

Administrators can disable the integration or allocate a concurrency budget share to it. Every MCP call appears in the AI Connector Service (MCP) subtab of the integration record, which is where you verify activity and audit usage.

What to Check When Authorization Still Fails

If you've configured everything and the auth still fails, trace the data flow:

1. Confirm the redirect URI in Cursor's logs, look for the actual localhost port Cursor attempted to use
2. Verify the integration record's redirect URI, it must match exactly, including the port
3. Check the client name spelling, DCR matching is case-sensitive
4. Review the AI Connector Service (MCP) subtab, failed attempts appear here with error details

Test this with a single record first. Connect once, verify the tools load, then expand usage. The error response tells you exactly what went wrong, so read it before changing configuration.

When to Fall Back to Alternative Connectors

If the loopback workaround still fails, the pre-configured OpenAI ChatGPT option won't help. NetSuite doesn't support that integration due to a redirect URL routing limitation on ChatGPT's side. Your alternatives are Claude's connector or a direct RESTlet-based integration that bypasses the AI Connector Service entirely.

For a custom RESTlet approach, you control the full OAuth flow and can pin the redirect URI to a fixed port. This trades the MCP convenience for complete control over the handshake between systems.

The DCR approach with mcp-remote is the most reliable path forward for Cursor. It's fault-tolerant by design because the client registration handles the dynamic port issue automatically.