MCP Turnkey

Production-grade, multi-tenant MCP servers in Python — scaffolded in one command.

Most MCP server examples are single-user, stdio-only demos. The moment you want to put one on the internet — so that each user connects their own account from claude.ai, Claude Desktop or Claude Code — you need an OAuth 2.1 Authorization Server with Dynamic Client Registration and PKCE, a consent screen against the “confused deputy” attack, encrypted token storage, strict tenant isolation, and a pile of serverless gotchas nobody writes down.

MCP Turnkey is that server, already built and tested. You run one command, get a renamed copy wired to your provider, and spend your time on the tools — not on OAuth.

python scripts/scaffold.py --name acme-crm --title "Acme CRM"
# → ../mcp-acme-crm: package mcp_acme_crm, slug acme_crm, green test suite

Why MCP Turnkey

Build the tools — not the OAuth. What sets it apart is the part almost nobody ships ready-made:

1. It solves the hard part of remote MCP. For claude.ai to connect, your server has to be a complete OAuth 2.1 Authorization Server — discovery, Dynamic Client Registration, PKCE. Most examples are single-user stdio; this one is multi-tenant from day one, with every user connecting their own account.
2. Security that is easy to miss, built in.
   • Protection against the confused deputy attack, which the MCP specification requires and few starters implement.
   • Upstream tokens encrypted with AES-256-GCM, behind default-deny row-level security.
   • The tenant comes only from the credential, so no prompt can reach another user’s data.
   • A STRIDE threat model that ships with every generated server.
3. A real, tested server — not a code generator. About 200 tests, including the whole OAuth flow without network, and CI proves on every push that a freshly generated project passes its own suite without a single edit.
4. Production lessons, already paid for. production-lessons.md lists real failures