A local MCP server that talks over stdio is a different animal from a remote MCP server that Cursor or Claude has to Connect to. Remote Connect almost always means OAuth: Protected Resource Metadata, an authorization code flow with PKCE, and a challenge header that survives your reverse proxy. This guide is the end-to-end recipe for that path—what to implement, where Cursor and Claude diverge, and the failure modes that waste a day. When you want a kit-backed pattern instead of stitching blogs together, start with the free desk on /free or go straight to the MCP Starter Kit ($27).
The problem you’ll actually hit
You ship a remote URL. In Cursor, the MCP entry sits on “Needs authentication.” In Claude, `/mcp` OAuth fails after login, or never opens a browser. Both clients can see the same host and still disagree about redirect URIs, Dynamic Client Registration (DCR), and how they send audience / resource parameters. Official Cursor and Claude MCP auth docs cover the pieces. What’s missing in most writeups is one working sequence that survives both clients—and a clear failure card when middleware eats the challenge.
Spec pieces in plain language (no fake scores)
You don’t need to memorize RFCs to ship this, but you do need the names:
- Protected Resource Metadata (PRM, RFC 9728) — your MCP resource publishes metadata (often under a `.well-known` path) so the client knows which authorization server protects it.
- Authorization Server Metadata — the AS advertises token and authorization endpoints.
- Authorization Code + PKCE — the browser login dance remote clients expect; don’t swap this for a long-lived API key in a header and call it “OAuth.”
- Dynamic Client Registration (DCR, RFC 7591) — optional. If your AS supports it, clients can register at runtime. If not, you ship a static `CLIENT_ID` (and careful secret handling) and document that path for both Cursor and Claude.
- Audience / resource binding — tokens must be minted for the right resource. Wrong audience looks like “login succeeded, tools never appear.”
API key headers on a remote URL can work for a private demo. They are not the same as MCP OAuth PKCE for Connect.
Minimal happy path
Aim for this sequence before you chase client-specific settings:
- Client probes the remote MCP URL without credentials.
- Server returns 401 with a `WWW-Authenticate` challenge that includes `resource_metadata` (pointing at your PRM).
- Client opens a browser against your authorization server.
- User completes login; client receives tokens via the OAuth redirect.
- Client retries MCP; tools appear.
If step 2 never happens cleanly, stop. Fix the challenge before you debug Cursor vs Claude UI quirks.
Cursor: remote URL, Connect, redirect URIs
In Cursor, configure a remote MCP server with a `url` (not only a local command). Use the Connect control when the server needs authentication. Register the Cursor redirect URI your build documents—commonly a `cursor://…/oauth/callback` style URI. When DCR is unavailable, set a static `auth.CLIENT_ID` (and related fields) in the way Cursor’s MCP auth docs describe for your version—don’t invent keys in chat or commit secrets into a shared `mcp.json` you publish.
Test Connect on the real remote URL, not only on localhost tunnels that strip headers.
Claude: `/mcp` OAuth and the static-client path
Claude’s MCP OAuth path (including `/mcp` flows and callback-port behavior) is close but not identical. If DCR is missing, plan on pre-configured credentials and document the static-client setup explicitly. A setup that “works in Cursor” is not proof Claude will finish the same dance—run both.
Point readers at Claude’s MCP auth docs and Cursor’s MCP docs as authorities for client UI details; this article owns the server-side recipe and the dual-client checklist.
Failure card (fix this first when Connect breaks)
| Symptom | Likely cause | What to check |
|---|---|---|
| Connect never opens a login UI | Middleware or CDN stripping `WWW-Authenticate` | Raw 401 response includes `resource_metadata`; bypass HTML error pages |
| Login works, tools never load | Wrong audience / resource on the token | PRM resource identifier matches what the AS mints |
| Cursor works, Claude fails (or reverse) | Redirect URI, DCR, or client auth differences | Test both clients; don’t assume parity |
| DCR errors on every Connect | AS doesn’t support DCR | Ship static `CLIENT_ID` path and document it |
| Intermittent 401 after success | Clock skew, cookie/proxy caching, or token refresh path | Inspector + server logs around refresh |
| “Works in Postman” but not in Cursor | You’re sending API keys, not completing MCP OAuth | Happy path must start from the 401 challenge |
Debug order: MCP Inspector against the remote URL → confirm 401 + `WWW-Authenticate` + `resource_metadata` → then client-specific Connect settings.
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 layout and examples instead of assembling half a dozen vendor posts. Pair it with a skimmable auth checklist (Cheat Sheet) when you want the failure card in your pocket. Soft path if you’re not ready to buy: grab the free starter desk at /free, then come back to the kit when you’re wiring production Connect.
If you’re also wiring coding agents that *consume* MCP tools, see the Agent Starter Kit—different job, same agent-ops shelf.
Soft next step
Get the challenge right (401 + `WWW-Authenticate` + `resource_metadata`), then prove Connect in both Cursor and Claude. When you want the pattern packaged, use /free for the starter desk, or the MCP Starter Kit ($27) for the auth-ready layout. No rush—ship the failure card into your own runbook either way.