MCP 协议：LLM 应用开发的“适配器”

【直播预告】昇腾 × 大模型：如何让 AI “跑得快” 又 “用得好”？

最近，许多软件和平台纷纷上线 MCP Server，按照 MCP 协议统一与大模型的交互接口，如 Gitee MCP Server、百度地图 MCP 的发布等等。

通过 Gitee MCP Server 读取用户 Gitee 仓库中的 Issue

重新定义大模型交互范式

MCP 协议可以简单理解成是一个国际通用版本的转接头，将大模型与各种外部系统、工具和数据源链接在一起。它通过定义统一的通信规范和数据格式，实现了异构技术栈间的无缝对接，使得算力资源、行业知识库与 AI 模型能够突破平台限制进行跨维度协作。

比如，要调用大模型做一个客服 AI，通常需要同时访问客户信息、产品知识库和工单系统等，开发者要为每个数据源编写独立代码，开发定制化的 API 接口，还要实现复杂的鉴权与错误处理机制，并对模型进行特定格式的指令训练。

而通过 MCP 协议，就可以直接将这些系统接入统一的 MCP 管理，像“插排接电器”一样即插即用。

具体来说，开发者不再需要为每个数据源单独开发 API，只需在 MCP 中配置一次工具（如客户数据库、工单系统），后续所有兼容 MCP 的 AI 模型都能直接调用这些服务。

MCP Server 会实时维护可用的工具列表，AI 模型在交互时能自动感知到新接入的系统。例如：企业新增了一个物流跟踪系统；管理员只需要将其注册到 MCP Server 并声明服务类型；客服 AI 无需停机升级，即可通过协议内置的语义理解模块自动识别该工具的功能边界，直接调用接口回答用户物流问题。

MCP 协议还具备跨平台兼容性，无论底层系统是 Java 开发的工单平台，还是 Python 写的知识库，甚至是遗留的 COBOL 系统，只要接入 MCP Server，就能被 AI 模型以统一方式调用。这相当于给所有工具装上了“万能翻译器”。

除了常见数据库，MCP 还支持接入：

• Web API：天气查询、支付网关等

• 代码仓库：Git 操作自动化

• 本地系统：文件操作、硬件设备控制

• 企业系统：SAP/Oracle 等 ERP 系统

协议背后的工程智慧

那么，MCP 是如何实现这些能力的？

MCP 就是 Claude(Anthropic) 主导发布的一个开放的、通用的、有共识的协议标准，本质上只是定义了一套基于 JSON-RPC 的通信规则，从而将外部服务的调用标准化，只要支持这套协议的 Host 和 Agent 都可以接入。核心组件包括：

• MCP Host：主机负责发起与 LLM 的连接，类似 Cursor, Claude Desktop、Cline。

• MCP Client: 客户端是用来在 Host 应用程序内维护与 Server 之间 1:1 连接。根据客户端的不同，MCP 的使用方法也不同，如 Clinn 是直接附加在系统提示词中；5ise 是 Function Call 的模式。

• MCP Server: 通过标准化的协议，为 Client 端提供上下文、工具和提示。Mcp Server 的本质是运行在本地电脑上的一个 nodejs 或者 Python 程序。

• 本地数据源: 包含本地文件、数据库和服务。

• 远程服务: 可连接的外部文件、数据库、API。

整个 MCP 的调用过程大致可以分为 5 步：

1. 客户端将 MCP 详细使用方法告诉大模型

2. 用户输入问题通过客户端传递给大模型

3. 大模型自行决定调用哪个 Mcp Server，以及如何传递参数

4. 客户端根据大模型决定的调用方式，调用 MCP Server，拿到返回结果，加上之前的上下文，再传递给大模型

5. 大模型进行整理，然后把最终的结果呈现给用户

简化了各式外部资源的调用之后，在 LLM 上构建复杂的工作流或者应用就会相应简化。同时，由于 MCP 协议解耦了工具和 LLM，可以实现 LLM 自由切换，并且数据和工具不需要上传远端，保护数据隐私。

目前，MCP 支持的语言列表中已经包含 Kotlin SDK、Python SDK、TypeScript SDK 和 Java SDK。

在社区的最新动态中，MCP 本身也有望采用 "Streamable HTTP" 传输代替「HTTP+SSE」的 PR，以解决当前远程 Model Context Protocol (MCP) 传输方式的关键限制。简单来说，Streamable HTTP 改变了 MCP 的数据传输方式，让协议变得：更灵活，支持流式传输，但不强制；更易用，支持无状态服务器；更兼容，适用于标准 HTTP 基础设施。

一个简单的比喻是： 原来的 MCP 传输方式就像是你和客服通话时必须一直保持在线（SSE 需要长连接），而新的方式更像是你随时可以发消息，然后等回复（普通 HTTP 请求，但可以流式传输）。

MCP Vs Function Calling

MCP 和此前的 Function Calling 相比，本质上都是让大模型通过标准化的接口来调用外部工具和服务，实现更多复杂功能，区别在于协议层抽象深度与系统级自治能力的跃迁。

Function Calling 是模型厂商提供的工具调用框架，停留在应用层工具调度的维度，开发者需显式定义工具清单、编写参数模板并固化调用逻辑，那么 LLM 就可以根据清晰的结构化数据进行推理，执行函数。缺点就是很难处理好复杂需求与多轮对话，同时代码量较大，难以维护。此外，不同的模型有不同的 Function Calling 实现，代码集成的方式也不一样，很难统一标准。

以开头的 Gitee MCP Server 为例，如果用户想读取仓库中的 Issue 列表，Function Calling 方案下，开发者首先要定义工具函数，手动编写 Gitee API 调用逻辑；大模型调用时需要精确控制参数传递，手动解析参数并执行。在这个过程需要要自己处理鉴权令牌传递，存在安全风险，还需为每个 API 编写参数校验逻辑，新增 API 时必须修改代码并重新训练模型适配。

但在 MCP 协议方案下，只需要注册 Gitee MCP Server，一次配置即可实现大模型直接调用。MCP Server 会自动完成以下动作：

1. 识别需要调用 Gitee 的 issue 接口

2. 从安全中心获取当前用户 OAuth 令牌

3. 转换参数格式调用 API

4. 将原始数据转换为模型友好格式

此外，Gitee MCP Server 让 AI 助手可以读取仓库内容、分析 PR 变更、理解 Issue 需求，并自动执行代码管理任务，如创建 PR、合并分支、发布版本等。

• 智能化仓库管理：AI 直接访问代码库，读取文件、分析变更，辅助开发决策；

• 自动化 PR 审查：识别代码变更，提供优化建议，减少人工审查工作量；

• Issue 追踪与管理：AI 可解析 Issue 内容，生成修复建议，甚至直接提交 PR 解决问题；

相较之下，Function Calling 更适合快速验证原型、仅需调用少量简单工具、使用单一模型厂商服务的业务场景中。

MCP 协议则更适合企业级系统集成、需要长期维护扩展、涉及多模型/多厂商协同的业务场景中。

下一步：成为行业共识

当下的大模型智能应用越来越多地使用到了多 Agent 系统，也逐渐在复杂业务中落地。MCP 协议的出现，或许是实现智能应用 从“单兵作战”到“群体智能”转变的一个关键技术。

在 MaaS 平台中，通过标准协议，模型可以像微服务一样被动态调用。例如，电商平台的推荐系统可同时调用文本理解、图像生成、语音合成等多个模型，无需关心底层通信细节。在 Agent 的协作中，MCP 支持智能体间的任务分发与结果聚合。例如，在自动驾驶场景中，视觉模型、路径规划模型、语音交互模型可通过 MCP 实时协同，形成闭环决策。

从去年12月发布至今，市场上也出现了各式 MCP Server，覆盖浏览器自动化处理、日历管理、云平台操作管理、电商服务、游戏多媒体服务、文件系统、基础服务等方面。

MCP 也是一个开放性协议，为开发者社区提供了协作基础，降低集成成本，开发者无需为每个模型定制适配层，可专注于业务逻辑。开放生态也推动标准化工具链，围绕 MCP 的调试工具、性能监控平台、安全审计框架等生态工具正在兴起，形成类似 Kubernetes 之于云原生的技术栈。

一些常用的 MCP Server 汇总

不过，虽然目前看起来 MCP 前景广阔，但从实际应用角度看，MCP协议目前存在几个关键限制。

MCP 的实现逻辑是通过安装相应的 MCP Server 到系统中，交给大模型去选择并调用，那么。当接入的外部系统较多时，AI 可能无法快速选择最优工具，甚至出现调用错误的情况。而随着客户端安装的 MCP Server 增加，存储在系统中的 Prompt 就会越长，也需要告诉大模型更多的 MCP Server 参数，进而导致上下文消耗更多 Token 或是调用混乱？

在 Anthropic 发布的 MCP Rodemap 中也提到了 Agent Support，扩展 MCP 使其适合更加复杂的 Agent 流程，包括关注分层 Agent，交互式工作流等。

当然，还有一个更严峻的挑战——当前 MCP 尚未成为行业共识，未来是否会出现新的协议，又或是以更简洁的方式实现 AI 应用开发还未可知。