Session Lifecycle
1. Session Initialization
A session begins when a client sends aninitialize request:
2. Subsequent Requests
After initialization, the client includes the session ID in all requests:3. Session Termination
Sessions can end in several ways:- Client closes: Client sends DELETE request to
/mcp - Idle timeout: Session expires after inactivity (default: 5 minutes)
- Server restart: In-memory sessions are lost (see Storage Providers)
4. Session Not Found (404)
Per the MCP specification, when a client sends a request with an invalid or expired session ID, the server MUST return HTTP 404: Modern MCP clients (like mcp-use client) automatically handle 404 responses by sending a newinitialize request.
Stateful vs Stateless Modes
Stateful Mode (Default for Node.js)
In stateful mode, the server tracks sessions across requests:stateless is not explicitly set, the server automatically detects mode per-request:
- Client sends
Accept: application/json, text/event-stream→ Stateful mode - Client sends
Accept: application/jsononly → Stateless mode
- Session tracking with unique IDs
- Client capability storage (sampling, elicitation, roots)
- SSE streaming with resumability
- Resource subscriptions and notifications
- Idle session cleanup
- Development and debugging
- Single-instance deployments
- Applications requiring persistent client context
- Servers using sampling, elicitation, or notifications
Stateless Mode (Default for Deno)
In stateless mode, each request is independent:- No session tracking
- New server instance per request
- No memory of previous requests
- Horizontal scaling friendly
- Edge functions (Cloudflare Workers, Deno Deploy)
- Serverless deployments (AWS Lambda, Vercel)
- Load-balanced distributed systems
- Simple, stateless APIs
Storage Providers
mcp-use supports multiple storage providers for session management:- In-Memory Storage - Fast, but sessions lost on restart
- File System Storage - Default in development, persists to disk, sessions survive hot reloads
- Redis Storage - Persistent, distributed, supports full MCP features
Session Configuration
Idle Timeout
Configure how long sessions remain active without requests:Deployment Patterns
Single Server
Simple development/single-instance deployment:- ✅ All features work (notifications, sampling, subscriptions)
- ✅ No external dependencies
- ❌ Sessions lost on restart
- ❌ Can’t scale horizontally
Persistent Sessions
Session metadata survives restarts, but still single server:- ✅ Session metadata persists across restarts
- ✅ Notifications work (single server)
- ❌ Can’t distribute across multiple instances
- ⚠️ Active SSE connections still lost on restart
Distributed
Complete horizontal scaling with all MCP features:- ✅ Full horizontal scaling
- ✅ Notifications work across ALL servers
- ✅ Sampling works across instances
- ✅ Resource subscriptions work distributed
- ✅ Load balancer can route requests anywhere
- ✅ Session metadata persists
Stateless
No sessions, no state:- ✅ Infinite horizontal scaling
- ✅ No Redis needed
- ❌ No notifications
- ❌ No sampling
- ❌ No resource subscriptions
- ❌ No SSE streaming