为什么说 MCP 的爆发是必然：Function Calling vs MCP

MCP：MCP 是协议类似 Type-C，各个厂家再去具体的生产和制造。

Function Calling：Function Calling 是一种能力。

Function Calling是OpenAI为自家模型设计的工具，最适合需要快速接入OpenAI生态的场景。虽然其核心思想（让大模型调用外部函数/API）被其他厂商借鉴 ，但各家实现方式不同，缺乏统一标准，这正是MCP应运而生的原因。

图片来源: Norah Sakal

MCP 在 2024 年 11 月推出的，刚推出时并没有激起太大的水花。

而在 Claude 公司的大力推广下，及今年在纽约举行的 AI 工程师峰会对于 MCP 的讨论视频浏览量爆涨。另外就是 MCP 的开源的在开发者社区的积极推动也是它火爆的另一原因。**

一、MCP 的背景

当下的大模型确实越来越聪明，但它们本身只能靠训练时的"旧数据"做决定。

在大模型发展初期，它们虽然能处理复杂的语言任务，但无法直接调用外部系统。比如查询数据库、读取本地文件或调用在线API（这些是Function Calling和MCP出现前的情况）。

后来OpenAI推出了Function Calling ，确实引起了很大反响。Function Calling是OpenAI为自家模型设计的工具，最适合需要快速接入OpenAI生态的场景。虽然其核心思想（让大模型调用外部函数/API）被其他厂商借鉴 ，但各家实现方式不同，缺乏统一标准，这正是MCP应运而生的原因。

mcp 官网

Anthropic 在 2024 年推出了 Model Context Protocol（MCP），就是为了解决这个"接入分散"问题。MCP 定义了一套统一的 JSON-RPC 消息规范：后端服务只要实现了它，模型端就能按同样的流程发请求、拿数据、执行操作。这样一来就像插上同一个标准插座一样"即插即用"，彻底省去了为每个模型重复造轮子的麻烦。

MCP Hosts: 如 Claude Desktop、IDE 或 AI 工具，希望通过 MCP 访问数据的程序
MCP Clients: 维护与服务器一对一连接的协议客户端
MCP Servers: 轻量级程序，通过标准的 Model Context Protocol 提供特定能力
本地数据源: MCP 服务器可安全访问的计算机文件、数据库和服务
远程服务: MCP 服务器可连接的互联网上的外部系统（如通过 APIs）

二、基本概念

MCP 核心是一套基于 JSON-RPC 2.0 的消息规范，整个交互遵循"客户端-服务器"模式。

协议原语：MCP 定义了三大类"原语"

- Resources（资源），资源相当于静态数据块
- Tools（工具），资源相当于静态数据块
- Prompts（提示词模板），提示词模板是一些预设的对话或工作流程。

开源标准：Anthropic 把协议规范、示例服务器和客户端 SDK 全部开源，鼓励社区贡献新功能或适配更多后端。

通过这样的设计，任何符合 MCP 的客户端都能顺利对接任意 MCP 服务器，模型和后端的耦合度被降到最低。

三、MCP Server

MCP Server 是"能力提供方"，对外提供服务的程序。它可以是一个独立进程，也可以内嵌在现有的后端中，常见做法是：

声明原语：在代码里注册哪些资源（比如文件列表、数据库表）、工具（如发送邮件、查询天气）和提示模板。
实现逻辑：为每个原语编写处理函数，接收客户端的 JSON 请求，执行对应操作，然后按 MCP 规范生成响应。
启动监听：用标准接口（HTTP、STDIO、WebSocket 等）等待客户端连接，接收和发送 JSON-RPC 消息。

举个简单例子，如果你想让模型读某个目录下的文件，就把目录当作一个资源注册，模型发来"列出文件"的请求后，服务器遍历目录并把文件列表打包成 JSON 返回。整个过程对模型和用户来说，就是一次"普通的接口调用"，完全不用关心底层文件系统的细节。

四、MCP Client

MCP Client 是"能力使用方"，通常跑在 AI 应用或模型宿主（Host）里，负责在模型需要访问外部能力时，把请求发给服务器，并把服务器响应送回给模型。它主要做两件事：

连接管理：应用启动时，客户端根据配置命令或参数启动或连接到指定的 MCP Server。
消息转发：当模型在对话中触发某项操作（比如"告诉我今天的天气"），AI 应用把这个需求封装成 MCP 请求，由客户端转发给服务器，拿到结果后再交给模型继续生成回答。

在使用层面，用户只要在应用设置里填好"服务器启动命令"或"连接地址"，就能自动完成整个接入，期间无需手动写一行网络请求代码。

五、 Client-Server通信

传输层处理 clients 和 servers 之间的实际通信。MCP 支持多种传输机制：

Stdio 传输

- 使用标准输入/输出进行通信
- 适用于本地进程

通过 HTTP 的 SSE 传输

- 使用服务器发送事件进行服务器到客户端的消息传递
- 使用 HTTP POST 进行客户端到服务器的消息传递

所有传输都使用 JSON-RPC 2.0 进行消息交换。

六、开发流程

要把自家系统做成 MCP Server，一般遵循以下步骤：

查看官方规范：参考 modelcontextprotocol.io 或 GitHub 上的文档，了解协议细节和示例。
安装 SDK：选用 Python、TypeScript、Java 等语言的 SDK，快速引入协议支持。
注册原语：在服务器初始化代码中，声明要暴露的 Resources 资源、Tools 工具和 Prompts 提示。
编写处理逻辑：为每个原语写函数或回调，处理请求并返回符合格式的 JSON 响应。
配置启动：在配置文件或启动脚本里写明启动命令和运行参数，比如监听端口、本地路径或环境变量。
Host 集成：在 AI 应用的配置里填写启动命令或连接信息，让客户端自动加载服务。

整个过程和写一个普通的后端微服务差不多，重点在于要遵守 MCP 的消息格式和原语定义，这样才能保证不同客户端都能兼容使用。

七、调试与排错

集成 MCP 后，调试主要靠三大法宝：

MCP Inspector：Anthropic 提供的可视化工具，能模拟客户端发起请求，展示完整的 JSON-RPC 消息，方便检查请求格式、参数及响应内容。
日志打印：在服务器端打开详细日志，把每次请求的入参、处理过程和返回数据都打出来，快速定位逻辑或格式问题。
Host 端状态页：像 Claude 桌面版这类宿主应用，自带一个"服务状态"视图，可以实时看到哪些服务器在线、暴露了哪些原语，确认客户端是否正常连接。

建议先用 Inspector 单独验证每个原语，再到真实应用里做联调。遇到权限错、路径不对或协议兼容性问题，结合日志和 Inspector 提示，一般都能很快定位并修复。

我是栈江湖，如果你喜欢此文章，不要忘记点赞+关注！