MCP（Model Context Protocol）是一套面向大模型的标准化工具协议，旨在以统一、安全、可扩展的方式向模型暴露外部能力（工具/数据/操作），从而让模型在对话中“按需调用”这些能力。
基础概念
什么是 MCP
- 标准化协议：以统一的数据结构和交互流程对外暴露工具能力
- 多传输形态：支持 HTTP（SSE）与 Stdio（本地进程）等通道
- 可发现性：工具（Tools）与资源（Resources）可被模型自动发现与描述
- 可控性：支持权限、速率、上下文隔离等治理手段
核心组件
- MCP Server：实现工具能力的服务端，暴露 Tools/Resources 等能力
- MCP Client：模型侧或中间层的客户端，用于连接 MCP Server 并发出 Tool 调用
- Transport：传输通道，常见为 HTTP(SSE) 与 Stdio
- Schema & Capabilities：能力声明、参数/响应模式、错误约定
深度解析：三种MCP通信协议的技术实现
为了满足不同场景的需求，LangChat Pro现在明确支持三种MCP通信协议，每种协议都有其独特的技术优势和适用场景。1. HTTP协议：兼容SSE与Streamable的智能适配
随着MCP协议的演进，官方SDK在新版本中已经舍弃了旧版本的HTTP SSE协议，转而采用全新的HTTP Streamable协议。技术对比：SSE vs Streamable
HTTP SSE (Server-Sent Events) 是早期MCP实现中使用的协议，它基于HTTP的单向通信机制，服务器可以向客户端推送数据流。然而，SSE协议存在以下局限性：- 仅支持服务器向客户端的单向通信
- 连接建立后无法动态调整参数
- 对于复杂的双向交互支持有限
- 支持真正的双向通信，客户端和服务器可以互相发送消息
- 具有更好的流控制和错误处理机制
- 支持连接复用，提高资源利用率
- 提供更灵活的会话管理能力
执行流程（高层）
在LangChat Pro中使用HTTP协议
LangChat Pro MCP应用市场截图
创建阿里云百炼平台MCP服务（添加HTTP协议请求头Header授权）
对应阿里云开通此联网搜索服务
2. Stdio协议：本地命令的灵活集成
标准输入/输出(stdio)，即通过标准输入/输出进行通信，是MCP协议中最灵活的一种实现方式。支持的命令类型及环境要求
Stdio协议支持多种本地命令执行方式，但需要预先安装相应的运行环境：- uvx：
- 环境要求：需要安装Node.js和npm/yarn
- 用途：用于运行基于npm包的MCP服务
- 示例：
uvx @modelcontextprotocol/server-filesystem
- npx：
- 环境要求：需要安装Node.js
- 用途：用于执行npm包中的命令行工具
- 示例：
npx @modelcontextprotocol/server-gitlab
- python：
- 环境要求：需要安装Python 3.8+和pip
- 用途：用于运行Python编写的MCP服务
- 示例：
python server.py
- docker：
- 环境要求：需要安装Docker引擎
- 用途：用于运行容器化的MCP服务
- 示例：
docker run -i mcp/github
- 其他本地命令：
- 环境要求：根据具体命令而定
- 用途：支持任何可以通过标准输入输出通信的本地程序
在LangChat Pro中使用Stdio协议
LangChat Pro配置截图
LangChat Pro添加授权后查看tools列表
Chat测试截图
3. Docker协议：容器化MCP服务的无缝集成
Docker协议支持以容器镜像形式分发的stdio MCP服务器，用户可以在LangChat Pro平台中轻松配置和使用Docker化的MCP服务。技术优势
Docker协议具有以下技术优势：- 环境隔离：每个MCP服务运行在独立的容器中，避免环境冲突
- 易于部署：通过镜像分发，简化了服务部署流程
- 资源控制：可以精确控制每个服务的资源使用
- 版本管理：通过镜像标签实现服务版本管理
在LangChat Pro中使用Docker协议
实战配置本地Docker Github MCP服务
在LangChat Pro平台配置Docker Github MCP服务
注意，应该使用本机Docker Host地址：unix:///var/run/docker.sock
架构设计：LangChat Pro MCP多协议支持的背后
LangChat Pro之所以能够同时支持HTTP、Stdio和Docker三种协议，背后有着精心设计的架构：1. 动态协议识别机制
系统能够根据配置自动识别并选择合适的传输协议，无需用户手动干预。2. 链接缓存优化
通过智能的链接缓存机制，避免重复建立连接的开销，显著提升响应效率。3. 统一接口抽象
无论底层使用哪种协议，上层应用都通过统一的接口进行访问，保证了系统的一致性和可维护性。在LangChat Pro工作流中使用MCP
MCP 与 Function Call 的区别
二者都让模型“调用外部能力”，但定位、边界与治理能力不同：
对比维度
| 维度 | Function Call | MCP |
|---|---|---|
| 定位 | 模型厂商协议内的函数调用语义 | 跨模型/跨厂商的统一工具协议 |
| 发现机制 | 预先注入函数签名 | Server 端声明的 Tools/Resources 可被发现 |
| 传输通道 | 走模型 API 交互 | HTTP(SSE)/Stdio 等独立通道 |
| 能力治理 | 依赖应用侧自定义 | 标准化能力声明、错误处理与权限边界 |
| 可移植性 | 受模型厂商限制 | 脱离具体模型、易于迁移 |
| 扩展性 | 单应用/单模型为主 | 多服务/多工具可编排 |
选型建议
- 快速接入/轻量函数：Function Call 足够且开发门槛低
- 多模型、多工具、强治理：优先考虑 MCP（标准化、可发现、易迁移）
- 混合方案：在同一 Agent 中同时启用，两者互补
最佳实践
- 安全治理：
- 为 MCP Server 配置细粒度鉴权与速率限制
- 隔离高权限工具与敏感资源
- 可观测性：
- 接入日志与链路追踪，记录 Tool 调用耗时与失败率
- 监控重试/超时策略与告警
- 鲁棒性：
- 对外部服务网络抖动与间歇性失败进行重试与降级
- 采用幂等设计，避免重复执行带来的副作用
- 一致性：
- 对工具的参数模式、错误码与返回结构进行标准化
- 保持工具命名、描述与能力边界的稳定性
常见问题（FAQ）
- Tools 列表超时？
- 检查 MCP Server 可用性与网络连通（SSE 返回头、CORS、代理）
- Stdio 场景检查命令可执行性与环境变量
- 调用成功但模型未采用结果？
- 检查 Agent 的提示词策略与工具优先级
- 确认工具输出是否满足模型期望的结构化格式
- HTTP 与 Stdio 如何选？
- 云端/跨网络优先 HTTP（SSE）
- 本地/低延迟/内网可信优先 Stdio
MCP 与 Function Call 可共存：前者负责“标准化工具层”，后者负责“模型侧调用意图”。在 LangChat Pro 中，推荐将高价值的外部能力沉淀到 MCP，提升跨场景的可复用与可治理性。