【深度解析】MCP到底是什么，一个动画彻底搞懂！

MCP 核心价值与定位

• 本质定位：Anthropic 推出的模型上下文协议（MCP），核心是通过为外部工具“套一层标准化壳”，统一 Client 与 Server 间的通信，解决大模型调用外部工具生态割裂的问题。

• 解决痛点：传统 Function Calling 需为每个接口手写复杂的 API Schema 描述、维护成本高且存在直接暴露 HTTP 接口的安全隐患；MCP 借助 官方 SDK（如 Python 装饰器） 极大简化了工具开发与配置。

MCP 架构与通信机制

• 核心三层架构：
  

  • MCP Host / Client：容纳客户端的中介程序（如 Claude 桌面端、VS Code 的 Cline 插件）。

  • MCP Server：封装了本地或远程工具函数的服务端。

• Client 与 Server 的通信方式（基于 JSON-RPC 2.0 协议）：
  

  • stdio（标准输入/输出流）：Server 作为 Client 的子进程启动，通过 stdin/stdout 双工通信，适合同机/本地场景。

  • HTTP + SSE（Server-Sent Events）：通过建立两个路由（一个持久连接下发数据、一个接收客户端请求）实现双工通信，适合跨网络/分布式场景。

• Client 与 大模型的通信机制：
  

  • 协议未做硬性规定：MCP 规范仅约束 Client 与 Server 的通信，Client 与 LLM 的对接非常灵活。

  • 实测发现（Cline 案例）：抓包显示其未走标准的 Function Calling 参数字段，而是将包含 MCP 在内的所有工具说明以系统提示词形式直接拼接，单次消耗高达 6 万多字符（耗费大量 Token），通过 <use_mcp_tool> 等特定标签约束输出。

  • 兼容性权衡：直接塞 Prompt 的方式泛化性好，任何遵循指令能力的模型均可适配；而走原生 Function Calling 则对模型自身能力有前置依赖。

技术演进脉络

• Prompt 约定时代：纯靠 Prompt 文本描述工具与返回格式，早前模型遵循力差、解析易出错。

• Function Calling 时代：以 OpenAI 为代表，将工具描述提取为独立的 JSON Schema 结构，模型输出特定参数字段，标准化程度高但接口维护与开发繁琐。

• MCP 协议时代：通过 SDK 封装底层的 Web Server 与 Schema 构造细节，走向即插即用、统一协议的代理工具生态。