An open-source MCP boilerplate gives you a scaffold: a server skeleton, a few stub tools, and usually a local stdio setup. A kit-backed remote OAuth recipe gives you the Connect path end to end: Protected Resource Metadata (PRM), surviving the 401 challenge, PKCE, the drift between Cursor and Claude, the static CLIENT_ID path when DCR isn’t available, and a failure card for when Connect breaks. They do different jobs, so this page compares jobs, not scores. If your server only runs over stdio on your own machine, a free OSS boilerplate may be all you need.
Who this is for
Builders who have cloned an MCP template, gotten tools working locally, and then hit a wall when the server has to be remote and authenticated for Cursor and Claude. If your server only runs over stdio on your own machine, a free OSS boilerplate may be all you need, and that's fine. If the question is "why does Connect fail after the browser hop?", keep reading.
This is not a "best MCP starter kit" listicle. There's no leaderboard here, no ranked scores, and no SaaS-boilerplate comparison. It's one honest contrast between two kinds of starting point.
What OSS MCP boilerplates usually own
Most open-source MCP templates do a solid job at:
- Server skeleton: transport wiring, a request handler, project layout.
- Tool stubs: one or two example tools that show the schema shape.
- Local-first setup: stdio transport, run it next to your editor, no auth needed.
- Community breadth: many languages and frameworks, free to fork.
What they often leave to you is the remote auth story: discovery metadata, challenge headers, client registration, and the small ways different MCP clients read the same spec. That isn't a flaw. A scaffold is a scaffold. But auth drift is where most "it works locally" servers stop working.
What a kit-backed remote OAuth recipe owns
The MCP Starter Kit is opinionated about the part boilerplates skip:
- PRM: serving the protected-resource metadata clients look for, so discovery doesn't dead-end.
- Challenge survival: a `401` with the right `WWW-Authenticate` shape, so the client actually starts OAuth instead of giving up.
- PKCE: done the way the clients expect, not "almost."
- Cursor vs Claude drift: where the two clients differ on redirect handling and registration, and how one server serves both.
- Static `CLIENT_ID` path: for when Dynamic Client Registration isn't available or isn't wanted. Field names live in docs and secret values live in env, never in a published `mcp.json`.
- Failure card: symptom → likely cause → fix, so you're reading a known list instead of guessing.
The full walkthrough is in the live pillar: Build a remote MCP server with OAuth that Cursor and Claude can both Connect to.
Contrast table (jobs, not scores)
| Job | Typical OSS MCP boilerplate | Kit-backed remote OAuth recipe |
|---|---|---|
| Server skeleton + tool stubs | Yes, its core job | Included, but not the point |
| Local stdio dev loop | Yes | Yes |
| Remote transport | Sometimes | Yes |
| PRM / discovery metadata | Usually left to you | Yes |
| `401` challenge shape | Usually left to you | Yes |
| PKCE flow wired for real clients | Varies | Yes |
| Cursor vs Claude Connect differences | Rarely covered | Yes, documented |
| Static `CLIENT_ID` (non-DCR) path | Rarely covered | Yes |
| Failure card for Connect errors | Rarely | Yes |
| Price | Free | $27 |
Read it as "who does which job." Neither column wins. If your rows are all at the top of the table, free is the right answer.
When OSS is enough vs when the kit earns its keep
OSS is enough when:
- The server is local-only (stdio) and only you use it.
- You're learning MCP and want to read a variety of scaffolds.
- You already know OAuth well and want to wire discovery and PKCE yourself.
The kit earns its keep when:
- The server has to be remote and authenticated for Cursor and Claude.
- You've already lost an afternoon to "Connect opens the browser, then nothing."
- You want a working recipe and a failure card instead of piecing together specs, issues, and forum threads.
Either way, keep secrets out of examples: name env vars, never paste values. See never put secrets in chat.
Proof of category: the live pillar
You don't have to buy anything to see what the kit's approach looks like. The MCP OAuth pillar walks through the same Connect path in public. The kit packages that path as a working recipe, plus the failure card and client-drift notes, so you aren't rebuilding it from the article.
Soft next step
Write down which rows of the contrast table your server actually needs. If they're all scaffold rows, stay on your OSS boilerplate. If any are auth rows, read the MCP OAuth pillar first, start on /free, and pick up the MCP Starter Kit ($27) when you want the recipe in hand. No rush, and the table is useful either way.