2026 年构建 MCP 服务器：有哪些变化，生产环境需要什么
这是《MCP 开发指南 2026》完整版的精简版，完整版包含可直接运行的 TypeScript 与 Python 服务端示例、完整的 OAuth 流程和安全检查清单。如果你是通过 2025 年的教程学会 Model Context Protocol（模型上下文协议，MCP）的，那么其中一部分内容现在已经不适用了。2026-07-28 版规范让 MCP 变成了无状态协议，这直接改变了服务端的设计、扩容和安全做法。我们在 Feedlio（我们的社交媒体 SaaS 产品）上自建并运行托管 MCP 服务端，它已经收录在官方 MCP Registry、Smithery 和 mcpservers.org 上。下面这些是我们在生产环境里认为最要紧的点。
2026-07-28 版改了什么
没有 initialize 握手了。 每个请求都在 _meta 里携带自己的协议版本和客户端能力。服务端实现 server/discover，用来告知自己支持哪些能力。
没有协议层会话了。 Mcp-Session-Id 头已移除。如果需要在多次调用之间保留状态，就返回一个显式的句柄（handle），由模型把它当作普通工具参数再传回来。
服务端不再向客户端发起请求。 信息收集（Elicitation）改用多轮往返请求（Multi Round-Trip Requests）：服务端返回 resultType: "input_required"，客户端带上输入重试。
已废弃： roots、sampling、logging、旧的 HTTP+SSE 传输方式，以及动态客户端注册（Dynamic Client Registration，改用 Client ID Metadata Documents 代替）。目前废弃窗口最短为十二个月。
工具、资源（resources）和提示（prompts）的用法与以前一致，所以大部分工具代码可以直接沿用。最大的好处是：负载均衡后面的任意一个实例都能处理任意请求。
传输方式怎么选
stdio 适合本地工具（文件、本地数据库、命令行工具）。服务端以用户的权限运行，从环境变量里读取凭据。
Streamable HTTP 适合任何共享服务或 SaaS。只有一个端点，每条消息发一次 POST，每个 POST 都带上 MCP-Protocol-Version、Mcp-Method 头，工具调用还要带 Mcp-Name 头。这样网关不用解析 JSON 就能做路由和限流。记得校验 Origin 头，挡住 DNS 重绑定攻击。
HTTP+SSE 已废弃，不要在新项目里用了。
工具按意图设计，别按接口设计
最常见的错误，是把 REST API 一个接口一个接口地照搬过来。
一个模型如果需要串联 get_customer、get_customer_accounts 和 get_account_invoices，出错的概率和消耗的 token 都会高于直接调用 find_overdue_invoices(customer, min_days_overdue)。每个用户意图对应一个工具，工具之间不重叠。读写分离，并用 readOnlyHint / destructiveHint 标记（这些是给宿主的提示，不是安全控制）。工具描述就是提示词：说明何时使用该工具，给出格式和单位（“ISO 8601 UTC，例如 2026-11-02T09:00:00Z”），并说明 ID 的来源（“accountId 来自 list_social_accounts”）。枚举和限制写在 schema 里，不要写在描述文字中。
错误信息要让模型能采取行动
MCP 有两条错误通道。协议错误（格式错误的请求、未知工具）模型很难从中恢复。工具执行错误则是正常结果，带上 isError: true，客户端会把它传回给模型，让模型自行纠正。所以错误信息要面向模型来写：“404”什么信息都没给。“没有 id 为 p_99 的帖子。调用 list_posts 获取有效 ID。”这样模型就知道下一步该做什么。永远不要返回堆栈信息、主机名或密钥：你返回的任何内容都可能出现在聊天记录里。
写操作要幂等
模型会重试，而且在无状态的 Streamable HTTP 传输下，流中断会丢失在途请求，客户端会重新发起。没有幂等机制的话，重试就会产生重复数据。接收一个幂等键，把结果和键一起存储，当键重复时返回原始结果：
const postId = `post_${idempotencyKey}`;
if (!posts.has(postId))
posts.set(postId, { text, publishAt, status: 'scheduled' });
return {
content: [{ type: 'text', text: JSON.stringify({ postId, status: 'scheduled' }) }]
};
远程服务器的授权
你的 MCP 服务器是一个 OAuth 2.1 资源服务器。客户端通过 PKCE 和 resource 参数从你的授权服务器（通常是你现有的身份提供商）获取 token，获取前会先通过 /.well-known/oauth-protected-resource 上的 Protected Resource Metadata 发现授权服务器。两条规则可以避免大多数严重错误：
- 验证 audience。只接受签发给你的服务器的 token。
- 永远不要透传 token。
安全：必须提前规划的部分
令牌透传。服务器调用下游 API 时，用的是自己的凭证。令牌透传（token passthrough）是被明令禁止的：它既会破坏审计链路，也会带来「混乱代理人」（confused deputy）风险——也就是服务被诱导，用超出用户本意的权限去操作。权限范围要按「用户会同意什么」来设计，比如 posts:read 绝不能具备发布能力；需要提权时，返回 403 insufficient_scope，而不是图省事用通配符权限。
工具结果中的提示注入（prompt injection）。一封客户邮件、一条社交评论，都可能写着「忽略前面的指令」。所以只返回必要的字段，读操作的结果永远不能解锁写操作，凡是会产生副作用的动作都必须经过审批。
工具投毒（tool poisoning）。来自不可信服务器的描述同样不可信。做法是：服务器走白名单、锁定版本、描述一有变更就告警。
最小权限。权限范围给到最小，工具列表按用户区分，租户隔离放在数据层实现，而不是写成给模型的指令。
SSRF（服务端请求伪造）。如果某个工具要抓取模型给出的 URL，必须强制 HTTPS、屏蔽内网地址段，并限制文件大小和请求时长。
运行 Feedlio MCP 服务器得到的三个教训
平台要求必须写进 schema。 TikTok 需要隐私设置和音乐使用确认，YouTube 需要标题和分类。schema 里没有对应字段，模型就发不出去——它再强也没用。
媒体以公开 URL 的形式传入。 由 add_media_from_url 在服务端抓取文件。把二进制文件塞进工具参数，既消耗大量上下文，又很脆弱。
内容上线前必须有人确认。 助手负责准备好帖子，由人确认之后才进入排期。能放在产品里做的审批就放在产品里，这样无论用户接的是哪个客户端，行为都一致。
测试方法
用 MCP Inspector（需要 Node 22.19 及以上）测试：
npx @modelcontextprotocol/inspector --server-url http://127.0.0.1:3000/mcp --transport http
然后用用户真正在用的那些助手再测一遍，并补上对抗性测试：在返回的数据里埋入指令，看它会不会被带偏。
阅读完整指南
完整指南涵盖：整体架构、一套完整的 TypeScript（v2 SDK）服务器和一套 Python 服务器、OAuth 流程的逐步讲解、一张对照 OWASP LLM Top 10 的威胁与控制措施表、运维实践，以及真实的时间估算——从 1–2 周的原型，到 8–14 周面向公众的 SaaS 服务器。
👉 阅读完整的《2026 年 MCP 开发指南》
iTech Soft Solutions 提供 AI 智能体、LLM 集成与 MCP 服务器开发服务：AI 开发服务。
本文是完整版《2026 年 MCP 开发指南》的精简版，完整指南包含可直接运行的 TypeScript 和 Python 服务器示例、完整的 OAuth 流程以及一份安全检查清单。如果你是从 2025 年的教程里学会模型上下文协议（Model Context Protocol，MCP）的，那么其中部分内容已经不再适用。2026-07-28 规范让 MCP 变成了无状态协议，这会改变你设计、扩展和保护服务器的方式。我们为自家社交媒体 SaaS 产品 Feedlio 构建并运营托管 MCP 服务器，该服务器已收录于官方 MCP Registry 和 Smithery。