为简洁起见,本页的请求示例省略了
_meta 请求元数据(io.modelcontextprotocol/protocolVersion、io.modelcontextprotocol/clientInfo 和 io.modelcontextprotocol/clientCapabilities)。每个请求**必须(MUST)**包含必需的 _meta 字段;参见 _meta。用户交互模型
MCP 中的资源被设计为由应用驱动,由宿主应用根据它们的需求确定如何并入上下文。 例如,应用可以:- 通过 UI 元素在树形或列表视图中暴露资源以供显式选择
- 允许用户搜索和过滤可用的资源
- 基于启发式规则或 AI 模型的选择实现自动上下文纳入

能力
支持资源的服务器**必须(MUST)**声明resources 能力:
listChanged:服务器是否会在可用资源列表变化时发出通知。subscribe:服务器是否支持针对通过 subscriptions/listen 使用 resourceSubscriptions 过滤器请求的资源的、资源特定的更新通知。
listChanged 也不支持 subscribe 的服务器可以省略它:
resources 能力的服务器**必须(MUST)以当前对发起请求的客户端可用的资源集合响应 resources/list 请求。此集合可以(MAY)为空并可以(MAY)随时间变化(参见列表变更通知),但不得(MUST NOT)按连接变化或作为连接上其他请求的副作用变化。此集合可以(MAY)**按请求上出示的授权变化——例如,只返回调用方被授予的 scope 所允许的资源——因为凭据是每请求输入,而非连接状态。
协议消息
列出资源
要发现可用的资源,客户端发送一个resources/list 请求。此操作支持分页和缓存。
请求:
读取资源
要检索资源内容,客户端发送一个resources/read 请求。此操作支持缓存。
请求:
resources/read 请求的响应中返回多个资源内容。例如,服务器可以在读取一个目录资源时返回若干文件的内容。
服务器**也可以(MAY)**以一个 InputRequiredResult 响应 resources/read,以表明在资源可以被读取之前需要额外的输入。这遵循多轮往返请求机制。在重试请求时,客户端在请求参数中包含 inputResponses,以及(如果服务器提供)requestState。
或者,如果 uri 的 scheme 是 https://,客户端可以直接从 Web 获取资源。更多信息参见常见 URI Scheme 一节。
资源模板
资源模板允许服务器使用 URI 模板暴露参数化的资源。参数可以通过补全 API自动补全。此操作支持分页和缓存。 请求:列表变更通知
当可用资源列表变化时,声明了listChanged 能力的服务器**应当(SHOULD)**发送一个通知:
订阅
客户端通过发送一个subscriptions/listen 请求(其中资源 URI 列在 notifications.resourceSubscriptions 中)来订阅特定资源的变更通知。每当被监视的资源变化时,服务器就在由此产生的流上投递 notifications/resources/updated。
subscriptionId 关联和取消)参见订阅。
消息流
数据类型
Resource
一个资源定义包括:uri:资源的唯一标识符name:资源的名称。title:用于显示目的的可选人类可读资源名称。description:可选的描述icons:用于在用户界面中显示的可选图标数组mimeType:可选的 MIME 类型size:以字节为单位的可选大小
资源内容
资源可以包含文本或二进制数据:文本内容
二进制内容
注解
资源、资源模板和内容块支持可选的注解,为客户端提供关于如何使用或显示资源的提示:audience:一个数组,指示此资源的预期受众。有效值为"user"和"assistant"。例如,["user", "assistant"]表示对两者都有用的内容。priority:一个从 0.0 到 1.0 的数字,指示此资源的重要性。值为 1 表示”最重要”(实际上是必需的),而 0 表示”最不重要”(完全可选)。lastModified:一个 ISO 8601 格式的时间戳,指示资源最后修改的时间(例如"2025-01-12T15:00:58Z")。
- 基于资源的预期受众过滤资源
- 优先决定将哪些资源纳入上下文
- 显示修改时间或按新近程度排序
常见 URI Scheme
协议定义了若干标准 URI scheme。此列表并非穷尽——实现始终可以自由使用额外的、自定义的 URI scheme。https://
用于表示 Web 上可用的资源。 服务器**应当(SHOULD)**仅在客户端能够自行直接从 Web 获取和加载资源时才使用此 scheme——即,它不需要通过 MCP 服务器读取资源。 对于其他用例,服务器**应当(SHOULD)**优先使用另一个 URI scheme,或定义一个自定义的,即使服务器本身将通过互联网下载资源内容。file://
用于标识行为像文件系统的资源。然而,这些资源不需要映射到一个实际的物理文件系统。 MCP 服务器**可以(MAY)**用一个 XDG MIME 类型(如inode/directory)标识 file:// 资源,以表示没有标准 MIME 类型的非常规文件(例如目录)。
git://
Git 版本控制集成。自定义 URI Scheme
自定义 URI scheme **必须(MUST)**符合 RFC3986,并考虑上述指导。错误处理
如果所请求的资源不存在,服务器**必须(MUST)返回一个代码为-32602(Invalid Params)的 JSON-RPC 错误。服务器应当(SHOULD)**为内部错误返回 -32603。
为向后兼容,客户端**应当(SHOULD)**也接受 -32002 作为资源未找到错误,因为早期协议版本使用此代码。
服务器**不得(MUST NOT)**为一个不存在的资源返回空的 contents 数组。空数组是有歧义的——它可能意味着资源存在但没有内容,或者它根本不存在。
错误示例:
安全考量
- 服务器**必须(MUST)**校验所有资源 URI
- 对于敏感资源**应当(SHOULD)**实现访问控制
- 二进制数据**必须(MUST)**被正确编码
- 资源权限**应当(SHOULD)**在操作之前被检查
- 在提供
file://资源时,服务器**必须(MUST)**净化文件路径以防止目录遍历攻击