协议版本: 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类型标识file://资源,例如inode/directory,表示没有标准MIME类型的非普通文件(如目录)。
git://
Git版本控制集成。错误处理
服务器应该为常见失败情况返回标准JSON-RPC错误:- 资源未找到:
-32002 - 内部错误:
-32603
安全考虑
- 服务器必须验证所有资源URI
- 对敏感资源应该实现访问控制
- 二进制数据必须正确编码
- 操作前应该检查资源权限