Running MCP in Production
Getting an MCP server working locally is straightforward. Running it reliably in production is a different challenge. Here's what you need to think about.
Before adding another deployment, decide whether the new tools belong in the same trust boundary or a separate server. The MCP server count guide gives a practical split/consolidate framework.
Hosting
An MCP server is a long-running HTTP service. It needs:
- A server or container to run on
- A public URL that Claude Desktop or your AI client can reach
- TLS (HTTPS) — most MCP clients require secure connections
- Process management to restart on crashes
- Health checks and uptime monitoring
Self-hosting means managing all of this yourself. For teams that want to focus on building rather than infrastructure, hosted MCP services handle it for you.
Keeping in Sync with Your API
Your MCP server is a snapshot of your API at the time you generated it. When your API changes — new endpoints, modified parameters, deprecated routes — your MCP server goes out of date.
Options:
- Manual sync: Regenerate the MCP server whenever your API changes. Error-prone.
- Auto-sync: Point your MCP server at your spec URL and let it check for changes automatically.
MCPForge supports auto-sync on paid plans — it checks your spec URL periodically and updates the tools list when your API changes.
Credential Rotation
API keys expire or get rotated. When that happens, your MCP server needs to be updated with the new credentials.
If credentials are stored on the client (in the Claude Desktop config), you need to update every client that uses them. If they're stored server-side in an encrypted vault, you update them once in one place.
Request Volume and Rate Limits
AI agents can call tools frequently — sometimes in rapid succession as part of a longer reasoning chain. Make sure your MCP server and your upstream API can handle the request volume.
Consider:
- Rate limiting at the MCP layer before requests reach your API; for Claude-specific quota failures, see the Claude AI rate exceeded error guide
- Caching for expensive read operations
- Request quotas per user or plan
Observability
In production, you need to know:
- Is the MCP server running?
- Are tool calls succeeding?
- What's the error rate?
- How long do tool calls take?
- Are any tools being called unexpectedly?
An audit log with latency tracking is the minimum viable observability setup. For more complex deployments, integrate with your existing monitoring stack.
The Simplest Production Setup
For most teams, the simplest production setup is:
- Use a hosted MCP service (no infrastructure to manage)
- Configure permissions before connecting to production APIs
- Store credentials server-side
- Enable audit logging
- Set up approval workflows for destructive operations
This gives you production-grade reliability and security without the operational overhead of running your own infrastructure.
Want to analyze your API security?
Import your OpenAPI spec and generate a Security Report automatically.
Official Sources
- MCP transports specification - official requirements for stdio and Streamable HTTP transports, session handling, headers, and security warnings.
- MCP authorization specification - official authorization model for HTTP-based MCP transports.
- Claude Code MCP reference - practical client behavior for remote HTTP, SSE, stdio, retries, timeouts, and MCP management.
- MCP TypeScript SDK - official server/client SDK and runtime packages.