随着大型语言模型（LLM）应用的普及，模型与工具／服务的连接方式变得越来越关键。本文聚焦于开放标准 Model Context Protocol（MCP）的四大关键维度：  

1. 传输方式：Stdio、Streamable HTTP／HTTP + SSE  

2. 核心调用方法：initialize、tools/list、tool_call  

3. Server 端职责：工具暴露、传输支持、会话管理、安全治理  

4. Client（适配层）职责：transport 管理、能力发现、调用封装、上下文管理  

如果你正在或准备为系统构建 MCP 的 Server 或 Client 适配层，希望本文能给你一个清晰的技术视角与实践建议。

1. MCP 的传输方式：Stdio、Streamable HTTP、SSE

虽然 MCP 的重点在于“模型调用工具／资源”，但底层通信机制（transport）对系统的部署、性能、可扩展性与稳定性有极大影响。规范中明确指出：MCP 使用 JSON-RPC 消息格式，并支持多种传输机制。

常见传输方式对比

方式	描述	优点	限制
Stdio	Client 与 Server 在同一主机／进程，通过 stdin/stdout 通信	部署简单、延迟低、便于本地工具集成	不适合分布式、远程服务或多客户端场景
HTTP + SSE（Server-Sent Events）	远程场景中：Client 与 Server 通过 HTTP 建立，Server 向 Client 推送事件流	支持远程部署、推送能力、跨语言／跨平台	单向流（Server→Client）、需要长期连接、扩展受限
Streamable HTTP	MCP 规范新版推荐：通过单一 HTTP 端点（POST/GET）支持普通响应或选择流式响应	支持标准 HTTP、可选流、支持无状态或状态化部署、扩展性强	需要新协议支持／实现相对较新

细分说明：SSE 与 Streamable HTTP

SSE（HTTP + SSE）

工作方式：Client 向 Server 打开一个 `text/event-stream` 类型的长连接（SSE 流）用于接收消息，Client 如果要发送请求则通过另一个 HTTP POST 接口。

• 优点：实现较早、推送能力好、简单支持 Server→Client 的实时事件。
•  缺点：
  • 连接双端（一个用于 SSE 读流、一个用于 POST 发送），架构复杂。
  • 长连接资源占用高、在高并发场景扩展困难。
  • 信道多为单向（Server→Client），客户端发起还需另一路径。

Streamable HTTP

工作方式：Client 与 Server 使用单个 HTTP 端点，支持普通 HTTP 请求-响应，也可升级为流式响应（Server 可在同一连接中推送多条消息或事件）。

• 优点：
  • 架构简化：只用一个端点，客户端／服务端管理更轻松。
  • 支持无状态服务器部署、更易于扩展、兼容现有 HTTP 基础设施。
  • 客户端实现复杂度低、维护成本小。

实践建议

1.  初期如工具部署与模型／Host 在同机、调试周期短，可优先选用 Stdio。
2. 市场中大多数厂商当前（截止至2025年11月）公开的 MCP 服务使用的传输方式为SSE，使用时注意适配。
3. 自己实现 MCP 服务时，强烈建议使用Streamable HTTP。既符合官方推荐，集成方式也更简单。

2. MCP 的核心方法

在 MCP 的典型流程中，Client 与 Server 的交互可视为三步：初始化 → 能力发现 → 工具调用。下面逐一说明。

a). 初始化（initialize）

在 Client 与 Server 建立 transport 链接后，Client 通常发起 `initialize` 请求，用于协商协议版本、会话元数据、认证信息等。 

示例伪码：

  session = McpClient(server_endpoint)
  init_response = await session.initialize({
      "client_name": "HostApp",
      "protocol_version": "1.0",
      "supported_transports": ["stdio", "http"]
  })

在此阶段，通过initialize方法，从responseHeader中提取到`mcp-session-id`，后面的所有调用需要把此sessionId置于requestHeader中，确保整个流程处于同一session中。

b). 工具/资源发现（tools/list）

初始化完成后，Client 向 Server 请求其支持的工具／资源／提示清单。Server 返回 metadata，包括名称、参数 schema、返回类型、调用约束等。

示例伪码：

  capabilities = await session.list_tools()
  for tool in capabilities["tools"]:
      register_tool(tool["name"], tool["parameters"], tool["return_type"])

此部分内容将传给大模型，使模型知道工具的使用方法，便于后续模型选择MCP工具并调用。

c). 工具调用（tools/call）

当模型／Host 决定使用某工具时，Client 发起调用请求（如 `call_tool(toolName, args)`），携带工具名称、参数、session ID 等。Server 执行后回应结果。

示例伪码：

result = await session.call_tool("weather_query", {"location": "Singapore"})

MCP返回内容将自动回传给大模型，大模型会根据返回决定后续操作。整个流程处于同一次大模型问答交互。

d). 扩展机制：资源调用、提示模板、异常／取消处理

MCP 除了工具调用，还支持 Resources（只读访问、无副作用）及 Prompts（预定义交互模板）。

3. MCP Server 端需要做的事情

Server 端在 MCP 架构中是负责工具／资源暴露、传输支持、会话管理、安全治理的关键组件。下面说明 Server 端需要做的主要工作，以及在项目中可参考的实践内容。

职责清单:

• 能力发布 (Capability Exposure)：Server 启动后应向 Client／Host 公布其支持的工具／资源／提示清单。
• 传输层实现 (Transport Support)：Server 需支持一种或多种 transport（例如 Stdio、HTTP+SSE 等），并遵守 MCP 的消息格式（通常基于 JSON-RPC）。
• 工具／资源实现 (Tools & Resources)：Server 将外部系统（例如 API、数据库、脚本、文件系统）包装为 MCP “tools” 或 “resources”，定义名称、参数、返回类型、调用逻辑。
• 会话／状态管理 (Session & Context)：Server 应追踪 session ID、每次调用历史、工具调用次数、并可能支持限流／并发控制。
• 安全与权限控制 (Auth & Governance)：Server 应验证 Client 身份、校验调用权限（例如 Token、scope）、记录审计日志、防止滥用。
• 错误／取消机制 (Error Handling / Cancellation)：Server 应支持调用取消、超时、错误返回、资源不可用等情况的处理。
• 版本兼容／协议演进 (Versioning / Back-compatibility)：由于 MCP 仍在演进，Server 需支持协议版本协商、transport 扩展、新工具注册、旧版本兼容。

在项目中的实践

构造一个最简可用版本（MVP版）的MCP只需要4步：

1. 启动一个长期运行服务
   在你选择的语言／框架（如 Python、Node.js、Java）中，启动一个一直在监听连接或请求的服务。这个服务应准备好接收来自客户端（MCP Client）的调用请求。

2. 实现业务逻辑处理函数（handler）
   在服务中定义一个或多个函数（handler 方法），它们实现你希望暴露为 MCP 工具（tool）所做的具体业务逻辑。例如 “查询天气”“读取数据库”“执行某操作” 等。

3. 定义 Tool 的元数据描述对象
   为每个工具构造一个元数据对象／结构，描述如下内容：

   • 工具的名称（tool name）

   • 输入参数：参数名、类型、是否必需、描述

   • 返回值类型或结构

   • 工具用途的简要描述
     这个描述将被 MCP Client／Host 用于能力发现（tool_list）和调用封装。

4. 将工具注册／暴露为 MCP 服务接口
   在服务启动时，将上述工具通过 MCP 协议注册／暴露出来，使客户端在连接服务后能通过 “能力发现（tool_list）” 查询到工具，并能够调用（tool_call）这些工具。换言之，你的服务类似 HTTP/API 服务那样，将 MCP 工具以标准接口方式上线。

4. MCP Client（适配层）需要做的事情

Client 适配层连接 Host（模型环境）与 MCP Server（工具环境），负责 transport 接入、能力发现、调用封装、上下文管理、错误处理等。以下为 Client 应做的关键工作及实践建议。

职责清单：

• Transport 初始化与管理：根据配置（如 “stdio”、“streamable http”、“sse”）建立 Client-Server 连接，管理连接生命周期、断线重连、心跳检测、日志记录。
• 初始化 (initialize) 与能力发现 (tool_list)：在 session 开始时发起 `initialize()`，然后获取工具／资源／提示清单，并将其转换为 Host／模型可用格式。
• 工具调用封装 (tool_call)：为 Host／模型提供统一接口，例如 `call_tool(toolName, args)`；内部处理构建请求、发送、超时／重试、接收响应、结果转换。
• 上下文／会话管理 (Session & Context)：维护 `session_id`、调用链记录、上下文状态（当模型连续调用多个工具时尤为重要）。
• 错误／超时／取消机制 (Error Handling / Retry / Cancel)：处理 Server 不响应、网络断开、工具失败、调用链中断等情况。
• 能力适配与模型对接 (Capability Mapping)：将 Server 返回的工具 metadata（名称、参数、返回类型、描述）映射为模型调用所用 schema（例如 function-call 风格、UI 工具选项）或 Host 可使用的接口。
• 安全与审计 (Auth / Logging)：Client 可负责 token 注入、为工具调用提供客户端过滤（例如生产模式限制某些工具调用）、记录客户端日志。
• 扩展性设计 (Extensibility)：预留接口以支持新增 transport、多 Server 管理、协议版本切换、工具模块扩展。

在项目中的实践

实际上各家模型的SDK几乎都实现了上述职责。我们只需按照SDK的配置格式 将MCP的host及鉴权使用的token/api-key按要求配置即可完成。

但各家模型SDK使用的object以及命名不同，因此我们通常会添加一个适配层让多大模型的项目在MCP上能统一配置方式。

额外一提：部分大语言模型如Google Gemini Pro 2.5目前暂不支持MCP，在适配层可通过调用MCP的“tool/list”方法读取到所有的tool定义后，将他们转换为function call供模型使用。