Chrysalid1. MCP协议概述与核心价值
MCP（Model Context Protocol）是一种开放的技术协议，旨在为大型语言模型（LLM）与外部工具和服务之间的交互提供标准化解决方案。这个协议的核心价值在于解决了AI工具调用领域的两个关键痛点：接口碎片化和开发低效问题。
在MCP出现之前，每个LLM使用不同的指令格式，每个工具API也有独特的数据结构，开发者需要为每个组合编写定制化连接代码。这种"一对一翻译"模式成本高昂且难以扩展，就像为每个外国客户雇用专属翻译。模型与工具深度绑定，无法构建统一生态系统，大大增加了迁移成本。
MCP采用了一种通用语言格式（JSON-RPC），使得开发者一次学习就能与所有支持这种协议的工具进行交流。这相当于在AI世界建立了一个通用翻译器，不管使用什么LLM，通过MCP就能统一调用各类工具和数据资源。
1.1 MCP的核心特性
MCP协议具有以下显著特点：
- 协议标准化：统一采用JSON-RPC 2.0消息格式，任何兼容MCP的主机（如Claude Desktop、Cursor等）都能即插即用
- 本地优先设计：敏感数据可以保留在本地，API密钥不再需要暴露给模型提供商
- 动态扩展能力：新增工具只需启动一个新的MCP Server，无需修改模型或主程序
- 安全隔离机制：采用双层授权+最小权限+端到端加密的安全策略
1.2 MCP与相关技术的对比
MCP与传统的Function Calling和Tool调用方式有着本质区别：
| 维度 | MCP | Function Calling | Tool |
|---|---|---|---|
| 本质 | 开放协议/标准 | 模型自身能力 | 泛指可被调用的外部函数 |
| 架构 | Client-Server（主机-服务器） | 模型直接生成调用指令 | 无统一架构 |
| 耦合度 | 低：一次开发，多模型通用 | 高：需针对模型微调 | 无标准，各自为政 |
| 扩展方式 | 启动新MCP Server即可 | 需改prompt、重训或改代码 | 每换环境重写 |
| 安全模型 | 本地运行、双层授权 | 密钥/数据通常送云端 | 取决于实现 |
| 类比 | USB-C通用接口 | 各品牌私有充电线 | 单个转接头 |
Function Call是大型语言模型与外部工具或API交互的核心机制，它是大模型的基础能力，用于识别何时需要工具以及可能需要什么类型的工具。而MCP则是工具分类的标准化容器。因此MCP不是要取代Function Call，而是要在Function Call基础上，联合Agent一起去完成复杂任务。
如果把整个工具调用的流程剖析开来，实际上是"Function Call + Agent + MCP系统"的组合。用一句话概括：大模型通过Function Call表达"我要调用什么工具"，Agent遵循指令执行工具的调用，而MCP则提供了一种统一的工具调用规范。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. MCP技术架构详解
2.1 整体架构设计
MCP采用经典的客户端-服务器（C/S）架构，其技术架构可以简单理解为一个由三个核心部分组成的系统：MCP Host、MCP Client和MCP Server。
2.1.1 MCP主机（MCP Hosts）
MCP主机是发起请求的AI应用程序，它们希望通过MCP协议访问外部数据或工具。典型的MCP主机包括：
- Claude Desktop等AI桌面应用
- AI驱动的IDE（如Cursor）
- 其他AI应用（如聊天机器人、自动化助手等）
2.1.2 MCP客户端（MCP Clients）
MCP客户端是MCP主机和MCP服务器之间的桥梁，与服务器一对一进行连接，负责与服务器进行通信，执行数据请求和工具调用。它的主要功能包括：
- 从MCP服务器获取可用的工具列表
- 将用户的查询和工具描述一起发送给大模型
- 接收大模型的决策，判断是否需要使用工具
- 通过MCP服务器调用相应的工具，并获取返回结果
- 将结果反馈给大模型，由大模型生成最终的自然语言响应
2.1.3 MCP服务器（MCP Servers）
MCP服务器是整个架构的核心，它实现了MCP协议，并提供各种功能来支持AI应用。它主要负责：
- 资源提供：提供可被读取的数据，如本地文件、API响应、数据库等
- 工具调用：提供可以被大模型调用的函数或操作
- 提示词管理：提供预定义的提示词模板，帮助用户完成特定任务
每个MCP服务器通常专注于特定的任务，例如：
- 读取和写入浏览器数据
- 访问本地文件系统
- 操作Git仓库
- 连接远程API等
2.2 数据源与连接方式
2.2.1 本地数据源（Local Data Sources）
MCP服务器可以访问计算机上的本地资源，例如：
- 本地文件（如PDF、Word文档、代码文件）
- 本地数据库（如SQLite、PostgreSQL）
- 其他本地应用的数据
本地数据源的特点是数据不会上传到远端，确保数据安全性。
2.2.2 远程服务（Remote Services）
MCP服务器也可以连接到远程资源，例如：
- 在线API
- 企业内部系统
- 其他基于云端的数据服务
远程服务通常通过API访问，并由MCP服务器进行管理，来确保访问权限的控制。
2.3 通信协议与方式
2.3.1 通信协议对比
MCP采用JSON-RPC作为底层的通信协议。JSON-RPC是一种基于JSON的轻量级远程调用协议，相较于HTTP来说它更加简洁、高效、容易处理。
| 属性 | HTTP | JSON-RPC |
|---|---|---|
| 本质 | 应用层协议（Web核心协议） | 轻量级RPC协议（基于JSON格式） |
| 数据格式 | 支持JSON/XML/二进制等多种格式 | 强制JSON格式，结构更简洁 |
| 协议功能 | 包含缓存/认证/状态码等完整功能 | 仅定义RPC调用规范（无底层逻辑） |
| 通信模式 | 无状态，支持GET/POST等多方法 | 无状态，基于method字段调用 |
| 适用场景 | Web API、浏览器交互、复杂业务 | 微服务内部调用、物联网等轻量场景 |
| 典型应用 | RESTful接口、网页加载 | 服务间函数调用、嵌入式设备通信 |
2.3.2 通信方式实现
MCP基于JSON-RPC协议，实现了以下三种主要通信方式：
-
STDIO方式
- 采用标准输入输出的方式，server端会在client端启动时，作为client端的子进程一起启动
- 适用于client和server在同一台机器上通信的场景，通常用于工具调试
- 实现原理是client和server两个进程间通过stdin和stdout进行双向通信
- 优点：无外部依赖；进程间通信极快；脱机可用
- 缺点：并发能力差，是同步阻塞模型；不支持多进程通信
-
SSE（Server-Sent Events）
- 一种基于HTTP协议的服务端主动推送机制
- 客户端通过EventSource向服务器发起一个长连接，服务器可以持续不断地通过这个连接发送文本数据
- 一般用于client在本地，server在远程服务器的场景
- 优点：简单易用，浏览器原生支持EventSource；自动重连，断线后自动尝试重新连接
- 缺点：单向通信（只能服务器推送）；不支持二进制，只能发送UTF-8文本；浏览器兼容性差；网络问题难以感知；不支持自定义Header，不便于鉴权
-
Streamable HTTP
- 本质上仍是标准的HTTP��求，但服务器端采用分块传输（chunked transfer encoding）
- 可以在响应体中逐块输出数据，实现流式返回
- 优点：支持流式响应，兼容所有现代浏览器和HTTP客户端；与标准HTTP完全兼容；支持自定义Header；可在客户端感知中断；不依赖浏览器特性
- 缺点：实现稍复杂；不像WebSocket那样全双工
SSE虽然在早期实现服务端推送场景中提供了一种简洁方式，但随着AI模型接口对可靠性、跨平台性、鉴权机制以及链路可控性提出更高要求，SSE的局限性逐渐暴露。而Streamable HTTP凭借其通用性、稳定性和良好的生态支持，成为更适合AI场景的流式传输方案。
2.4 完整工作流程
以下是MCP完成一次工作的完整流程：
-
连接阶段：建立通信通道
- MCP客户端启动并查找可用的MCP服务器
- 服务器验证请求，建立通信通道
- 连接建立后，客户端可以获取可用的资源、工具和提示信息
- 主机应用可以同时连接多个MCP服务器
-
请求发送：主机请求数据或