为什么 MCP 服务器难以部署在 Serverless 架构上？
随着大模型生态的发展，MCP（Model Context Protocol，模型上下文协议）成为了连接 AI 助手与外部工具的热门选择。然而，在实际部署中，开发者很快就会遇到一个棘手的架构问题：MCP 服务器默认是有状态的（Stateful）。
1. 单客户端的尴尬限制
在最基础的 HTTP/SSE（Server-Sent Events）实现中，服务器通常会将连接通道（Transport）保存在内存变量中。这意味着，一旦有第二个客户端尝试连接，前一个客户端的连接就会被迫中断。
2. 内存常驻与 Serverless 的冲突
即便我们通过引入 ID 标识来管理多个连接，依然无法解决核心问题——连接状态依然保存在服务器的内存中。
这种“有状态”的特性，直接把 Serverless 部署方案（如 Vercel、AWS Lambda）排除在外。因为 Serverless 函数在请求结束后会随时销毁实例，导致内存中的连接状态丢失。要维持连接，你只能选择 VPS 等需要持续运行的服务器，这增加了运维成本。
3. 如何实现无状态化？
目前最可行的解决方案是将状态外置。我们可以将 Transport 信息存储到像 Redis 这样的键值数据库中。
通过将状态抽离到 Redis，MCP 服务器成功实现了无状态化（Stateless），从而能够自由地部署到 Vercel 等 Serverless 平台上。Vercel 官方开源的
思考
虽然通过 Redis 解决了部署问题，但这无疑增加了系统的复杂度。我们不禁会想：在协议设计之初，是否应该让客户端去承担更多的状态维护，从而避免让服务端背上数据库的包袱？
---
原文链接：https://www.aihero.dev/the-problem-with-mcp-stateful-server
#MCP #Serverless #系统架构 #Redis #AI开发
随着大模型生态的发展，MCP（Model Context Protocol，模型上下文协议）成为了连接 AI 助手与外部工具的热门选择。然而，在实际部署中，开发者很快就会遇到一个棘手的架构问题：MCP 服务器默认是有状态的（Stateful）。
1. 单客户端的尴尬限制
在最基础的 HTTP/SSE（Server-Sent Events）实现中，服务器通常会将连接通道（Transport）保存在内存变量中。这意味着，一旦有第二个客户端尝试连接，前一个客户端的连接就会被迫中断。
2. 内存常驻与 Serverless 的冲突
即便我们通过引入 ID 标识来管理多个连接，依然无法解决核心问题——连接状态依然保存在服务器的内存中。
这种“有状态”的特性，直接把 Serverless 部署方案（如 Vercel、AWS Lambda）排除在外。因为 Serverless 函数在请求结束后会随时销毁实例，导致内存中的连接状态丢失。要维持连接，你只能选择 VPS 等需要持续运行的服务器，这增加了运维成本。
3. 如何实现无状态化？
目前最可行的解决方案是将状态外置。我们可以将 Transport 信息存储到像 Redis 这样的键值数据库中。
通过将状态抽离到 Redis，MCP 服务器成功实现了无状态化（Stateless），从而能够自由地部署到 Vercel 等 Serverless 平台上。Vercel 官方开源的
mcp-on-vercel 项目正是采用了这种架构设计。思考
虽然通过 Redis 解决了部署问题，但这无疑增加了系统的复杂度。我们不禁会想：在协议设计之初，是否应该让客户端去承担更多的状态维护，从而避免让服务端背上数据库的包袱？
---
原文链接：https://www.aihero.dev/the-problem-with-mcp-stateful-server
#MCP #Serverless #系统架构 #Redis #AI开发
www.aihero.dev
The Problem With MCP: Stateful Servers
Discover how to deploy MCP servers statelessly using Redis, enabling compatibility with serverless platforms like Vercel and AWS Lambda.
