1. 什么是MCP（Model Context Protocol）
1.1 定义
MCP（Model Context Protocol，模型上下文协议） ，2024年11月底，由 Anthropic 推出的一种开放标准，旨在统一大型语言模型（LLM）与外部数据源和工具之间的通信协议。MCP 的主要目的在于解决当前 AI 模型因数据孤岛限制而无法充分发挥潜力的难题，MCP 使得 AI 应用能够安全地访问和操作本地及远程数据，为 AI 应用提供了连接万物的接口。
Function Calling是AI模型调用函数的机制，MCP是一个标准协议，使AI模型与API无缝交互，而AI Agent是一个自主运行的智能系统，利用Function Calling和MCP来分析和执行任务，实现特定目标。
其实，从本质上来讲，MCP 的灵感部分来源于 USB-C 的类比：如同 USB-C 通过统一接口连接多种设备，MCP 旨在为 AI 应用提供一个“即插即用”的上下文管理框架。
更为准确而言，MCP 的核心思想是将模型与外部系统之间的通信抽象为一个客户端-服务器架构，通过标准化的接口（如基于 JSON-RPC 的通信）实现上下文的动态传递和工具的灵活调用。Anthropic 在发布时提供了初步的规范和 SDK（如 Python 和 TypeScript），并开源了多个预构建的 MCP 服务器（如 Google Drive、GitHub 集成），以加速社区采纳。
1.2 MCP价值
举个栗子，在过去，为了让大模型等 AI 应用使用我们的数据，要么复制粘贴，要么上传下载，非常麻烦。
即使是最强大模型也会受到数据隔离的限制，形成信息孤岛，要做出更强大的模型，每个新数据源都需要自己重新定制实现，使真正互联的系统难以扩展，存在很多的局限性。
现在，MCP 可以直接在 AI 与数据（包括本地数据和互联网数据）之间架起一座桥梁，通过 MCP 服务器和 MCP 客户端，大家只要都遵循这套协议，就能实现“万物互联”。
有了MCP，可以和数据和文件系统、开发工具、Web 和浏览器自动化、生产力和通信、各种社区生态能力全部集成，实现强大的协作工作能力，它的价值远不可估量。
1.3 MCP 和Function Calling 的区别
- MCP（Model Context Protocol），模型上下文协议Function Calling，函数调用
这两种技术都旨在增强 AI 模型与外部数据的交互能力，但 MCP 不止可以增强 AI 模型，还可以是其他的应用系统。
| 类别 | MCP (Model Context Protocol) | Function Calling |
|---|---|---|
| 性质 | 协议 | 功能 |
| 范围 | 通用（多数据源、多功能） | 特定场景（单一数据源或功能） |
| 目标 | 统一接口，实现互操作 | 扩展模型能力 |
| 实现 | 基于标准协议 | 依赖于特定模型实现 |
| 开发复杂度 | 低：通过统一协议实现多源兼容 | 高：需要为每个任务单独开发函数 |
| 复用性 | 高：一次开发，可多场景使用 | 低：函数通常为特定任务设计 |
| 灵活性 | 高：支持动态适配和扩展 | 低：功能扩展需要额外开发 |
| 常见场景 | 复杂场景，如跨平台数据访问与整合 | 简单任务，如实现天气查询，翻译等 |
1.4 工作原理
MCP 协议采用了一种独特的架构设计，它将 LLM 与资源之间的通信划分为三个主要部分：客户端、服务器和资源。
客户端负责发送请求给 MCP 服务器，服务器则将这些请求转发给相应的资源。这种分层的设计使得 MCP 协议能够更好地控制访问权限，确保只有经过授权的用户才能访问特定的资源。
以下是 MCP 的基本工作流程：
初始化连接：客户端向服务器发送连接请求，建立通信通道。
发送请求：客户端根据需求构建请求消息，并发送给服务器。
处理请求：服务器接收到请求后，解析请求内容，执行相应的操作（如查询数据库、读取文件等）。
返回结果：服务器将处理结果封装成响应消息，发送回客户端。
断开连接：任务完成后，客户端可以主动关闭连接或等待服务器超时关闭。
1.5 MCP 核心架构
模型上下文协议（Model Context Protocol, MCP）的核心设计遵循客户端-服务器架构，这一架构允许一个宿主应用程序与多个服务器建立连接，从而实现灵活的上下文传递与功能扩展。
通常而言，MCP 的技术框架围绕三个关键组件构建：主机（Host）、客户端（Client）和服务器（Server）。这些组件共同协作，形成了一个高效、可扩展的生态系统，为 AI 模型与外部资源之间的动态交互提供了坚实的基础。在深入剖析其技术细节之前，我们先来简要概览这三大组件的角色与作用，以帮助读者建立清晰的认知框架，为后续的深入探讨奠定基础。
- MCP主机(MCP Host)：发起请求的LLM应用程序（例如Claude Desktop、IDE或AI工具）MCP客户端(MCP Client）：在主机程序内部，与MCP server保持1:1的连接MCP服务器（MCP Servers)：为MCP client提供上下文、工具以及prompt信息本地资源(Local Resource): 本地计算机中可供MCP server安全访问的资源（例如文件、数据库）远程资源（Remote Resource): MCP server可以连接到的远程资源（例如通过API）
MCP ClientMCP Client充当LLM和MCP server之间的桥梁， MCP client的工作流程如下：
MCP client首先从MCP server获取可用的工具列表将用户的查询连同工具描述通过function calling 一起发送给LLMLLM决定是否需要使用工具以及使用哪些工具如果要使用工具，MCP client会通过MCP server执行相应的工具调用工具调用结果会被发送给LLMLLM基于所有信息生成自然语言响应最后将响应展示给用户
Claude Desktop 和Cursor都支持了MCP Server接入能力，它们就是作为 MCP client来连接某个MCP Server感知和实现调用。
MCP Server
MCP server 是MCP架构中的关键组件，他可以提供三种类型的功能:
- 资源（Resource）：类似文件的数据，可以被客户端读取，服务器负责向 LLMs 暴露来自不同数据源的内容和信息， 如Api响应或文件内容。工具（Tools）：MCP 服务器能够为大型语言模型（LLMs）提供执行具体操作的能力。例如，通过服务器端的工具接口，LLMs 可以完成从代码调试到文件管理的各类任务，从而将模型的语言生成能力转化为实际的生产力。提示（Prompts）：MCP 服务器支持创建可复用的提示模板和工作流，帮助开发者设计标准化的交互模式。这种功能特别适用于需要高效迭代或批量处理的任务场景，例如自动化客服或内容生成流程。
这些功能使MCP server能够为AI应用提供丰富的上下文信息和操作能力，从而增强LLM的实用性和灵活性。
你可以在 MCP Servers Repository 和 Awesome MCP Servers 这两个 repo 中找到许多由社区实现的 MCP server。使用 TypeScript 编写的 MCP server 可以通过 npx 命令来运行，使用 Python 编写的 MCP server 可以通过 uvx 命令来运行。
1.6 通信机制
MCP协议支持两种主要的通信机制：基于标准输入输出的本地通信和基于SSE（Server Sent Events）的远程通信。
这两种机制都是用JSON-RPC 2.0 格式进行消息传输，确保了通信的标准化和可扩展性。
- 本地通信：通过stdio传输数据，适用于在同一台机器上运行的客户端和服务器之间的通信。远程通信：利用SSE与HTTP结合，实现跨网络的实时数据传输，适用于需要访问远程资源或分布式部署的场景。
