MCP协议

原创

已于 2025-08-14 14:39:24 修改 · 2.9k 阅读

11 ·

CC 4.0 BY-SA版权

文章标签：

#人工智能 #自然语言处理

于 2025-03-12 11:03:44 首次发布

1 什么是 MCP？

MCP（Model Context Protocol，模型上下文协议）是由 Anthropic 推出的一种开放标准，旨在统一大型语言模型（LLM）与外部数据源和工具之间的通信协议。
MCP 的主要目的在于解决当前 AI 模型因数据孤岛限制而无法充分发挥潜力的难题，MCP 使得 AI 应用能够安全地访问和操作本地及远程数据，为 AI 应用提供了连接万物的接口。

1.1 MCP 与functioncall

MCP是在OpenAI的Function call和GPTs之后出现的，那么它一定是看到了Function call的开发和使用的复杂性，而且看到了GPTs的封闭和不开放性。

Function call可以说是MCP的灵感的来源和基础功能，可以理解Function call等同于工具（tools）。大模型（LLM）能够理解工具的描述和参数的规定，然后，会从一堆工具中去选择一个和几个工具来解决用户提出的问题。没有LLM能自动选择和调用工具的能力，也没有MCP这个概念的可能。这是MCP的源头和基础，不得不说，这是OpenAI的巨大原始贡献。

但是，Function call，或者 Tools 使用，对很多开发者，就不用说一般用户了，尽管能用大模型来copilot，还是很不方便，网络访问，权限控制，流程控制，错误处理，可靠性，版本维护，升级改动，等等，一大堆事情都要去编程处理。而且，对不同的应用场景，可能还需要定制化。

既然Function call这么复杂不好用，那么OpenAI提出了GPTs的概念，说白的，GPTs就类似于微信的小程序，它的底层实现，依然是基于Function call，做好的一个一个GPTs，用户可以选择使用哪一个。这儿的问题是，GPTs相当于是已经包装好的闭源应用，只能在OpenAI平台上使用，不开放，不是生态玩法（可能只是OpenAI生态）。你给OpenAI做了个GPT，对别的平台，你还得做一个，这样，对服务商，开发者，依然不方便，不利于市场拓展。

由此看到，Function call太底层，GPTs太高层，这时，就有了MCP这样处于中间层的协议或产品出来了。

2 MCP 架构

MCP 遵循客户端-服务器架构（client-server），其中包含以下几个核心概念：

MCP 主机（MCP Hosts）：发起请求的 LLM 应用程序（例如 Claude Desktop、IDE 或 AI 工具）。

MCP 客户端（MCP Clients）：在主机程序内部，与 MCP server 保持 1:1 的连接。

MCP 服务器（MCP Servers）：为 MCP client 提供上下文、工具和 prompt 信息。

本地资源（Local Resources）：本地计算机中可供 MCP server 安全访问的资源（例如文件、数据库）。

远程资源（Remote Resources）：MCP server 可以连接到的远程资源（例如通过 API）。

3 MCP Server

MCP server 是 MCP 架构中的关键组件，它可以提供 3 种主要类型的功能：

资源（Resources）：类似文件的数据，可以被客户端读取，如 API 响应或文件内容。

工具（Tools）：可以被 LLM 调用的函数（需要用户批准）。

提示（Prompts）：预先编写的模板，帮助用户完成特定任务。

这些功能使 MCP server 能够为 AI 应用提供丰富的上下文信息和操作能力，从而增强 LLM 的实用性和灵活性。

你可以在 MCP Servers Repository 和 Awesome MCP Servers 这两个 repo 中找到许多由社区实现的 MCP server。使用 TypeScript 编写的 MCP server 可以通过 npx 命令来运行，使用 Python 编写的 MCP server 可以通过 uvx 命令来运行。

3.1 Resources

3.1.1 resource类型

Resource可以是如下类型：
文件内容
数据库记录
API响应结果
图片等多媒体内容
…

Resources更多的是用于固定的资源获取，如果是一些更复杂的动态数据获取，还是需要使用Tools来实现。

协议内容
每个对象都有唯一的URI标识：[protocol]😕/[host]/[path]，例如
file:///home/user/documents/report.pdf
postgres://database/customers/schema

3.1.2 客户端获取资源

客户端获取所有资源，共有两种方式：

获取direct resources

获取资源模板，一些动态资源可以通过这种方式返回

1. 获取direct resources
// Request
{
   
   
  method: "resources/list"
}

// Response
{
   
   
  uri: string;           // 唯一标识
  name: string;          // 资源名称
  description?: string;  // 描述
  mimeType?: string;     // 资源类型
}
2. 获取资源模板，一些动态资源可以通过这种方式返回

// Request
{
   
   
  method: "resources/templates/list"
}

// Response