mcp

Debug remote MCP OAuth with MCP Inspector

When remote MCP Connect fails in Cursor or Claude, start with MCP Inspector on the same remote URL—not client UI trivia. Probe without credentials, confirm 401, then confirm WWW-Authenticate exposes resource_metadata (Protected Resource Metadata). Only after that challenge is clean should you diff redirects, DCR vs static CLIENT_ID, or audience binding. This is the practical debug loop for the B01-style failures covered on the live OAuth pillar—challenge first, then client diffs. Soft path: /free. Kit-backed remote layout: the MCP Starter Kit ($27).

Who this is for

You’re shipping (or debugging) a remote MCP server that Cursor and Claude Connect must finish OAuth against. You want a repeatable Inspector loop before another hour in Connect settings.

Full recipe: Build a remote MCP server with OAuth that Cursor and Claude can both Connect to. Failure card: MCP OAuth failure card — WWW-Authenticate stripped. Pocket skim: MCP auth checklist (PKCE, PRM, redirects). Static client: mcp.json CLIENT_ID when DCR is missing. DCR decision: Do I need Dynamic Client Registration for remote MCP?.

Step 1 — Point Inspector at the remote URL

Use MCP Inspector against the same remote MCP URL the IDE will Connect to—not only a local stdio demo.

  1. Launch Inspector per your toolchain docs for the version you ship.
  2. Set the target to the production (or staging) remote URL.
  3. Do not trust a localhost tunnel that rewrites auth headers unless you also re-test past every CDN / proxy layer.

You’re proving the network challenge Cursor and Claude will see. A green local stdio session does not prove remote OAuth.

Step 2 — First 401 + WWW-Authenticate + resource_metadata

Probe without credentials: confirm status 401, then `WWW-Authenticate`, then `resource_metadata` pointing at your Protected Resource Metadata (PRM). If any of those three fail, stop. Fix the challenge (and anything that strips it—middleware, CDN, HTML error pages) before opening Cursor Connect or Claude `/mcp`. The failure card walks symptom → cause → fix when the header is gone.

Step 3 — Spot false greens

These look fine until Connect never opens a login:

False greenWhy it lies
“Works in Postman with an API key”API keys are not Auth Code + PKCE. Happy path starts from the unauthenticated 401 challenge.
Branded HTML error page on 401Hides the real challenge; often drops `WWW-Authenticate`.
Tunnel / proxy “success”Edge may strip or rewrite the challenge before the IDE sees it.
Inspector green on localhost onlyLocal stdio ≠ the remote URL Cursor/Claude hit.

Re-test with Inspector and a raw header dump past every layer until both agree the challenge survives.

Step 4 — Client Connect diffs (after challenge is clean)

When Inspector shows a clean 401 + challenge + `resource_metadata`, and Connect still fails in one IDE: diff redirect URIs (exact match), DCR vs static `CLIENT_ID` (DCR when needed, static CLIENT_ID), and audience / resource binding against your PRM identifier. Don’t restart from zero on the challenge—shared challenge first, client drift second. Dual-client notes stay on the OAuth pillar.

Debug checklist

  • [ ] Inspector pointed at the remote MCP URL (same as Cursor/Claude).
  • [ ] Unauthenticated probe returns 401 with `WWW-Authenticate` + `resource_metadata`.
  • [ ] Challenge survives CDN / proxy / HTML error pages.
  • [ ] False greens ruled out (API-key Postman, stripped headers, localhost-only).
  • [ ] Only then: client redirect / DCR / static `CLIENT_ID` / audience diffs.
  • [ ] Connect proven in both Cursor and Claude after the shared challenge is fixed.

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—challenge, PRM, and client paths included—not only a local stdio hello-world. Soft path: /free for the starter desk; Cheat Sheet for the pocket checklist / failure-card mindset; kit when you want the auth-ready layout instead of stitching vendor posts.

Soft next step

Run Inspector once on the real remote URL, confirm 401 + `WWW-Authenticate` + `resource_metadata`, then prove Connect in both Cursor and Claude. Soft ladder: /free for the starter desk, Cheat Sheet for the skim checklist mindset, or the MCP Starter Kit ($27) for the auth-ready remote layout. Deep recipe stays on the OAuth pillar; stripped-header card on WWW-Authenticate stripped.

FAQ

What should I point MCP Inspector at?+

The same remote MCP URL Cursor/Claude Connect to — not only a local stdio demo. You’re proving the network challenge the IDE will see.

What do I look for on the first 401?+

Status 401 plus WWW-Authenticate that exposes resource_metadata (Protected Resource Metadata). If either is missing or stripped, fix the challenge before client UI settings.

What are common false greens?+

“Works in Postman with an API key,” HTML error pages that hide the real 401, or tunnels/proxies that drop WWW-Authenticate. Those can look fine until Connect never opens a login.

Inspector succeeds — why does Claude/Cursor still fail?+

Shared challenge is fixed; now diff client redirects, DCR vs static CLIENT_ID, and audience/resource binding. Don’t restart from zero on the challenge.

Debug order?+

Inspector on remote URL → confirm 401 + challenge + resource_metadata → then client Connect. Full recipe: live MCP OAuth pillar; failure card: WWW-Authenticate stripped post.

Soft next step?+

Run Inspector once on the real URL, start at /free, then /products/mcp-starter-kit ($27) for the kit-backed remote layout.

Get the free starter

Value first, then a kit when you are ready. No fake urgency. Start with Harness Desk Starter at /free.