Protected Resource Metadata (PRM) is the discovery document remote MCP Connect uses after a clean 401 challenge. It tells the client where your authorization server (AS) lives and which resource identity the access token must cover—usually published at a .well-known/oauth-protected-resource URL relative to your MCP host. Cursor and Claude read PRM via resource_metadata on WWW-Authenticate; missing, 404, or wrong-host PRM means login never starts (or tools never appear). Without a reachable PRM behind that challenge, the client has nowhere to start login. Having an authorization server somewhere is not enough—Connect needs the map. This page explains PRM only—not the full OAuth recipe.
Why Connect cares about PRM
Remote Connect’s shared sequence (from the live pillar Build a remote MCP server with OAuth that Cursor and Claude can both Connect to):
- Unprotected probe of the remote MCP URL
- Server returns 401 with `WWW-Authenticate` exposing `resource_metadata`
- Client fetches PRM → finds the AS + resource identity
- Browser Auth Code + PKCE → tools appear
Without a reachable PRM behind that challenge, the client has nowhere to start login. Having “an authorization server somewhere” is not enough—Connect needs the map. Symptom card when the challenge is stripped or incomplete: MCP OAuth failure card — WWW-Authenticate stripped. Pocket skim: MCP auth checklist (PKCE, PRM, redirects).
Plain map of PRM fields
Exact key names follow RFC 9728 / your MCP auth docs—this is the safety map, not invented field trivia:
| Concern | What Connect needs | Common break |
|---|---|---|
| Resource identity | The resource the token must be minted for | Audience mismatch → login “works,” tools empty |
| Authorization servers | Which AS the client should open | Wrong host / staging AS in prod challenge |
| Scopes (when advertised) | What the client may request | Over- or under-scoped grants vs your tools |
| Location of the doc | Reachable URL in `resource_metadata` | 404, HTTP/HTTPS mismatch, CDN rewrite |
Publish PRM on the host the MCP URL claims. Clients resolve `.well-known/oauth-protected-resource` relative to that resource—don’t point `resource_metadata` at a different origin and expect Connect to forgive it.
Happy path vs broken PRM
Happy path: raw probe → 401 → `WWW-Authenticate` with `resource_metadata` → GET that URL returns PRM (not HTML) → AS + resource fields match what you configured.
Broken PRM (stop here):
- 404 / empty — challenge points at a doc that doesn’t exist
- Wrong host — staging PRM on a prod MCP URL (or reverse)
- HTTPS mismatch — mixed scheme; client won’t trust the map
- HTML error page — CDN or middleware replaced the JSON with a branded page
- Challenge stripped — see the failure card
Confirm with MCP Inspector (and a raw header dump) before opening Cursor Connect or Claude `/mcp`. DCR vs static `CLIENT_ID` is a separate decision: Do I need Dynamic Client Registration for remote MCP?—neither path skips PRM.
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, PKCE, and dual-client paths included—not only a local stdio hello-world. Soft path: /free for the starter desk; Cheat Sheet for the pocket checklist mindset; kit when you want the auth-ready layout instead of stitching vendor posts.
Soft next step
Publish a reachable PRM, prove 401 + `resource_metadata` with Inspector, then Connect in both Cursor and Claude. Soft ladder: /free for the starter desk, Cheat Sheet for the skim checklist, or the MCP Starter Kit ($27) for the auth-ready remote layout. Full recipe: OAuth pillar; challenge breakages: failure card; pocket skim: auth checklist; DCR decision: Do I need DCR?.