一文看懂MCP（万字长文）

浮雷2025-04-20 18:42

LLM + MCP = AIPU（Artificial Intelligence Processing Unit）

  • LLM：算力 - 智力（绍兴师爷，君子动口不动手）
  • MCP：数据交换，协议对接 - IO能力（长工，具体干活的）

一、背景

1.1、MCP协议的设计初衷

大型语言模型（LLM）在近年取得了长足进步，其推理能力和回答质量显著提升。然而，在缺乏统一接口的情况下，即使是最先进的模型也往往被隔离在数据之外------受困于信息孤岛和各种遗留系统。当前开发基于大模型的应用，每接入一个新数据源或外部工具，都需要开发者编写一个定制的数据源连接器或集成逻辑。不同应用、不同数据源之间缺乏通用标准，导致碎片化集成 问题严重：每个新的数据源都需要独立实现，难以复用，这使得真正互联的AI系统难以扩展。更糟的是，不同项目往往采用各自独特的集成方式，这不但增加了开发工作量，也埋下了维护隐患。举例来说，如果一个AI应用需要同时对接多个系统（如内部数据库、第三方API、办公工具等），在没有统一协议时，开发团队不得不为每种集成各自编写代码和维护，这无疑是一个"定制开发+维护噩梦" 。

需求：随着AI助手在各行业逐渐落地，如何让大模型直接利用实时的、专有的数据 成为关键需求之一。传统做法是通过额外的检索步骤（如问答的向量数据库检索文档）或工具调用机制（如LangChain定义的工具函数）来弥补模型与数据的隔阂，但这些方案往往缺乏标准化 。开发者需要重复造轮子，为每个数据源编写一对一的适配代码 ，导致开发周期长、功能受限，难以快速构建功能全面的AI应用。在没有MCP之前，每位开发者若想让AI访问公司文件或业务数据库，都得自行开发连接模块，这种重复劳动既耗时又低效。同时，不同集成模块缺乏统一规范，也增加了系统复杂度和后期维护成本：当数据源接口变化或应用迁移时，需要重写大量代码才能适配。

1.2、为什么需要MCP？

Anthropic于2024年11月推出了模型上下文协议（Model Context Protocol, MCP），旨在为上述难题提供解决方案。MCP的设计初衷是为AI系统与外部数据源、工具之间建立一个通用开放标准 。正如官方博客所述，MCP用单一协议替代了过去零散不一的集成方式 ，为AI获取所需数据提供了一种更简单、更可靠的途径。通过引入这一标准接口，开发者无需再维护针对每个数据源的独立连接器，而是可以让所有AI应用和数据源都说"同一种语言"进行通信。这类似于现实中USB接口的作用：过去各种设备各用各的接口，自从有了USB这个统一标准后，不同厂商的设备都能轻松连接。同样地，在MCP出现之前，每对AI应用和数据源/工具都是"一线牵"的特殊适配；而有了MCP，就如同给AI应用配上了通用转接头，可以无缝连接各种数据源。

没有MCP时的痛点：可以用"USB-C端口"这一比喻来形象说明MCP出现前后的差异。在没有USB-C之前，不同电子设备需要不同的连接线才能"对接"；同理，没有MCP之前，AI应用想接入某个数据源或工具，都得从头开发专用接口，过程费时费力且功能可能受限。这导致很多AI应用"闭门造车" ：只能局限于自身训练数据，无法方便地利用用户的实时数据和现有工具。对于AI应用的最终用户来说，这意味着他们的AI助手只能回答已有知识，而无法触及他们日常使用的信息和工具 ------AI 模型缺乏用户上下文，智能服务的相关性和实用性大打折扣。而对于开发者来说，缺乏统一协议意味着重复劳动 和维护噩梦 ：大家都在各自实现Google Drive或Slack的接入功能，既浪费人力，又很难保证所有实现的一致性与安全性。

MCP协议正是为了解决上述问题而生，其核心目标是打破数据孤岛 ，让前沿的大模型可以方便、安全地访问到用户授权的各种数据，从而给出更加贴合实际、更有上下文关联的回答 。通过标准化AI应用与数据源的交互方式，MCP极大降低了集成复杂度，让开发者聚焦于AI能力本身的创新 ，而不再为底层繁琐的连接细节分心。如Anthropic官方所言： "开发者现在可以针对统一的标准协议进行构建，随着生态的发展，AI系统在不同工具和数据集之间移动时也将保持上下文，取代当今支离破碎的集成，以更可持续的架构取而代之 "。由此可见，MCP的初衷在于为AI产业提供互操作性基础，消除数据访问障碍，为大模型应用的规模化落地铺平道路。

二、MCP协议原理

2.1、什么是MCP？

MCP（Model Context Protocol）是一个开放协议，它标准化了应用向LLM提供上下文的方式 。简单来说，MCP定义了一套通用的通信规则 ，允许任意AI应用（客户端）与任意数据源/工具服务（服务器）互相交流，而不受实现细节限制。Anthropic将其比喻为AI应用的USB-C 接口 ："就像USB-C为连接各种外围设备提供了标准化方式一样，MCP为将AI模型连接到不同数据源和工具提供了标准化途径"。换言之，MCP 既不是一个像LangChain那样的应用框架，也不是具体的工具，它更类似于HTTP （用于万维网的协议）或gRPC （远程过程调用协议）这样的通信协议 。通过MCP，开发者为AI系统打造了一个统一的"插口"，让不同厂商、不同平台的AI应用与数据源都能即插即用 地协同工作。MCP的作用类似于语言服务器协议（LSP） 之于开发工具生态：LSP标准化了IDE与编程语言引擎的交互，同样地，MCP标准化了AI应用与外部上下文（数据和工具）的集成方式。

2.2、架构设计

MCP采用典型的 客户端-服务器架构。在这个架构中涉及三类主要角色：

  • （1）MCP主机（Host） ：发起连接并承载LLM应用的程序，例如Claude桌面应用、Cursor、IDE插件或其他AI工具，它是整个AI工作流程的协调者；
  • （2）MCP客户端（Client） ：运行在主机内部，用于与MCP服务器建立连接、通信的组件，每个客户端负责连到一个服务器，因此Host可以通过多个客户端并行连通多个服务器；
  • （3）MCP服务器（Server） ：独立的轻量服务，负责暴露特定能力或数据 ，供客户端调用。服务器可以连接到底层的本地数据源 （如本机文件、数据库、应用）或远程服务（通过API提供的外部系统），并通过标准协议将这些资源/能力提供给客户端。下图以USB集线器为类比形象展示了MCP架构各组件的关系：

MCP角色示意图: MCP架构示意 ：主机（如Claude、ChatGPT等AI应用）通过MCP客户端连接到多个MCP服务器，每个服务器相当于一个"适配器"，将本地或远程的数据源/工具以统一接口提供给AI模型使用。 图中以USB-C扩展坞连接多种设备作比喻，其中MCP主机就像电脑，MCP客户端是其上的标准端口，MCP服务器如同不同的外设（Slack、Gmail、日历或本地文件等），都通过统一的MCP接口接入。

从架构上看，MCP主机可以同时连接多个服务器 ，每个服务器各司其职，比如一个提供文件访问，另一个提供数据库查询，第三个提供网络搜索等。主机通过内部运行的MCP客户端与这些服务器建立双向通信 。所谓双向，即不仅客户端可以请求服务器提供数据或执行操作，服务器也可以将消息（如通知或结果）推送给客户端，从而实现实时互动 。这一通信遵循MCP定义的协议规范，其底层采用JSON-RPC 2.0标准进行消息编码和交换。

JSON-RPC是一种轻量级的远程过程调用格式，使用JSON结构来表示请求和响应，具备方法名、参数和返回值等字段。这使得MCP的消息具有良好的自描述性和跨语言兼容性 。在传输层，MCP 支持多种机制：本地部署场景常用标准输入/输出（Stdio）管道进行进程间通信，而跨网络的场景则可以采用HTTP + SSE（服务器发送事件） 模式。无论使用哪种传输，双方通信都遵循相同的JSON-RPC消息格式，使协议在本地和远程环境下的行为保持一致。

2.3、通信流程

为了确保客户端与服务器的顺利协作，MCP定义了一套标准的连接初始化和消息交互流程：

    1. 当客户端首次连接服务器时，会发送一个initialize请求，其中包含自身所使用的协议版本及功能能力信息，服务器收到后回应自己的协议版本和支持的能力集合；
    1. 随后客户端再发送一个initialized通知表示确认，至此双方进入正常通信阶段。这个握手过程类似于HTTP的协议协商或gRPC的元数据交换，目的是确保双方在兼容模式下运行；

一旦初始化完成，客户端和服务器即可进行自由的信息交换，包括发送请求 （request）并等待响应 （response），或者发送不需要响应的通知 （notification）。例如，客户端可以请求服务器执行某项操作，服务器完成后返回结果；反过来服务器也能通知客户端一些事件（如有新的数据可用）而无需等待回应。连接过程中出现异常时，MCP也有统一的错误码和错误消息格式，遵循JSON-RPC的标准错误代码（如解析错误、方法未找到等）。这种严格规范的消息模型确保了不同实现之间能够清晰沟通、正确识别请求与响应，大大降低了集成出错的概率。

  • MCP定义了这些标准错误代码:
ini 复制代码 
    enum ErrorCode {
      // 标准JSON-RPC错误代码
      ParseError = -32700,
      InvalidRequest = -32600,
      MethodNotFound = -32601,
      InvalidParams = -32602,
      InternalError = -32603
    }

2.4、核心概念

资源、工具与prompt：MCP不仅规定了通信模式，还定义了几种核心概念用于抽象****表示服务器（Server）能够提供给AI模型的能力类型 ，主要包括资源（Resources）、工具（Tools）和提示词（Prompts） 三类。

  • 资源（Resources）：资源指服务器暴露出的可供读取的数据内容，用作LLM的上下文。资源通常是静态或半静态的信息 ，例如文件内容、数据库记录、知识库条目、日志文件，甚至截图、图像 等 。每个资源使用URI 进行唯一标识，可以包含纯文本或二进制数据。资源被设计为由应用控制使用 ，意味着client可以决定何时及如何让模型使用哪些资源 。不同客户端对资源的处理策略可以不同：比如Claude桌面版要求用户显式选择允许模型使用的文件；有的实现可能根据一定算法自动选取相关资源；也有可能允许AI模型主动请求需要的资源。资源提供了上下文注入的机制，模型在回答用户问题时，可以参考这些由服务器提供的外部信息，以提高答案的准确性和相关性。
  • 工具（Tools）：工具指服务器对外暴露的可执行功能 ，LLM可以通过调用工具来执行某些动作或计算。与资源不同，工具是动态操作 ，可能会更改系统状态或与外部环境交互。例如，文件系统服务器可以提供"读取文件"、"写入文件"的工具；数据库服务器提供执行SQL查询的工具；网络服务器提供HTTP请求或网络爬取的工具等等。工具通过tools/list接口向客户端公布 其可用清单，通过tools/call接口被调用并返回结果。每个工具拥有唯一名称、功能描述，以及输入参数的JSON模式schema定义（ 与langchain中定义的Tool类似） 。MCP设计工具为模型可控（model-controlled） ，意味着理论上大模型可以在对话中自主决定 调用哪个工具（这里就存在一个意图识别正确率的问题 ）并填入参数，然后由客户端代理实际调用。当然，出于安全考虑，人类往往需要在执行前确认（human in the loop）。工具机制让LLM不仅能"看"数据，还能"动手"处理任务，为构建Agent式的AI应用奠定了基础。
  • 提示（Prompts）：提示是在服务器端预定义的可复用提示模板或交互流程 。服务器可以将常用的任务流程编排成模板，供客户端选择执行，例如"代码分析""日报生成""数据趋势分析"等预设的问答流程。每个提示包含唯一名称、描述以及可选的参数列表定义 。客户端通过prompts/list接口获取服务器提供的所有提示，然后用户或应用可选择其中一个触发相应的交互。提示通常是由用户控制使用的，即需要用户明确选择或同意后才执行。它的作用相当于为AI应用提供"一键完成复杂任务"的模版，加速常见需求的实现，同时保证流程标准化。

通过资源 、工具 和提示 这三种抽象，MCP覆盖了从读取上下文 到执行操作 再到预定义工作流 的方方面面，使服务器能够全面地向AI提供能力支持。这种设计也体现了关注点分离 的原则：资源用于数据访问（读操作），工具用于动作执行（写或计算操作），提示用于引导模型完成复杂任务的脚手架。清晰的分层使开发者在实现服务器时有明确的框架可循，也方便AI客户端统一地发现并利用这些能力。例如，一个"MCP文件系统服务器"可能同时提供：若干文件作为资源、一系列文件操作（读/写/列目录）作为工具、以及一些文件管理的自动化流程作为提示。

2.5、与现有技术的类比

为了更好理解MCP的作用机制，我们可以将其与熟悉的协议和框架类比：

2.5.1、和HTTP/gRPC类比

  • 从性质上看，MCP和HTTP、gRPC 一样，都属于通信协议 ，定义了客户端与服务器间交换消息的格式和流程。HTTP采用请求-响应模式传输超文本资源，而MCP采用请求/响应/通知模式传输上下文数据和执行指令，底层基于JSON-RPC封装。
  • 可以认为，MCP是专门为AI场景设计的领域特定RPC协议 ：它内置了资源、工具等高级语义，适配LLM对上下文和操作的需求，而不像HTTP那样仅仅传输文档，也不像gRPC那样需要预先定义接口然后编译代码。MCP更加动态和开放：任何遵循协议的服务器都能接入，客户端也无需针对具体实现做特殊适配（类似于浏览器可以访问任何符合HTTP标准的网站）。同时，MCP也支持双向通信和长连接 （通过SSE等机制），这有点类似于WebSocket在HTTP之上的拓展，用于满足实时更新的需求。总的来说，MCP提供了类似HTTP/gRPC的通用消息传递框架 ，但内容格式和交互模式针对AI上下文做了优化，使之更适合模型与数据源交互这一特定用途。

2.5.2 AI Agent

  • AI Agent是一个智能系统，它可以自主运行以实现特定目标。传统的AI聊天仅提供建议或者需要手动执行任务，AI Agent则可以分析具体情况，做出决策，并自行采取行动。

  • AI Agent可以利用MCP提供的功能描述来理解更多的上下文，并在各种平台/服务自动执行任务。

2.5.3、和LangChain等框架的比较

  • LangChain、LlamaIndex等框架为开发者提供高级抽象，方便LLM与工具或数据源的交互，但它们是语言特定的库（多为Python），工具通常是本地函数或API封装，缺乏跨系统标准。

  • MCP则是一个开放协议，不限语言或环境，定义了AI客户端与数据源服务器的通用通信标准。LangChain可通过MCP扩展工具调用，从自定义函数转为标准服务调用，减少开发工作量。MCP的标准化促进系统协同，允许共享统一服务，许多框架（如LangChain、OpenAI Agents SDK）都开始支持MCP。MCP作为通用底座，通过标准接口连接数据源和AI应用，梳理AI生态，促进互操作与可持续发展。

2.5.4、Function Calling

  • Function Calling指的是AI模型根据上下文自动执行函数的机制。

  • Function Calling充当了AI模型与外部系统之间的桥梁，不同的模型有不同的Function Calling实现，代码集成的方式也不一样。由不同的AI模型平台来定义和实现。

如果我们使用Function Calling，那么需要通过代码给LLM提供一组functions，并且提供清晰的函数描述、函数输入和输出，那么LLM就可以根据清晰的结构化数据进行推理，执行函数。

Function Calling的缺点在于处理不好多轮对话和复杂需求，适合边界清晰、描述明确的任务。如果需要处理很多的任务，那么Function Calling的代码比较难维护。

三、MCP在实际场景中的应用与优势

3.1、场景：使用MCP协议重构问答

上图就是问答服务的早期的整体架构示意图，下边我们就尝试使用MCP协议来重构问答应用

目的 ：把现有"Python → Java问答"单体链路，重构为MCP标准化插件架构

3.1.1、如何把现有问答服务重构成MCP架构？

  1. 顶层Host（会话编排层）
  • 继续由Python服务承担意图识别、用户上下文管理（部分也是由java应用完成）、Prompt组装。
  • 在内部嵌入MCP Client ，把"调用Java问答接口"改为调用MCP Server的 traffic_doc_qa 工具（ 此时之前的java服务变成了一个MCP协议找中的server ） 。
  1. 能力服务器层（MCP Server）
    1. 将Java问答服务 改造成纯Server ：对外只暴露一个或少量工具（如traffic_doc_qa）。
    1. Java服务可升级为"二级Host"，内部再用Client调用下边的各类小server（以Http接口的形式对外暴露）：
    • DocumentIngest Server：PDF/Word/Excel解析、切分；
    • Embedder Server：文心、tao‑8k或其他向量化；
    • VectorStore Server：ES KNN / Milvus；
    • Rerank Server：重排模型；
    • LLM Server：大语言模型推理；

3.1.2、角色映射表

现有组件 在MCP中充当的角色 说明
Python意图识别/编排服务 Host (对话调度)+ Client (call工具) 拥有会话状态，嵌入Client与下游通信
Java问答服务 Server （至少），可作为Host（向下再拆） 暴露traffic_doc_qa；内部流程不变
ES向量检索 Server（如VectorStore Server） 由Java Host通过 Client 调用
tao‑8k Embedding Server (Embedder Server) 同上
Rerank模型 Server (Rerank Server) 同上
LLM推理 Server (LLM Server) 可是本地模型或第三方API

3.1.3、关键改造步骤

3.1.3.1、Host改造（Python/Java）示例：
shell 复制代码 
    # Python侧
    pip install modelcontextprotocol
Python 复制代码 
    import asyncio
    from mcp.host import Host           # MCP官方Python SDK
    from mcp.client import Client       # <<< 重点：Host内部持有Client

    LLM = LLM(api_key="sk-...")  # ① 负责意图识别 + 回复润色

    class QAPrimaryHost(Host):
        """
        顶层Host：负责
            * LLM调用/意图识别
            * 根据模型决策调用MCP工具
            * 聚合streaming结果并回写给前端
        """
        def __init__(self):
            super().__init__(name="qa_host_python", version="0.1.0")
            # ② 注册一个面向Java Server的Client
            self.java_client = Client(
                server_id="java_qa_server",
                transport="http",              # 支持http/stdio/sse
                url="http://localhost:8080/mcp" # <<< 重点：Java Server暴露的端点
            )
            self.register_client(self.java_client)  # <<< 重点

        async def handle_user_query(self, user_query: str, stream_cb):
            """
            对接SSE。示例里省略权限校验、安全过滤等细节
            """
            # 1) 调LLM做意图识别 / 参数抽取
            intent = await self._call_intent_llm(user_query)
            # 2) Host根据intent选择要调用的MCP工具
            #    这里假设Java Server暴露了名为vector_qa的工具
            async for chunk in self.java_client.invoke(
                    tool="vector_qa",           # <<< 重点：工具名
                    arguments=intent,           # {"query": xxx, "top_k": 5}
                    stream=True):               # MCP Streaming
                await stream_cb(chunk)          # 3) Streaming 回用户

        async def _call_intent_llm(self, query: str) -> dict:
            rsp = await LLM.chat.completions.create(
                model="xxxx",            # 任意支持函数调用/工具选择的模型
                messages=[{"role": "user", "content": query}],
                temperature=0.1
            )
            # 简化处理 -- 假设模型直接输出 JSON
            return rsp.choices[0].message.content_as_json()

    # ---- 启动 Host -------------------------------------------------------------
    if __name__ == "__main__":
        host = QAPrimaryHost()
        host.run_http(port=9001)               # Host本身可选择不暴露MCP，直接对接前端
  • Client握手 ：initialize → initialized
  • 调用工具 ：tools/call
3.1.3.2、通信过程

在上边介绍时我们已经简单讲了一下MCP协议的通信协议，下边以及问答服务中，python服务（Host & Client端）与java服务（Server端）的通信过程，这些通信过程对于开发者来说是透明的，在MCP官方的SDK中已经封装好了。

sequenceDiagram autonumber participant H as Python Host participant C as MCP Client (mcp‑py) participant S as Java Server (mcp‑java) H->>C: invoke(tool="vector_qa", args) Note over C,S: SDK 封装以下JSON‑RPC流程 C->>S: initialize(params){jsonrpc=2.0} ① S-->>C: initializeResult(capabilities) ② C->>S: initialized{} (进入业务阶段) ③ C->>S: tools/invoke{id, tool, args} ④ S-->>C: /progress (begin) ⑤ S-->>C: /progress (report 1) S-->>C: /progress (report 2) ... S-->>C: invokeResult{id, result} ⑥ C-->>H: Streaming chunks ⑦
3.1.3.2、能力服务器封装
能力 改造要点 示例接口
文档接入 (DocumentIngest Server) - 解析格式识别- 法规PDF/word ：章节/段落切分- Excel网点：Sheet+单元格转Html tools/call: ingest_document{"filepath":"xxx","doc_type":"law_pdf"}
Embedding (Embedder Server) 封装tao‑8k/文心/OpenAI ；多模型共存 tools/call: embed{"texts":[...],"model":"tao-8k"}
向量****库 (VectorStore Server) 封装ES KNN；未来可换Milvus tools/call: search_knn{"vector":[...],"topk":10}
Rerank (Rerank Server) 传入query+候选段落，返回重排列表 tools/call: rerank{"query":"...","candidates":[...]}
LLM (LLM Server) 本地或云端模型；支持tool调用格式 tools/call: complete{"prompt":"...","model":"claude-3"}
3.1.3.3、Host完整链路
  1. 意图识别 → 选traffic_doc_qa
  2. 调Embedder生成query vector
  3. 调VectorStore召回段落
  4. 调Rerank得到Top N
  5. 组装Prompt → 调LLM Server生成回答；
  6. （可选）调Safety Server过滤；
  7. 将答案返回用户；

改造后的流程示意图：

flowchart TD subgraph 用户侧 U["用户请求"] end  subgraph Host服务 direction TB parse["1. 解析用户意图"] llm_in["2. 调用大模型"] llm_out["3. 大模型返回"] client["4. MCP Client"] orchestration["5. 聚合各方结果"] respond["6. 返回用户"] end  subgraph MCPServers DOCQA["Java Server
traffic_doc_qa"] INGEST["DocumentIngest
Server"] EMBED["Embedder
Server"] VEC["VectorStore
Server"] RE["Rerank
Server"] LLM["LLM
Server"] DB["数据库 Server"] end  U --> parse parse --> llm_in llm_in --> llm_out llm_out --> client client --> DOCQA client --> DB DOCQA --> INGEST DOCQA --> EMBED DOCQA --> VEC DOCQA --> RE DOCQA --> LLM DOCQA --> client DB --> client client --> orchestration orchestration --> respond respond --> U
3.1.3.4、原方案 vs MCP优劣对比
维度 现行单体链路 MCP 标准化架构
接口一致性 Python→Java调REST/Http long polling；内部多套风格 全链路JSON‑RPC + 统一错误码
扩展能力 新增数据源需多处Glue代码 部署新Server，Host自动发现
可维护性 模块耦合，升级风险高 插件化，升级/替换互不影响
多模型兼容 更换Embedding/LLM需改业务逻辑 换模型 = 换Server，实现解耦
安全治理 各模块自管权限、日志 Host或Gateway统一审计/拦截
学习成本 Dev需掌握多套SDK 只需学习一次MCP协议 & SDK
初始改造量 √ 零 需包装Server + 嵌入Client（一次性）

3.2、场景2：基于地图的路径规划

下边我们再以较为常见的"路径规划"服务为例来说明当我们遵循MCP协议时，其实现路径与传统落地方案之间的差异，从而更加能够看出引入该协议后对开发者的效率提升。

3.2.1、目前常见实现方式

3.2.1.1、实现逻辑示意图：

flowchart LR U["示例对话：
"请帮我规划从百度大厦到百度科技园的路线""]  subgraph Backend[应用后端] IR["意图识别
& 参数抽取"] --> MAP_A["地图厂商A · 路线API"] IR --> MAP_B["地图厂商B · 路线API"] IR --> MAP_C["地图厂商C · 路线API"] MAP_A --> MERGE MAP_B --> MERGE MAP_C --> MERGE MERGE["结果解析
& 格式统一"] --> LLM["大模型
生成回答"] end U <-->|自然语言交互| LLM
  1. 对接多家地图接口
  • 地理编码 、地点检索 、路径规划 、IP定位 、实时路况......
  • 每家厂商（百度、高德等）都有各自的REST或gRPC协议、鉴权、限流策略、返回字段格式。
  1. 意图识别 & 参数抽取
  • 识别用于的意图是路径规划，然后调用LLM识别「起点」「终点」等。
  1. 接口调用 & 结果拼装
  • 针对不同API写各自的调用封装；
  • 将多源返回JSON解析为统一结构。
  1. 大模型总结
  • 将多源结果整理成用户能理解的语言；
  • 可能还要排序、加提示（如实时拥堵信息）。

3.2.1.2、优缺点

维度 优点 缺点
灵活度 任意调用厂商特有、领先的功能（如高精度ETA、避堵算法）。 每家厂商都要单独适配，接口迭代后需同步改代码。
维护成本 可针对关键业务场景做深度定制，获得更高性能。 代码膨胀：多套鉴权/签名流程；测试、监控、告警都成倍增长。
扩展性 理论上可以随时再接入新地图。 再接入= 再写一套SDK&解析逻辑；时区、单位制等坑重复踩。
大模型上下文 LLM可直接看到最原始API返回，信息最全。 上下文噪声大；不同厂商字段不一致，prompt要大量if-else处理

3.2.2、基于统一的MCP协议

3.2.2.1、实现逻辑

sequenceDiagram participant User as 用户 participant Host as LLM Host
(Cursor/Claude) participant LLM as 大模型  box "官方 Server 封装" participant MCP as MCP Server
(baidu-maps) participant BMAPI as 百度地图原生API end  User->>Host: 「请帮我规划从百度大厦到百度科技园的路线？」 Host->>LLM: 解析用户意图 LLM-->>Host: 意图 + 参数{origin, destination} Host->>MCP: mcp.routePlan{origin, destination} MCP->>BMAPI: /directionlite/v1?origin=...&destination=... BMAPI-->>MCP: JSON(route_result) MCP-->>Host: mcp.response{schema="route_result", ...} Host->>LLM: 根据route_result生成自然语言回答 LLM-->>Host: 自然语言回答文本 Host-->>User: 汇总路线 + 语言回答
  1. 选用厂商提供的MCP Server
  • 例如「baidu‑maps」「高德‑maps」「google‑maps」。
  1. 部署MCPServer
  • 多数官方已打包为Docker或pip包；
  • 统一暴露POST/mcp或WebSocket流式接口。
  1. Host中配置
  • 在cursor.json之类的设置中声明MCP Server，指定command/args/env。
  • Host在首次调用时按MCP规范自动握手、获取能力清单（schema）。

3.2.2.2、操作步骤（以Cursor为例）

  1. 开通百度地图服务
  • 云控制台申请Key，开通「路线规划」「实时路况」等模块权限。
  • 记下BAIDU_MAPS_API_KEY。
  1. baidu‑maps server部署

这里为了测试方便，采用本地部署的方式，注意mcp-server-baidu-maps依赖python3.11以上。

shell 复制代码 
    > pip install mcp-server-baidu-maps
    > python -m mcp_server_baidu_maps

mcp_server_baidu_maps是官方示例包，内部已对接百度"路线规划/地理编码/逆地理"等 API，并输出符合MCP v0.3的JSON Schema。

  1. Cursor中配置MCPServer
json 复制代码 
    {
      "mcpServers": {
        "baidu-maps": {
          "command": "/opt/homebrew/bin/python3.11",
          "args": ["-m", "mcp_server_baidu_maps"],
          "env": {
            "BAIDU_MAPS_API_KEY": "xIQehTI6IKz5T8ZJAmY6xxxxxx"
          }
        }
      }
    }
  1. 重启Cursor
  • Cmd+Shift+R或重新打开应用；
  • Cursor在启动时扫描mcpServers并启动子进程，若是配正确就会在Settings中正常出现MCP的配置，如下图：
  1. 正常交互
  • 直接在Cursor Chat里说"请帮我规划从百度大厦到百度科技园的路线"；
  • Host通过MCP调用baidu‑maps，返回统一字段route_polyline/distance/duration/steps；

3.2.2.3、优缺点

维度 优点 缺点
开发效率 一处接入，多厂商复用；只关心MCP Schema，无需关心各厂商request/response 差异。 厂商若未发布MCP Server，需要自行封装或等待生态成熟。
维护成本 协议升级 → 只升级MCP SDK；更换地图厂商只改Server地址/服务。 协议本身仍在迭代，可能遇到breaking change，需要跟进。
安全与合规 鉴权、限流逻辑集中在MCP Server层，可统一加密、审计。 MCP Server是一层新的网络组件，若配置不当可能暴露Key。
可观测性 MCP定义了标准的usage, error, latency字段，易于集中监控。 额外的转发hop增加一定的延迟，对SLA很敏感时需评估。

3.4、总结

  • 通过对比可以看到，MCP在「降低异构API碎片化」与「提升LLM接入效率」方面显著优势，但同时也引入了新的抽象层和运维需求。整体来看，对团队规模越大、接工具越多 的场景，收益越明显；而单一地图厂商 + 延迟敏感的小型应用，是否引入MCP还需根据实际权衡。

  • 根据目前的各家模型对MCP协议支持情况来看，Claude、Gemini模型已经针对MCP协议进行了专门的训练，其效果较好，其他模型目前的效果还需要评估。

四、结语

Anthropic推出的模型上下文协议（MCP）为大模型应用生态带来了一个重要的开放标准 。从MCP产生的背景痛点出发，详细阐释了其技术原理，并通过两个实际场景演示了MCP在提升开发效率、简化集成维护方面的显著优势。简而言之，MCP将AI助手从"黑箱"中解放出来，让其能安全、便捷地接入现实世界的数据和工具，为构建更智能、更实用的AI系统铺平了道路。

对于我们RD团队而言，引入MCP可以少做重复工作，多享受现成成果 ，迅速赋能AI应用；对于团队来说，标准化意味着生态协同 ，不同系统之间能够更加顺畅地互通，为未来扩展升级提供便利。当然，作为一个新兴的开放协议，MCP目前还在发展完善中，但其理念已得到业界广泛认同，开源社区也在积极贡献。我们有理由相信，随着MCP生态的成熟，开发者将能够像使用USB设备一样为AI模型即插即用地添加能力，让大模型真正成为连接一切信息与服务的智能中枢。

作为研发人员且主要工作就是大模型应用开发，所以非常有必要深入了解、学习最终掌握MCP协议。

五、外部资源

5.1、MCP Server相关网站汇总

  1. PulseMCP - MCP服务器目录：每日更新，包含超过3,860个MCP服务器，覆盖各种应用和用例。
  2. mcp.so：国内魔塔社区，刚建立不久；
  3. Glama - MCP服务器：提供生产就绪和实验性MCP服务器的详细列表，涵盖文件访问、数据库连接和API集成等功能。
  4. Awesome MCP Servers on GitHub：提供详细分类和描述，如AnyQuery支持40多个应用的SQL查询、Pipedream连接2,500个API等。内容由社区维护，适合技术用户。
  5. Model Context Protocol Servers on GitHub ：官方GitHub仓库，提供参考实现和第三方MCP服务器列表，包括AWS知识库检索、Brave搜索等。
  6. smithery.ai

5.2、SDK

六、附录（目前已经支持MCP协议的公司以及服务）

中国企业/服务

  • 阿里云百炼、高德
  • Alibaba Spring AI
  • 百度地图MCP Server

.....

美国及全球企业/服务

  • Anthropic
  • OpenAI Agents SDK
  • Google Gemini
  • Microsoft Semantic Kernel
  • Adobe 生态（社区）
  • Slack（Zapier 接入）
  • Cursor IDE
  • VS Code IDE
  • LangChain

.....

相关推荐
打小就很皮...1 小时前
使用 React 实现语音识别并转换功能
人工智能·语音识别
老朋友此林1 小时前
MiniMind：3块钱成本 + 2小时！训练自己的0.02B的大模型。minimind源码解读、MOE架构
人工智能·python·nlp
LitchiCheng1 小时前
复刻低成本机械臂 SO-ARM100 单关节控制（附代码）
人工智能·机器学习·机器人
微学AI1 小时前
大模型的应用中A2A（Agent2Agent）架构的部署过程，A2A架构实现不同机器人之间的高效通信与协作
人工智能·架构·机器人·a2a
AI视觉网奇1 小时前
MoE 学习笔记
人工智能
多巴胺与内啡肽.2 小时前
Opencv进阶操作：图像拼接
人工智能·opencv·计算机视觉
小草cys2 小时前
查看YOLO版本的三种方法
人工智能·深度学习·yolo
白熊1883 小时前
【计算机视觉】OpenCV实战项目：ETcTI_smart_parking智能停车系统深度解析
人工智能·opencv·计算机视觉
消失在人海中4 小时前
数据分析基础：需要掌握的入门知识
数据库·人工智能·数据分析
西红柿土豆丶4 小时前
基于Flask、Bootstrap及深度学习的水库智能监测分析平台
人工智能·python·深度学习·flask·bootstrap
热门推荐
01【分布式】Hadoop完全分布式的搭建（零基础）02从零安装 LLaMA-Factory 微调 Qwen 大模型成功及所有的坑03KGG转MP3工具|非KGM文件|解密音频04YOLOv8入门 | 重要性能衡量指标、训练结果评价及分析及影响mAP的因素【发论文关注的指标】05【SpeedAI科研小助手】2分钟极速解决知网维普重复率、AIGC率过高，一键全文降！文件格式不变，公式都保留的！06西电B测-计算机网络综合实验(含验收问题)07Coze扣子平台完整体验和实践（附国内和国际版对比）08苍穹外卖面试总结09DeepSeek各版本说明与优缺点分析10最新 Kubernetes 集群部署 + flannel 网络插件（保姆级教程，最新 K8S 版本）