Cursor Connect works — why does Claude still fail?

Clients differ on redirect URIs, Dynamic Client Registration support, callback-port behavior, and how they send audience/resource parameters. One success is not proof the other client will finish the same OAuth dance.

What should I check first?

MCP Inspector on the remote URL — confirm 401 + WWW-Authenticate + resource_metadata before chasing Claude UI settings. If the challenge is broken, both clients will eventually fail; if only Claude fails, move to client-specific diffs.

Callback port / redirect issues?

Register Claude’s documented callback exactly (including callback-port paths your AS expects). A URI that works for Cursor’s cursor://…/oauth/callback form will not automatically satisfy Claude.

What if DCR is missing?

Plan on pre-configured / static CLIENT_ID (and careful secret handling) and document that path for Claude explicitly — don’t assume Cursor’s static-client setup is identical.

Login works in Claude but tools never appear?

Often wrong audience/resource on the token, or PRM resource identifier mismatch. Fix resource binding before rewriting Claude connector settings.

Do I need a separate server for Claude?

Usually no. One remote MCP + correct PRM/PKCE path should serve both; the drift is client Connect configuration, not a second product.

Diff Cursor vs Claude on a checklist, start at /free, then /products/mcp-starter-kit ($27) for the kit-backed dual-client recipe. Cheat Sheet for the skim failure card.

Why Claude fails MCP auth when Cursor works

When Cursor Connects to your remote MCP server but Claude’s /mcp OAuth fails after login—or never opens a browser—you’re hitting client drift, not a broken product. Redirect URIs, Dynamic Client Registration (DCR), callback-port behavior, and how each client sends audience / resource parameters differ. One success is not proof the other will finish the same dance. Fix the shared 401 + WWW-Authenticate + resource_metadata challenge first, then walk the Cursor-vs-Claude diff and fix order below. Soft path: the free desk on /free. Kit-backed dual-client recipe: the MCP Starter Kit ($27).

The failure you’ll actually see

Cursor shows tools after Connect. Claude stalls on “Needs authentication,” drops after browser login, or never opens a callback. The remote URL is the same. The authorization server is the same. The clients are not. Treat this as a diff problem—redirects, DCR vs static `CLIENT_ID`, and resource binding—before you rewrite the server or spin up a second MCP host.

For the full remote OAuth recipe both clients share, see the live pillar Build a remote MCP server with OAuth that Cursor and Claude can both Connect to. For a skim checklist of PKCE, PRM, and redirects, see `mcp-auth-checklist-pkce-prm`. For when DCR is optional vs required, see `dcr-when-needed-remote-mcp`.

Diff table: Cursor vs Claude

Dimension	Cursor	Claude	What breaks if you ignore it
Entry point	Remote `url` + Connect	`/mcp` OAuth / connector flow	“Works in Cursor” never exercises Claude’s UI path
Redirect / callback	Often `cursor://…/oauth/callback`	Documented Claude callback (incl. callback-port paths)	Login succeeds, token exchange fails on URI mismatch
DCR	May register at runtime if AS supports it	Same idea; failure modes and prompts differ	DCR errors on every Connect when AS has no DCR
Static client	`auth.CLIENT_ID` (and related fields) per Cursor MCP auth docs	Pre-configured credentials path — document explicitly	Cursor static setup does not auto-satisfy Claude
Audience / resource	Client-specific how params are sent	Often stricter or differently labeled	Login works, tools never appear
Debug surface	Connect status + Inspector	`/mcp` errors + Inspector	Chasing UI quirks while the 401 challenge is already broken

Authorities for client UI details: Cursor MCP docs and Claude MCP auth docs. This article owns the diff and the fix order.

Fix order (stop when the step fails)

MCP Inspector on the remote URL — confirm unprotected probe → 401 with `WWW-Authenticate` including `resource_metadata`. If middleware or a CDN strips the challenge, both clients will eventually fail; fix that before Claude settings.
PRM + Auth Code + PKCE — Protected Resource Metadata points at the right authorization server; tokens use Auth Code + PKCE (not “API key in a header called OAuth”).
Audience / resource binding — PRM resource identifier matches what the AS mints. Wrong audience looks like “login worked, tools never load.”
Redirect URIs per client — register Cursor’s and Claude’s documented callbacks exactly. A URI that works for `cursor://…` will not automatically satisfy Claude’s callback-port path.
DCR vs static `CLIENT_ID` — if the AS doesn’t support DCR, ship the static-client path and document it for both clients. Don’t assume Cursor’s static fields are identical in Claude. Details: `dcr-when-needed-remote-mcp`.
Re-test Claude only after 1–5 are green — then chase Claude-specific connector UI. One Cursor success still isn’t dual-client proof.

Do not stand up a second remote MCP “for Claude.” One resource + correct PRM/PKCE + client-specific Connect config is the usual fix.

What the MCP Starter Kit is for

The MCP Starter Kit ($27) is aimed at shipping remote MCP with Cursor and Claude Connect in mind—not only a local stdio hello-world. Use it when you want a kit-backed dual-client layout instead of stitching vendor posts and guessing which redirect broke Claude. Soft path if you’re not buying yet: /free for the starter desk, then the kit when you’re wiring production Connect. Pair with the checklist companion (`mcp-auth-checklist-pkce-prm`) when you want the failure card in your pocket.

Soft next step

Prove the shared challenge (401 + `WWW-Authenticate` + `resource_metadata`), then walk the Cursor-vs-Claude fix order until both clients show tools. Soft path: /free. When you want the dual-client recipe packaged, use the MCP Starter Kit ($27). Cross-check the live MCP OAuth pillar, the checklist `mcp-auth-checklist-pkce-prm`, and `dcr-when-needed-remote-mcp` when DCR vs static is the open question.