𝗦𝗼𝗹𝘃𝗶𝗻𝗴 𝗠𝗖𝗣 𝗔𝘂𝘁𝗵𝗲𝗻𝘁𝗶𝗰𝗮𝘁𝗶𝗼𝗻 𝗮𝘁 𝗦𝗰𝗮𝗹𝗲
You built an MCP server. It works on your laptop. Your AI assistant can create Jira tickets and query databases. Everything is great until a teammate asks to use it.
If you want to sell your MCP as a product, you face a new problem. You must support multiple users. Each user needs their own API keys and secure access.
Most developers fail here. They try two bad approaches.
The first is the manual setup. You tell users to clone the repo, install dependencies, and set up local environment keys. This takes hours. Most users will quit before they finish.
The second is the serverless nightmare. You deploy to Cloud Run or Vercel. Because serverless platforms do not store sessions, every request hits a new instance. Your users get stuck in a loop. They authenticate, then the next click asks them to authenticate again. This is not a product. This is a broken prototype.
We solved this at BrainGrid. We moved from a local tool to production-ready infrastructure. Here is how we did it.
- Use a Redis Session Store: Serverless instances die and restart. You cannot store sessions in memory. Use Redis to keep session data alive across all instances.
- Implement Multi-Tier Caching: Check local memory first. If it is not there, check Redis. This prevents expensive JWT validation on every single request.
- Encrypt Sensitive Data: Use AES-256-GCM to encrypt session data before putting it in Redis. This keeps user information safe.
- Use Proper OAuth Patterns: MCP clients expect specific discovery flows. You must format your WWW-Authenticate headers correctly to avoid errors.
- Optimize for Speed: JWT validation adds latency. By caching validated sessions, we reduced response times significantly.
The result is a system that scales from one user to one thousand. It costs very little to run and integrates with providers like WorkOS or Auth0.
Stop building tools for yourself. Start building infrastructure for your customers.