Building MCP Servers That Survive Production
Architecture patterns, auth, observability, and the gap between demo MCP tools and systems your team can rely on.
MCP servers are the wiring between AI agents and your business systems. The demo version takes an afternoon. The production version takes auth, rate limiting, error handling, and logging your ops team can actually read at 2 a.m.
Start with the tool boundary
Each MCP tool should do one thing. “Manage the customer” is not a tool. “Look up customer by email” is. Narrow tools give the agent a clearer decision and give you an audit trail that says what actually happened.
The failure mode with wide tools is subtle: the agent picks the right tool and the wrong arguments, and your log line says “manage_customer succeeded.”
Auth is not optional
Demo servers run on a personal token with full access, because that's the fastest way to see it work. Production servers need scoped keys, OAuth, or a service account with least privilege. If your agent can read customer data, the MCP server needs the same access controls you'd put on the API behind it. It is the API, just with a model holding the keys.
Observability from day one
Log every tool invocation: arguments, latency, success or failure, and the session ID that ties calls together. When an agent does something surprising overnight, you need to replay the sequence rather than guess at it. Structured logs matter more here than in ordinary services, because what you're debugging is a decision rather than a stack trace.
The demo-to-production gap
The pattern I keep running into: a team builds an MCP server that works in Claude Desktop, demos it to leadership, then finds out it can't handle two users at once, has no retry logic, and prints credentials into error messages. All of that is ordinary engineering discipline that got skipped because the demo worked.
I run Log Cannon, an open-source log platform, for exactly this. Cloudflare Workers on ingest, ClickHouse for storage, about four million events a day. Agents are chatty. Plan for the volume before you need it.