The production checklist
- Auth — OAuth 2.1 with PKCE; tokens stored encrypted; refresh handled centrally.
- Scopes — one per tool family; least-privilege defaults; visible on consent.
- Quotas — per-user and per-workspace rate limits; quota breach returns 429 with retry-after.
- Observability — latency, error rate, tokens, OAuth refresh failures, unique users per tool per day.
- Audit — append-only log; user_id, tool, input hash, output hash, status. See what holds up at review.
- Schema stability — versioned tools; deprecate before delete; one host-release-cycle deprecation window.
- Dry-run mode — every mutating tool supports a dry-run flag; hosts can preview before invoking.
- Rollback — blue/green deploys; tool registry can pin a previous version per workspace.
- Health —
/healthzreturns transport status, dependency status, and current tool count. - Docs — every tool has a one-line description and an example call. LLMs use these to pick correctly.
Use the checklist as a release gate
Don't ship a new MCP server to enterprise customers until every box is checked. Retrofitting is 3-5× the cost of doing it first.
FAQ
- What separates a prototype MCP server from a production one?
- Auth, observability, quotas, schema stability, and a rollback plan. Anything else is implementation detail.
- Is one big server better than many small ones?
- Many small ones. Per-domain servers keep blast radius small, scopes legible, and rollouts independent. Resist the monorepo-server temptation.
- How do I version MCP tools without breaking hosts?
- Never change a tool's name or input schema in place. Add v2 alongside v1, deprecate v1 with a console warning, remove after one host release cycle.
- What metrics matter day one?
- p50/p95/p99 latency per tool, error rate per tool, tokens per call, OAuth refresh failures, and unique users per tool per day. Without these you're flying blind.