A hello-world MCP server is easy to ship. A production MCP server that survives contact with real AI agents, real traffic, and real attackers requires an entirely different checklist. This final article in our MCP series covers everything you need to productionise an MCP server: Streamable HTTP instead of stdio, OAuth-based authentication, a three-layer test strategy, Docker packaging with uv, and the health checks your DevOps team will demand before signing off.
This article assumes you have completed the first two articles in the series. If you are jumping in cold, read Build Your First MCP Server with Python SDK first, then Connect FastAPI to MCP to understand the integration patterns before tackling production hardening.
Page Contents
Why stdio Is Not Production-Grade
All three articles in this series have used server.run(transport="stdio") during development. Stdio is ideal for local development because it requires zero configuration — the client spawns the server process and communicates over pipes. But stdio has three fundamental limitations that make it unsuitable for production deployments.
First, network isolation. Stdio works only when the client and server run on the same machine. The moment you want an AI agent running on a laptop to call an MCP server hosted on a cloud VM, stdio breaks down. You would need SSH tunnelling or a wrapper to bridge the gap, which adds complexity and new failure points.
Second, no standard authentication mechanism. Stdio has no concept of HTTP headers, bearer tokens, or OAuth flows. Any credentials passed over stdio are unstructured and invisible to standard security tooling. Network transport layers, by contrast, can carry standard authentication headers that infrastructure — load balancers, API gateways, WAFs — can inspect and enforce.
Third, no horizontal scaling path. A stdio MCP server is a single process with a single connection. You cannot put it behind a load balancer or run multiple instances behind a service mesh without rebuilding the transport from scratch.
For all three reasons, the MCP specification community deprecated Server-Sent Events (SSE) and converged on Streamable HTTP as the production transport. Streamable HTTP provides full bidirectional streaming over standard HTTP/1.1 or HTTP/2, carries standard auth headers, works through proxies and load balancers, and supports session affinity for stateful sessions.
Switching to Streamable HTTP
The MCP Python SDK provides run_streamable_http_async as the production-grade entry point. Migrating from stdio to Streamable HTTP requires changing the transport configuration and, critically, binding the server to a network address rather than stdio.
# weather_server_http.py — production MCP server using Streamable HTTP
import asyncio
from mcp import Server
from mcp.types import Tool, TextContent
from mcp.server import run_streamable_http_async
async def main():
await run_streamable_http_async(
server,
host="0.0.0.0", # Bind to all interfaces in production
port=8000,
debug=False,
)
if __name__ == "__main__":
asyncio.run(main())Key changes from the stdio version: run_streamable_http_async replaces server.run(transport="stdio"). You specify an explicit host and port. In production, bind to 0.0.0.0 so the container or VM can receive connections from the network. Starting with version 1.1 of the MCP Python SDK, Streamable HTTP servers can also emit MCP-Session-Id headers to enable session affinity in load-balanced deployments.
Authentication
An unauthenticated MCP endpoint is a direct execution path into your backend. Any AI agent that can reach the endpoint can call every tool it exposes. Authentication is not optional for production deployments. Streamable HTTP solves this cleanly because it runs over standard HTTP — you can use any HTTP authentication mechanism.
The three most common patterns for MCP are: Static API key (bearer token) for internal services; OAuth 2.0 token exchange when your MCP server acts as a proxy to other services; and mTLS (mutual TLS) for high-security environments requiring certificate-based mutual authentication.
# auth_guard.py — FastAPI middleware enforcing bearer token auth on an MCP HTTP server
import os
from fastapi import FastAPI, HTTPException, Security, Depends
from fastapi.security import HTTPBearer
from mcp.server import Server
from mcp.types import Tool, TextContent
from mcp.server import run_streamable_http_async
security = HTTPBearer()
EXPECTED_TOKEN = os.environ.get("MCP_API_KEY", "")
async def verify_token(token: str = Security(security)):
if not EXPECTED_TOKEN:
raise HTTPException(status_code=500, detail="Server misconfigured: no API key set")
if token != EXPECTED_TOKEN:
raise HTTPException(status_code=401, detail="Invalid or missing API key")
return token
app = FastAPI(title="Weather MCP (authenticated)")
mcp_server = Server("com.pyblog.weather-server")
@app.get("/health")
async def health():
return {"status": "healthy"}
async def main():
await run_streamable_http_async(
mcp_server,
app=app,
host="0.0.0.0",
port=8000,
)Always bind Streamable HTTP servers to localhost during local development and use a reverse proxy (Nginx, Caddy, or a cloud load balancer) to terminate TLS and add authentication at the edge. Implementations must also validate the Origin header to prevent DNS rebinding attacks.
Testing an MCP Server
Testing MCP servers requires a three-layer strategy. Layer 1 — Unit tests verify that individual tool functions return correct output with mocked external dependencies. Use pytest. Layer 2 — Integration tests verify the MCP server correctly processes JSON-RPC requests end-to-end over HTTP. Start the server in a subprocess and send actual HTTP requests. Layer 3 — E2E tests verify the full flow from an AI agent’s perspective using the MCP SDK’s ClientSession.
# tests/test_integration.py — integration tests for the weather MCP server
import pytest, httpx, subprocess, time, os
MCP_SERVER_URL = "http://127.0.0.1:8899/mcp"
@pytest.fixture(scope="module")
def mcp_server():
env = os.environ.copy()
env["MCP_API_KEY"] = "test-secret-key"
proc = subprocess.Popen(["python", "weather_server_http.py"], env=env)
time.sleep(2)
yield proc
proc.terminate()
proc.wait(timeout=5)
@pytest.mark.asyncio
async def test_list_tools_returns_weather_tool(mcp_server):
async with httpx.AsyncClient(headers={"Authorization": "Bearer test-secret-key"}) as client:
response = await client.post(MCP_SERVER_URL, json={
"jsonrpc": "2.0", "id": 1, "method": "tools/list", "params": {},
})
assert response.status_code == 200
tools = response.json()["result"]["tools"]
assert any(t["name"] == "get_weather" for t in tools)
@pytest.mark.asyncio
async def test_reject_invalid_token(mcp_server):
async with httpx.AsyncClient(headers={"Authorization": "Bearer wrong-token"}) as client:
response = await client.post(MCP_SERVER_URL, json={
"jsonrpc": "2.0", "id": 2, "method": "tools/list", "params": {},
})
assert response.status_code == 401Docker Deployment with uv
Docker guarantees that the MCP server runs identically in development, CI, and production. The three critical decisions for a production MCP Dockerfile: choosing a minimal base image, installing uv for fast dependency installation, and running as a non-root user for security.
# Dockerfile — production MCP server using uv
FROM python:3.12-slim
COPY --from=ghcr.io/astral-sh/uv:latest /uv /usr/local/bin/uv
WORKDIR /app
COPY pyproject.toml uv.lock ./
RUN uv pip install --system --no-cache -e .
COPY weather_server_http.py ./
RUN adduser --disabled-password --gecos "" mcpuser
USER mcpuser
HEALTHCHECK --interval=30s --timeout=5s --start-period=10s --retries=3
CMD python -c "import httpx; httpx.get('http://localhost:8000/health').raise_for_status()"
EXPOSE 8000
CMD ["python", "weather_server_http.py"]Security Checklist
- Streamable HTTP with TLS termination at the load balancer
- Bearer token or OAuth token on every MCP endpoint — no exceptions
- Origin header validation to prevent DNS rebinding attacks
- Tool allowlisting — never expose internal admin operations as MCP tools
- Rate limiting on the MCP endpoint
- Non-root user inside the container
- Secrets injected via environment variables — never baked into images
- Docker HEALTHCHECK and Kubernetes liveness/readiness probes
- Structured JSON logs with request correlation IDs
- Error tracking with alerts on error rate spikes
Summary
The three articles in this series give you a complete foundation for building, integrating, and deploying MCP servers with Python. Keep an eye on the official MCP specification for new transport options and updated security recommendations as the protocol matures.
- MCP Python SDK: github.com/modelcontextprotocol/python-sdk
- Auth0 — Why MCP moved from SSE to Streamable HTTP: auth0.com/blog/mcp-streamable-http/
- Stack Overflow Blog — MCP authentication: stackoverflow.blog
- Snyk — 5 Best Practices for Building MCP Servers: snyk.io
