When your authorization server has no Dynamic Client Registration (DCR), remote MCP Connect still works—you ship a static CLIENT_ID path instead of runtime registration. Put only the non-secret auth fields your IDE documents into client config (often mcp.json or Connect settings). Keep CLIENT_SECRET and anything that grants access in server-side env or a secret store—never chat, never a published mcp.json, never AGENTS.md. Static clients do not skip Auth Code + PKCE or Protected Resource Metadata. Register each client’s redirect URI exactly, then prove Connect in both Cursor and Claude. Soft path: start at /free. Kit-backed remote layout: the MCP Starter Kit ($27).
When static CLIENT_ID is the path
DCR (RFC 7591) lets a client register itself and receive a `CLIENT_ID` at runtime. If the AS has no DCR—or you prefer not to expose registration—you mint the client in AS admin (or IaC) and document the static path for every IDE that Connects.
You still need the shared remote OAuth sequence from the live pillar Build a remote MCP server with OAuth that Cursor and Claude can both Connect to: unprotected probe → 401 with `WWW-Authenticate` + `resource_metadata` → browser Auth Code + PKCE → tools appear. Skipping DCR does not let you swap that for API-key headers and call it MCP OAuth.
Decision context (DCR vs static): Do I need Dynamic Client Registration for remote MCP?. Pocket skim for PKCE / PRM / redirects: MCP auth checklist.
mcp.json shape (static client)
Exact keys depend on your Cursor / Claude build—follow the client’s MCP auth docs for your version. The shape below is the safety contract, not invented field names:
| Field / concern | Safe in client `mcp.json` / UI? | Where it actually lives |
|---|---|---|
| Remote MCP `url` | Yes | Client config |
| Static `CLIENT_ID` (public id only) | Only if your IDE treats it as non-secret | Prefer env / secret store when the client supports it; never publish a repo that embeds production ids you wouldn’t show a stranger |
| `CLIENT_SECRET` / refresh material | No | Server-side env / secret store / AS admin |
| Redirect URI | Register on the AS—not as a secret | Exact string match per client |
| Audience / resource | Configured via PRM + AS | Must match what the token is minted for |
Do: document required env *names* in the kit README. Don’t: paste secrets into chat, commit a public client config that ships access, or dump credentials into `AGENTS.md`.
Safety checklist
- [ ] AS DCR support confirmed or static path chosen deliberately (see DCR when needed).
- [ ] Auth Code + PKCE still in use—not API-key-as-OAuth.
- [ ] Remote probe returns 401 + `WWW-Authenticate` + `resource_metadata` (checklist).
- [ ] Cursor redirect URI and Claude callback registered exactly.
- [ ] Secrets only in env / secret store—not chat, not published `mcp.json`, not `AGENTS.md`.
- [ ] Connect proven in both Cursor and Claude with the static client.
Debug order: MCP Inspector on the remote URL → confirm challenge → confirm static client fields per IDE docs → then redirect / audience diffs. Full failure narrative stays on the OAuth pillar.
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—including the static-client fallback when DCR isn’t available. Use it when you want a kit-backed layout instead of stitching vendor posts. Soft path: /free for the starter desk; Cheat Sheet when you want the pocket checklist mindset; 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
Document the static `CLIENT_ID` path once, keep secrets out of client configs, and prove 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 stays on the OAuth pillar; DCR decision on Do I need DCR?.