背景
随着大模型的快速发展，如何让模型与企业数据、工具高效对接成为核心挑战。传统方式需为每个数据源/工具编写定制化代码，导致开发成本高、扩展性差、安全性低，形成“烟囱式开发”。
如何让大语言模型与外部系统交互，已经成为AI系统急需解决的问题。从2023年到现在，业界也有过多种尝试，我们也一起来梳理一下：
-
原始时代——prompt转json。大家现在回头看看写在代码里面的prompt是否还有大量的提示词转结构化数据的要求。优点就是可以很快的事项让大模型给出符合格式的结果。缺陷也是很大，就是不可靠。常遇到的比如json的key错误，json格式不对，时间格式不匹配。
-
农耕时代——Plugins。2023年3月份，OpenAI 官方发布了重磅的「ChatGPT plugins」。也是大模型首次允许通过插件与外部应用交互的能力，也给了AI应用很大的想象。比如当前大模型都具备的实时信息检索，也是这个时候引入的。
-
铁器时代——Function Calling。2023年6月，OpenAI在GPT-3.5和GPT-4模型中首次引入Function Calling机制，赋予模型调用外部函数的能力，使其能够结合真实的数据或计算结果，而非单纯依赖模型自身的推理能力，这样不仅可以提高模型的可控性和准确性，还能让其更适应实际业务需求。Function Calling的意义在于让大模型结果闭环且可控，在大模型流程中加入函数能力，让其获取到外部数据，不必再自行幻想出来结果，并且结构化的输入给到大模型，输出的结果更加稳定。
-
蒸汽时代——Agent框架 Tools。Agent可以根据任务动态选择Tool是完成任务，所以Tool应该是大模型能力的补充。
-
电气时代——MCP。在上一时代中的Agent的Tool诞生可以补充大模型的缺失的能力和数据，但是还需要一个大问题，一个企业或者应用面对不同的大模型不同的系统如何快速集成到一起，一个个是开发Tools？这是一个重复且繁琐的工作。为此本文的主角——MCP协议诞生了。
MCP是什么？
按照博文所说：MCP （Model Context Protocol，模型上下文协议）为连接 AI 系统和数据源提供了一个通用的开放标准，用单一协议取代了分散的集成。换一个说法是 以一致的方式将各种数据源、工具和功能连接到 AI 模型中间协议。可以说MCP协议类似大家现在使用的type-c接口，可以让不同的设备通过相关的接口协议连接在一起，组成不同功能的系统。更通俗的方式类比是，你拿着一个万能翻译器，去不同的国家和地区旅游，可以以不同的人员通过万能翻译器实时对话，这个万能翻译器就是MCP协议。
针对MCP有几点需要注意：
-
Function Calling是大模型与外部数字世界的交互方式。MCP是MCP host(chatbot或者AI工具)与外部工具/资源之间的交互方式。
-
MCP比Plugins规范性更好，定义了清晰的数据格式、传输协议、身份验证方法等，能力也更强。
-
GPTs是OpenAI的应用市场，主要是给人使用的。MCP server主要是给AI使用的，不直接给人用。
-
MCP与Agent是合作关系，彼此有对应的关系：
|
Agent能力
|
MCP特性
|
|
工具（技能）调用
|
Tool
|
|
LUI 交互
|
Prompt
|
|
感知
|
Resource（Changed Notification）
|
|
深度思考
|
Resource（Listing/Reading Resources）
|
那为什么需要MCP协议呢？下面通过一张图来说明。
可以看到，MCP协议将原本M×N集成问题（M AI客户端×N数据源）转化为M+N问题-任何MCP兼容的AI客户端都可以与任何MCP兼容的数据源或工具一起工作。
为什么需要MCP？
-
MCP的出现可以解决大模型的数据和能力补充问题，大模型的训练是在大量的数据上训练出来的，这些知识是过去的，也可能是不完整的，比如今天的天气数据，我们团队刚刚写出来的产品报告，需要帮助我在饿了么订外卖等。这些数据和能力是大模型不具备的。有了MCP后大模型就可以获取到最新的数据，拥有更多的能力补充，可以极大的降低幻觉，让AI更加可靠。
-
MCP是通用的AI模型集成方法。上面的图已经说明了，没有MCP时候，AI模型访问多个系统意味着要处理大量的应用编程接口、软件开发工具包和身份验证方法。而且服务之间的连接会随着功能的增加出现指数式增长，必然会导致系统脆弱。MCP用一个标准接口取代了这种复杂性，大大简化了开发。
-
MCP不绑定任何厂商。Anthropic开源了MCP规范，并由社区驱动。当前与AI模型是一致的，开放性才是不断增长的系统，大家一起努力才可以把生态构建出来。
总之出现MCP，根本原因是 大模型百家争鸣，各有所长并且数据孤岛的壁垒无法打破。
MCP可以做什么？
MCP作为连接AI模型与外部系统的标准化协议，其核心价值在于打破数据孤岛、提升模型交互能力，并推动AI从“被动响应”向“主动执行”转型。目前可以预知到的MCP的应用场景有四大核心场景。
场景一 AI模型治理与合规管理
军政、金融、医疗等强监管行业需对AI访问权限进行细粒度控制，例如限制模型仅读取脱敏数据或禁止写入关键系统。通过MCP的数据沙箱机制和权限审批流程，实现动态策略调整与操作审计，满足GDPR、HIPAA等法规要求。MCP 服务器可以支持不同的访问策略并且可以实现访问时进行身份验证，有效地充当AI模型和企业之间的门神。内部数据的获取和响应都是通过MCP服务器，类似数据网关，实时监控模型行为，发现异常（如数据泄露风险）时自动触发防护机制（如阻断敏感API调用）。
场景二 实时上下文增强与知识更新
AI模型对过去交互的记忆有限，因此在推理时提供相关的、实时的上下文至关重要。MCP服务器连接实时数据源（如OS Drive、Slack、数据库），确保AI响应基于最新信息（如客户最新订单、库存状态）。通过MCP资源功能加载专业文档（如法律条款、产品手册），提升AI在垂直领域的专业性（如法律咨询、技术支持）。通过MCP服务器允许AI模型可以在需要的时候从指定的渠道获取到相关的数据甚至可以进行相关的操作。比如创建一个Excel文档将收集和整理好的简历写入。在客服场景中，可以关联用户的信息（订单、兴趣、）和之前与客服的沟通内容，结合企业内的SOP，为用户解决问题。还有在AI编码的场景也是有很好的应用，AI模型可以通过MCP服务器获取git仓库的代码和接口文档、产品设计、方案设计甚至是编码规范，可以为程序员提供更好的编码提示和建议。
同时，使用结构化格式传递信息避免歧义，可以更有效地指导AI模型推理。更可靠的知识源，结合结构化的数据上下文，AI模型就可以应用在要求可靠性更高的场景，比如医疗诊断。
场景三 工具生态扩展与系统互联
试想一下，这样的场景。用户反馈APP的一个bug上来后，AI模型自动根据Git 的MCP服务器，结合产品文档需求和用户描述，自动化实现bug修复并通过CI/CD MCP服务器实现服务上线。MCP协议将会是AI模型和各个工具之间互联互动的桥梁。MCP如果成为了标准协议，将各个AI模型和丰富的工具和平台链接起来，打破信息孤岛，让AI的自动化升级为AI智能化。MCP可以成为AI模型对工具和平台的监督和驱动大脑，让它们协同的完成工作。
对于不同的企业和平台来说，MCP可以让不同AI模型的能力获取最大化，也建议让AI模型方案统一化。 AI模型不应该只是在浏览器上，也不应该只是在APP应用上，而是应该集成到操作系统中，在系统层面获得更大的能力。
场景四 企业级智能助手与Agent构建
MCP作为企业内部AI Agent的“数据总线”，整合CRM、MES等多系统数据，例如制造业AI Agent通过MCP协调IoT传感器与生产调度系统。企业部署MCP驱动的虚拟助手，可统一响应员工IT支持、审批进度查询等需求，响应时效缩短至秒级。在医院，可通过MCP构建AI助手，实时分析患者病史并提醒医生药物相互作用风险。MCP可以让Agent的构建更加强大。
MCP有什么？
组件
MCP本质还是一种C/S架构，官方给出的架构图：
MCP 由三个核心组件构成：Host、Client 和 Server。
-
MCP Hosts: 负责接收用户提问并与 AI 模型交互，充当容器和协调者：
-
创建和管理多个客户端实例
-
控制客户端连接权限和生命周期
-
协调 AI/LLM 集成和采样
-
管理Clients之间的上下文聚合
-
MCP Clients：与服务器保持 1:1 连接的协议客户端，将Server连接到的客户端中，组成不同功能的应用：
-
和每个 server 建立一个有状态的会话
-
处理协议协商和能力交换
-
双向路由协议消息
-
管理订阅和通知
-
维护 servers 之间的安全边界
-
MCP Servers： 轻量级程序，每个程序都通过标准化模型上下文协议公开特定功能：
-
通过 MCP 原语暴露resources、tools 和prompts
-
通过client 提供的接口请求sampling
-
可以是本地进程或远程服务
-
具备特定的功能
协议
MCP的规范中协议层、传输层和消息类型：
传输层
MCP 目前定义了两种标准的 client-server通信传输机制：stdio（标准输入输出）和基于 SSE 的 HTTP。此外，客户端和服务器也可以以可插拔的方式实现自定义传输机制。
|
通信传输机制
|
部署方式
|
网络要求
|
场景
|
应用
|
|
|
Stdio transport 标准传输
|
本地子进程
|
无需网络
|
|
filesystem
|
|
|
HTTP with SSE transport 带有 SSE 传输的 HTTP
|
独立服务器进程
|
需要网络连接
|
-
分布式部署、多客户端
-
对于需要 HTTP 兼容性的场景使用 SSE
-
考虑安全影响，包括身份验证和授权
|
search
|
|
消息类型
所有在 MCP clients 和 servers 之间的消息必须遵循 JSON-RPC 2.0 规范，基于 JSON-RPC 2.0，确保消息格式结构统一。该协议定义了三种基本类型的消息：
|
消息类型
|
描述
|
约束
|
|
Requests
|
用于具体操作的消息
|
-
必须包含唯一的 ID 和方法名称
-
ID 不能为 null
-
请求 ID 在同一会话中不得被请求者之前使用过
|
|
Responses
|
请求的响应
|
|
|
Notifications
|
单向消息，不需要回复
|
不得包含 ID
|
Requests
Requests可以从Client端或者Server端发起，其格式为：
{
jsonrpc: "2.0";
id: string | number;
method: string;
params?: {
[key: string]: unknown;
};
}
在MCP Server中对请求需要做到：
-
彻底验证输入，验证 JSON-RPC 格式
-
使用类型安全架构
-
妥善处理错误
-
实施超时处置
在MCP中定义的requests的业务类型：
表格 还在加载中，请等待加载完成后再尝试复制
initialized是非常重要的阶段，是MCP Client和MCPServer之间的第一次交互。类似HTTPS一样需要确认彼此协议版本的兼容性、交换和协商各自能力。Client 必须发送其支持的协议版本，如果server支持请求的协议版本，则必须以相同的版本进行响应。否则，server必须以其支持的其他协议版本进行响应。这应该是server支持的最新版本。
initialized能力协商
表格 还在加载中，请等待加载完成后再尝试复制
Prompts
MCP还提供Prompt能力，可将重复使用的提示模板和工作流程放在Server以便Client使用。Prompts的主要价值是对Resource的内容进行解释，让LLMs能够更好的理解返回的数据，从而更好的完成任务。
Responses
Responses是对requests的回复，其格式为：
{
jsonrpc: "2.0";
id: string | number;
result?: {
[key: string]: unknown;
}
error?: {
code: number;
message: string;
data?: unknown;
}
}
MCP的核心就是将资源暴露给到AI模型，Response的类型是多种多样的，有文本、二进制文件、API等等。Server拥有的Responses如何让AI模型知道呢？这就需要Direct resources直连资源，MCP Server 通过esources/list 端点公开固定的资源列表，每个资源的属性包含：
{
uri: string; // Unique identifier for the resource
name: string; // Human-readable name
description?: string; // Optional description
mimeType?: string; // Optional MIME type
}
如果Server端的Responses的生成是动态资源，那么还可以通过Resource templates来支持。在实际中，Server的Resource并不会固定不变，而是时常变化，MCP提供了资源更新（Resource updates）机制：
|
机制类型
|
机制描述
|
应用场景
|
核心特点
|
|
资源列表变更通知
|
服务器通过notifications/resources/list_changed通知客户端资源列表结构性变化
|
目录结构变动、新增资源类型等全局性更新
|
|
|
资源内容实时订阅
|
客户端通过resources/subscribe订阅资源，服务器通过notifications/resources/updated推送变更
|
日志文件追加、API数据刷新等动态内容更新
|
-
支持实时推送
-
可随时取消订阅
-
客户端主动拉取最新内容
|
|
Streamable HTTP传输
|
新增流式传输协议，支持断点续传、无状态服务器及动态SSE升级
|
高并发场景、云平台部署、需要兼容CDN/API网关的场景
|
-
断点续传解决掉线问题
-
无状态服务器降低部署成本
-
兼容标准HTTP生态
|
现在AI模型已经知道Server有哪些资源了，还需要可以读取到这么Resource，就需要使用resources/read请求。
在MCP Server中对响应需要做到：
-
对长时间操作使用进度标记，可逐步报告进度
-
使用适当的错误代码，包含有用的错误消息和发生错误时清理资源
-
不要泄露敏感信息并记录与安全相关的错误
Notifications
Notifications是从client 发送到server 或反向发送的，不需要回复。其格式为：
{
jsonrpc: "2.0";
method: string;
params?: {
[key: string]: unknown;
};
}
案例
本小节以github.com/mark3labs/mcp-filesystem-server 为例介绍MCP相关的消息类型。
初始化会话：initialized
Request
{
"jsonrpc": "2.0",
"id": 12,
"method": "initialize",
"params": {
"protocolVersion": "1.0",
"capabilities": {
"roots": {
"listChanged": true
}
},
"clientInfo": {
"name": "test-client",
"version": "1.0.0"
}
}
}
Responses
{
"jsonrpc": "2.0",
"id": 12,
"result": {
"protocolVersion": "2024-11-05",
"capabilities": {
"resources": {
"subscribe": true,
"listChanged": true
},
"tools": {
}
},
"serverInfo": {
"name": "secure-filesystem-server",
"version": "0.4.1"
}
}
}
发现可用的工具:tools/list
Request
{
"jsonrpc": "2.0",
"id": 12,
"method": "tools/list",
"params": {
}
}
Responses
{
"jsonrpc": "2.0",
"id": 12,
"result": {
"tools": [
{
"description": "Create a new directory or ensure a directory exists.",
"inputSchema": {
"type": "object",
"properties": {
"path": {
"description": "Path of the directory to create",
"type": "string"
}
},
"required": [
"path"
]
},
"name": "create_directory"
},
{
"description": "Retrieve detailed metadata about a file or directory.",
"inputSchema": {
"type": "object",
"properties": {
"path": {
"description": "Path to the file or directory",
"type": "string"
}
},
"required": [
"path"
]
},
"name": "get_file_info"
},
{
"description": "Returns the list of directories that this server is allowed to access.",
"inputSchema": {
"type": "object"
},
"name": "list_allowed_directories"
},
{
"description": "Get a detailed listing of all files and directories in a specified path.",
"inputSchema": {
"type": "object",
"properties": {
"path": {
"description": "Path of the directory to list",
"type": "string"
}
},
"required": [
"path"
]
},
"name": "list_directory"
},
{
"description": "Move or rename files and directories.",
"inputSchema": {
"type": "object",
"properties": {
"destination": {
"description": "Destination path",
"type": "string"
},
"source": {
"description": "Source path of the file or directory",
"type": "string"
}
},
"required": [
"source",
"destination"
]
},
"name": "move_file"
},
{
"description": "Read the complete contents of a file from the file system.",
"inputSchema": {
"type": "object",
"properties": {
"path": {
"description": "Path to the file to read",
"type": "string"
}
},
"required": [
"path"
]
},
"name": "read_file"
},
{
"description": "Recursively search for files and directories matching a pattern.",
"inputSchema": {
"type": "object",
"properties": {
"path": {
"description": "Starting path for the search",
"type": "string"
},
"pattern": {
"description": "Search pattern to match against file names",
"type": "string"
}
},
"required": [
"path",
"pattern"
]
},
"name": "search_files"
},
{
"description": "Create a new file or overwrite an existing file with new content.",
"inputSchema": {
"type": "object",
"properties": {
"content": {
"description": "Content to write to the file",
"type": "string"
},
"path": {
"description": "Path where to write the file",
"type": "string"
}
},
"required": [
"path",
"content"
]
},
"name": "write_file"
}
]
}
}
发现可用的工具:tools/call
Request
{
"jsonrpc": "2.0",
"id": 12,
"method": "tools/call",
"params": {
"name": "list_allowed_directories",
"arguments": {
"path": "/Users/ouerqiang/Downloads/1.txt"
}
}
}
Responses
{
"jsonrpc": "2.0",
"id": 12,
"result": {
"content": [
{
"type": "text",
"text": "Allowed directories:\n\n/Users/ouerqiang/project/gopath/src/github.com/mark3labs/mcp-filesystem-server (file:///Users/ouerqiang/project/gopath/src/github.com/mark3labs/mcp-filesystem-server)\n/Users/ouerqiang/Downloads (file:///Users/ouerqiang/Downloads)\n"
}
]
}
}
发现可用的资源：resources/list
Request
{
"jsonrpc": "2.0",
"id": 12,
"result": {
"content": [
{
"type": "text",
"text": "Allowed directories:\n\n/Users/ouerqiang/project/gopath/src/github.com/mark3labs/mcp-filesystem-server (file:///Users/ouerqiang/project/gopath/src/github.com/mark3labs/mcp-filesystem-server)\n/Users/ouerqiang/Downloads (file:///Users/ouerqiang/Downloads)\n"
}
]
}
}
Responses
{
"jsonrpc": "2.0",
"id": 12,
"resources": [
{
"uri": "file://",
"name": "File System",
"description": "Access to files and directories on the local file system"
}
]
}
其他的格式就请各位同学自行去验证。
服务层
MCP 服务器可以提供三种主要类型的功能：
-
Resources：客户端可以读取的类似文件的数据（例如 API 响应或文件内容）
-
Tools：可由LLM调用的函数（需经用户批准）
-
Prompts：预先编写的模板，帮助用户完成特定任务
上面的三个功能并不要求MCP Server全部提供，可以提供一种或者多种类型的功能。
看着也是在MCP Server实现了对外部服务的API对接给到AI模型，为什么还需要多加MCP，直接让AI模型直接调用外部服务API不是更好吗？这是因为，MCP 不仅实现了 API 的功能，还带来了更高的标准化和灵活性。
表格 还在加载中，请等待加载完成后再尝试复制
客户端
对于大多数开发者而言，主要开发的模块还是MCP Server，而MCP Client 主要面对的还是直接的用户。客户端可以向服务器提供以下功能：
在业界中也有很多支持MCP 的应用程序，每个客户端可能支持不同的 MCP 功能，从而允许与 MCP 服务器进行不同程度的集成。
业界MCP Client
https://modelcontextprotocol.io/clients
MCP实践
本人主要使用Golang为主，但是官网上只提供了Python、TypeScript、Java、Kotlin的SDK，并未提供golang。我也查看了github库，也亲身验证了一些框架，目前比较好的Go MCP框架有两个：
我们可以对比一下这两个框架。
对比
核心功能对比
表格 还在加载中，请等待加载完成后再尝试复制
技术选型决策矩阵
表格 还在加载中，请等待加载完成后再尝试复制
从代码的设计、使用灵活度和对外部框架的集成而言，使用 metoro-io/mcp-golang是不错的选择。
总结
MCP作为Anthropic开源的AI系统与数据源交互协议，凭借其统一性、可控性和高效性在AI集成领域展现出潜力。该协议通过标准化工具调用、资源访问和提示模板，解决了传统插件或自定义工具开发的高成本问题，尤其为非技术人员提供了便捷的AI能力扩展途径。例如，开发者可通过MCP Server快速暴露功能，供Claude、Cursor等客户端直接调用，显著提升跨系统协作的灵活性。
然而，MCP仍面临多重挑战。协议公布仅半年，主流编程语言（如Go、Rust）的支持尚不完善，生态建设仍处于早期阶段，可用工具数量和质量难以满足复杂场景需求。同时，LangChain创始人Nuno Campos指出，当前模型对工具的调用成功率仅约50%，且MCP的双向通信机制和本地化部署方式增加了实现复杂度，对比IBM新推出的ACP协议，其在无状态设计、跨平台兼容性等方面可能存在劣势。
尽管如此，MCP的前景值得期待。随着基础模型能力的迭代优化，工具调用准确率有望提升。若协议能进一步简化部署流程（如云端托管）、扩大语言支持范围，并借助社区力量构建高质量工具生态，其有望成为连接AI系统与现实世界的核心桥梁。正如Harrison Chase所言，MCP的核心价值在于为不可控的第三方Agent提供标准化接入方案，这种开放性使其在长尾场景中具备持久生命力。
一句话，MCP未来可期！
附录
https://www.anthropic.com/news/model-context-protocol
https://mp.weixin.qq.com/s/WndS_QSbQFalFvBcGzur4A
https://mp.weixin.qq.com/s/kQrltrzRk-SVLfWm_zsPoA
https://github.com/CherryHQ/cherry-studio/releases/tag/v1.1.7
