01
Streamable HTTP传输模式
在新版本中，MCP引入了新的Streamable HTTP远程传输机制来代替之前的HTTP+SSE的远程传输模式（stdio的本地模式不变）。
1.背景与动机
当前MCP采用的HTTP+SSE的远程传输模式总结为（图中未涵盖服务端发送请求如Sampling的场景）：
客户端首先发送HTTP Get请求到服务端/sse端点
服务端进行响应，建立SSE长连接，并返回后续请求的URI（默认/messages）
客户端使用此URI与服务端交互，发送请求
服务端则通过SSE连接发送响应消息或通知信息给客户端
这种方式存在问题有：
需要维护两个独立的连接端点
有较高的连接可靠性要求。一旦SSE连接断开，客户端无法自动恢复，需要重新建立新连接，导致上下文丢失
服务端必须为每个客户端维持一个高可用长连接，对可用性和伸缩性提出挑战
强制所有服务端向客户端的消息都经由SSE单向推送，缺乏灵活性。
2.变更说明
最新规范的Streamable HTTP传输机制总结为（图中未涵盖服务端发送请求如Sampling的场景）：
这里的主要变化包括：
服务端只需一个统一的HTTP 端点（如/messages）用于通信
客户端可以完全无状态的方式与服务端进行交互，即Restful HTTP Post方式
必要时客户端也可以在单次请求中获得SSE方式响应，比如：一个需要进度通知的长时间运行的任务，可以借助SSE不断推送进度
客户端也可以通过HTTP Get请求来打开一个长连接的SSE流，这种方式与当前的HTTP+SSE模式类似；但这个SSE长连接主要用于后续的服务端向客户端推送通知或发起服务端的请求（比如Sampling请求）
增强的Session管理。服务端会在初始化时返回Mcp-Session-Id，后续客户端在每次请求中需要携带该MCP-Session-Id。这个Mcp-Session-Id作用是：
用来关联一次会话的多次交互。
服务端可以用Session-Id来终止会话，要求客户端开启新会话
客户端也可以用HTTP Delete请求来终止会话
StreamableHTTP在旧方案的基础上，提升了传输层的灵活性与健壮性：
允许无状态的服务端存在，不依赖长连接。有更好的部署灵活性与扩展能力
对服务端中间件的兼容性更好，只需要支持HTTP即可，无需做SSE处理
允许根据自身需要开启SSE响应或长连接，保留了现有规范SSE模式的优势
3.影响与应用
新的应用客户端必须设置 Accept 头支持两种返回类型（application/json 和 text/event-stream），以同时支持服务器返回 JSON 或 SSE 流。如：
POST /mcp HTTP/1.1Host: mcp.example.comAccept: application/json, text/event-streamContent-Type: application/json{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}如果不要求流式输出，则服务端返回一个 JSON 响应；如果要求流式模式，则响应头为 Content-Type: text/event-stream，并以 SSE 事件方式发送一个或多个 JSON-RPC 消息。
客户端通过以下方式开启SSE的长连接，用来接收服务端的异步的消息推送：
GET /mcp HTTP/1.1Host: mcp.example.comAccept: text/event-stream
02
MCP 2025-03-26 规范引入了基于 OAuth 2.1 的授权框架，为基于 HTTP 交互的客户端与服务端提供了标准化的安全机制。当然，这种机制仅适用于远程模式，对于通过标准输入输出（stdio）传输的交互则无需考虑此规范。
如果你对OAuth流程毫无概念，参考文后方法获得一个极简的例子代码。
1.背景与动机
目前的大多数 MCP 应用采用基于 stdio 的本地传输模式，部署几乎是一对一的，安全边界清晰。但在基于 SSE 传输模式的远程 MCP 服务端场景中，尤其是随着第三方 MCP 共享服务的迅速增长，缺少统一的授权机制导致无法安全地管理对服务端功能的访问权限。引入 OAuth 2.1 可以使资源所有者通过标准的授权流程安全地控制访问权限。
例如， 在企业环境中，一个MCP服务端可能连接内部数据库或敏感API，通过OAuth2.1授权，可以确保只有经过用户同意的MCP客户端才能访问这些资源。这使构建安全的AI 智能体成为可能：用户可随时撤销授权令牌，终止其对数据的访问。此外，由于使用标准OAuth流程，企业开发者可以方便地将现有企业的身份认证与授权服务整合到MCP服务器中。
2.变更说明
若选择遵循MCP新规范中的OAuth2.1授权流程，MCP客户端在向服务端的受限资源发起请求之前，必须先通过浏览器引导用户授权访问MCP服务端，完成OAuth授权流程以获取访问的安全令牌（Access Token）。随后，客户端需携带此令牌访问MCP服务端；若服务器返回未授权响应，并提示客户端启动授权流程。
此外，规范建议MCP服务端支持OAuth动态客户端注册和授权服务器元数据发现，以便客户端能够自动获取服务器的授权端点信息。
整体授权流程描述如下图：
【角色定义】
浏览器：用户所使用的网络浏览器，用于实现交互式授权。
MCP客户端（例如智能体、ChatBot）：需要调用MCP 服务端功能的应用程序。
MCP服务端（同时担任OAuth 授权服务器的角色）：既是受保护资源的服务器端，也是OAuth认证授权的服务器。
【流程描述】
(1)客户端发现授权服务器的元数据
客户端访问标准路径（一般为.well-known/oauth-authorization-server），希望自动发现服务器的授权端点、令牌端点等元数据。这不是一种必须实现的服务端机制，所以有两种可能的返回结果：
[Server Supports Discovery]：服务器返回标准的元数据信息（通常是一个 JSON，里面有 authorization_endpoint、token_endpoint等地址）。
[No Discovery]：如果服务器返回404，客户端按默认配置继续，相当于 MCP 服务端直接告诉客户端：“我没有实现发现机制，请自己配置好端点地址”。
(2)动态客户端注册（可选）
在调用授权服务的过程中，需提供一个client_id（比如调用Google的OAuth授权服务，需要在后台创建获得client_id）。若MCP服务端支持动态客户端注册，客户端无需预先注册，即可在运行时直接向MCP服务端进行注册，从而获得一组新的client_id、client_secret以及其他授权配置信息。
如果您的MCP服务可能拥有众多客户端应用，建议实现动态客户端注册机制。
(3)客户端准备授权请求（包含 PKCE 参数）
PKCE（Proof Key for Code Exchange）是 OAuth 2.1 强制要求的保护机制，旨在防范“授权码被拦截盗用”的攻击。它涉及一组PKCE参数，包括：
code_verifier（一串随机字符串）
code_challenge（基于code_verifier进行编码生成）
在授权过程中，客户端会携带code_challenge以获取授权码；在使用授权码交换安全令牌时，客户端再提供code_verifier。授权服务器将验证code_verifier与先前的code_challenge是否匹配，只有在匹配的情况下，才会发放令牌，从而有效防止授权码被劫持。
(4)启动浏览器，进行用户授权
客户端打开系统浏览器，跳转到 MCP 服务端的授权地址。并带上这些信息：client_id、redirect_uri、response_type=code、scope、code_challenge等。此时浏览器界面显示让用户确认授权，比如“授权 MCP xxx访问你的MCP服务资源”。
(5)用户同意授权
用户在浏览器上点击 “允许授权”（也可能需要额外的输入验证信息）。
(6)服务端验证并生成授权码
此时服务端验证用户身份与授权请求是否合法，如果用户同意授权，就生成一个临时的授权码（code）。
(7)授权码回调到客户端
MCP 服务端通过浏览器重定向到MCP客户端前面提供的重定向URI（redirect_uri），并在参数中附带授权码 code=xxx。
(8)客户端接收回调
客户端捕获这个回调请求，拿到授权码；并使用授权码访问MCP服务端的令牌颁发的端点，换取访问令牌（Access Token），一般需要带上code，code_verifier，client_id等信息。MCP服务端验证授权码合法，且code_verifier验证通过，就会下发安全令牌。
(9)客户端使用安全令牌调用 MCP 服务端功能
客户端拿到安全令牌后，正式调用 MCP 服务端的受保护功能。令牌在HTTP的请求头中携带即可：
POST /mcpAuthorization: Bearer {access_token}Content-Type: application/json接着就可以发起 MCP 调用，比如 tool/call、resource/fetch 等。
3.影响和应用
老版本MCP客户端/服务器如果不实现授权，默认仍可在不需要认证的环境下正常通信，因为授权是可选的。
规范明确仅在HTTP传输下推荐OAuth授权，本地stdio模式下的行为不被影响。
不支持OAuth的旧客户端仍可连接不要求认证的新版服务器。然而，如果新版服务器开启了授权要求，此时需要客户端升级以实现OAuth流程。
总体而言，OAuth授权框架的加入对原有功能不造成破坏，但要求在需要安全接入的场景下，客户端和服务器都进行相应升级来配合这一流程。
