协议版本: 2025-03-26
用户交互模型
MCP中的资源被设计为应用程序驱动的,主机应用程序根据其需求确定如何整合上下文。 例如,应用程序可以:- 通过UI元素(如树形视图或列表视图)公开资源以供明确选择
- 允许用户搜索和过滤可用资源
- 基于启发式算法或AI模型的选择实现自动上下文包含
然而,实现者可以通过任何适合其需求的界面模式公开资源—协议本身不强制要求任何特定的用户交互模型。
能力
支持资源的服务器必须声明resources能力:
subscribe:客户端是否可以订阅以接收有关单个资源变更的通知。listChanged:服务器是否会在可用资源列表变更时发出通知。
subscribe和listChanged都是可选的—服务器可以不支持、支持其中之一或两者都支持:
协议消息
列出资源
要发现可用资源,客户端发送resources/list请求。此操作支持分页。
请求:
读取资源
要检索资源内容,客户端发送resources/read请求:
请求:
资源模板
资源模板允许服务器使用URI模板公开参数化资源。参数可以通过补全API自动完成。 请求:列表变更通知
当可用资源列表发生变化时,声明了listChanged能力的服务器应该发送通知:
订阅
协议支持可选的资源变更订阅。客户端可以订阅特定资源并在其变更时接收通知: 订阅请求:消息流
数据类型
资源
资源定义包括:uri:资源的唯一标识符name:人类可读名称description:可选描述mimeType:可选MIME类型size:可选大小(字节)
资源内容
资源可以包含文本或二进制数据:文本内容
二进制内容
常见URI方案
协议定义了几种标准URI方案。此列表并非详尽无遗—实现者始终可以自由使用额外的自定义URI方案。https://
用于表示网络上可用的资源。 服务器应该仅在客户端能够直接从网络获取和加载资源时使用此方案—即,客户端不需要通过MCP服务器读取资源。 对于其他用例,服务器应该优先使用另一个URI方案,或定义一个自定义方案,即使服务器本身将通过互联网下载资源内容。file://
用于标识行为类似文件系统的资源。然而,资源不需要映射到实际的物理文件系统。 MCP服务器可以使用XDG MIME类型(如inode/directory)来标识file://资源,以表示没有标准MIME类型的非常规文件(如目录)。
git://
Git版本控制集成。错误处理
服务器应该为常见失败情况返回标准JSON-RPC错误:- 资源未找到:
-32002 - 内部错误:
-32603
安全考虑
- 服务器必须验证所有资源URI
- 应该为敏感资源实施访问控制
- 二进制数据必须正确编码
- 在操作前应该检查资源权限