The MCP Practitioner Course · Lesson 3 of 7
Transports, Hosting, and Remote MCP
> ~3 hours · Streamable HTTP, Cloudflare/Lambda/Vercel, sessions, idempotency, the production gotchas that bite remote servers
By the end of this module you'll have your weather server deployed to Cloudflare Workers, reachable from any host on the internet, with proper session management and structured logging. STDIO is great for local development. For anything you want to share across a team or sell as a service, you need remote MCP.
---
Streamable HTTP is the MCP-blessed network transport. The host POSTs a JSON-RPC request to a single endpoint (`/mcp` by convention). The server responds either with a single JSON response (for short operations) or with a Server-Sent Events stream (for long-running operations that need to push intermediate progress).
Sessions are tracked via a `Mcp-Session-Id` header that the server returns on the first response. The client sends it back on subsequent requests. This is how the server distinguishes one host's session from another's — important for stateful behavior, capability negotiation, and per-session resource limits.
The old "HTTP+SSE" two-endpoint transport is deprecated. If you read older blog posts that describe a separate `/sse` endpoint, that's the deprecated path. For new work in 2026 use Streamable HTTP — single endpoint, conditional streaming, session header.
---
Cloudflare Workers. Best default for SMB-scale MCP servers. Sub-50ms cold start, generous free tier, native KV / Durable Objects for session state, native Hyperdrive for fronting Postgres. Cloudflare ships an "MCP server" template (`workers-mcp`) that handles the Streamable HTTP plumbing for you. Use Workers when you want minimum operational overhead and don't need long-running compute (Workers have a 30-second wall-clock limit per request).
AWS Lambda + API Gateway. Best when the rest of the client's stack is AWS. Lambda gets you up to 15 minutes of compute per invocation, more memory ceiling, native VPC access for talking to internal services. The downside is colder cold starts (~500ms-2s) and more YAML. Use Lambda when you need long-running operations, VPC-internal services, or AWS-native auth (Cognito).
Vercel Functions. Best for solo developers and teams already shipping on Vercel. Excellent DX, fast iteration, native integration with Vercel KV. Function timeout is 5 minutes on Pro tier. Use Vercel when you're building a productized MCP SaaS and you want to ship fast — the platform compresses your dev-to-prod cycle dramatically.
For most consultants serving SMBs, Cloudflare Workers is the default. Fewer moving parts, lower bills.
---
```bash
npm install -g wrangler wrangler login
npm create cloudflare@latest mcp-weather-remote -- --template=workers-mcp cd mcp-weather-remote ```
Copy your `get_weather` tool from the stdio server in Module 2 into the Worker's tool registration. The handler signature is identical — only the transport setup changes.
```bash
wrangler deploy ```
You'll get back a `*.workers.dev` URL. Note it.
Update your `claude_desktop_config.json` to point at the remote URL:
```json { "mcpServers": { "weather-remote": { "url": "https://mcp-weather-remote.your-account.workers.dev/mcp" } } } ```
Restart Claude Desktop and test. Same conversation pattern as before — "what's the weather in Scranton?" — but now the server is reachable from anywhere.
---
Idempotency. Tools that mutate state (create_invoice, send_email) need to be idempotent against retries. Generate an idempotency key, check it before doing the side effect, return the cached result on duplicate calls. The transport can retry on transient failures and you don't want to send the same email three times.
Session affinity. If your server keeps in-memory state per session, you need sticky sessions or external storage. On Workers, use Durable Objects keyed by session ID. On Lambda, DynamoDB or ElastiCache. On Vercel, KV.
Rate limiting. A model under instructions can call your tools fast. Rate limit per session and per tool, not per IP — IPs are unreliable across hosts, sessions are not.
Cold starts. First request after deploy or after a quiet period is slow. Pre-warm via a scheduled job if user-perceived latency matters.
Versioning. Once a host is connected to your server, you can't break the wire shape. Add tools, never remove them. Add optional parameters, never make existing parameters required. Use semver in your server name string.
---
Every log line should include the session ID, tool name, request ID, and duration. Without those four fields, debugging "why was this user's call slow" two months from now is painful. With them, it's 60 seconds.
Use a structured logger (Pino in Node) and send the JSON to your platform's log aggregator (Workers Logpush, CloudWatch, Vercel Logs).
Three metrics that actually matter:
- Tool call success rate, per tool. If a tool is at 70%, something is wrong — schema, description, or upstream integration.
- Tool call latency p50/p95/p99, per tool. The model is in the loop; latency directly affects perceived quality. Anything above 5s at p95 needs attention.
- Error rate, per error category (schema, handler, transport, protocol). Tells you where to invest debugging time.
Three alerts cover most of the surface:
- Error rate above threshold (>5% over 5 minutes)
- Tool call latency p95 above threshold (>10s)
- Specific tool failing repeatedly in 5 minutes (probably an upstream is down)
---
For a billable MCP service, your client expects you to be on call. Build a one-page runbook before you ship. It should answer:
- Where do I look at logs? (URL, login)
- How do I roll back a deploy? (one command)
- How do I tell if it's our problem or an upstream's? (which dashboards to check)
- How do I disable a specific tool without redeploying? (feature flag)
- What's the escalation path if it's the upstream's problem?
Your future self at 11pm on a Tuesday will thank you. Your client's confidence in you grows visibly when you can answer "what happened" inside an hour, every time.
---
For an SMB MCP server handling 5,000 tool calls per day across 50 users, the hosting cost on Cloudflare Workers is essentially zero (free tier). On Lambda it's a few dollars a month. On Vercel Pro it's part of your plan. Hosting is not the cost driver. The cost driver is your time building and maintaining. Pick the platform that minimizes your operational overhead, not the cheapest line item.
---
- Sign up for an OAuth provider with a free dev tier — Auth0 or Clerk are easiest for MCP work
- Skim RFC 8707 (Resource Indicators for OAuth 2.0) — you don't need to read the spec deeply, just see the shape
- Install your preferred OAuth provider's SDK for your stack
Module 4 puts authentication and authorization on top of what you deployed today, plus the security review checklist you'll hand to a CIO during a real engagement.
Previous: Building Your First MCP Server · Next: Security, Governance, and the Things That Will Get You Sued