Shipping MCP to Production Without Breaking Your Product
The demo worked. Someone connected an agent, ran a happy-path tool call, and the room nodded.
Production is a different product.
This checklist is for product owners and ops leads who need MCP live without becoming the support queue for "the agent did something weird."
What demos hide
- Auth that only works for one test account
- No rate limits when an agent loops
- Giant JSON responses that look fine once and bankrupt token budgets at volume
- No rollback if a bad tool ships on Friday
- No named owner when a customer asks who broke their data
If you can't answer those, you're not deploying a feature. You're deploying a liability.
Go-live checklist
1. Auth matches how customers already access you
Use the same trust model as your product: OAuth, API keys with least privilege, or your existing session exchange. Document revoke. Test a compromised key path before launch.
2. Tenancy is explicit
Every tool call must know which customer it belongs to. Never share credentials across tenants. Log user identity without logging secrets.
3. Tools are curated
Ship the workflows that matter. Cap the list. Name tools the way users ask. A small, sharp surface beats a complete API mirror.
4. Errors tell agents how to recover
"Invalid state" is useless. "Subscription is paused — call manageSubscription with action=resume" is useful. Agents retry what you teach them to retry.
5. Rate limits protect you from runaway loops
Agents can hammer endpoints. Put limits at the MCP edge and at your API. Alert when a single user or key spikes.
6. Observability is product-grade
Track per-tool latency, error rate, and volume. Support should answer "what did the agent do?" without opening a database console.
7. Rollback is one switch
Version tools or feature-flag them. You need a way to disable a dangerous tool in minutes, not after a redeploy debate.
8. Support ownership is named
Write down who owns agent mishaps. If the answer is "engineering will watch logs," you don't have a support model.
9. Success has one metric
Pick one for the first 30 days: weekly successful tool calls, tickets down on a workflow, or time saved on a top task. Without a metric, you can't tell if MCP helped.
10. Infrastructure is stateless
Prefer the 2026-07-28 model: no session pinning, any server can handle any request. Sticky sessions and Redis session stores are how "it worked in staging" becomes "it died after deploy."
A launch sequence that works
- Freeze the first workflow set (usually 5–8 tools)
- Prove auth + one happy path + three failure paths in staging
- Pilot with a small user group
- Watch support and error rates for a week
- Expand tools only when the first set is boring in production
Get the full playbook
The free MCP Production Playbook expands this into scale risks, the stateless migration checklist, and a brief you can send every vendor. Leave your email — we'll send the guide.