The Model Context Protocol (MCP) provides a standardized way for servers to expose resources to clients. Resources allow servers to share data that provides context to language models, such as files, database schemas, or application-specific information. Each resource is uniquely identified by a URI.
Resources in MCP are designed to be application-driven, with host applications determining how to incorporate context based on their needs.
For example, applications could:
However, implementations are free to expose resources through any interface pattern that suits their needs—the protocol itself does not mandate any specific user interaction model.
Servers that support resources MUST declare the resources
capability:
The capability supports two optional features:
subscribe
: whether the client can subscribe to be notified of changes to individual
resources.listChanged
: whether the server will emit notifications when the list of available
resources changes.Both subscribe
and listChanged
are optional—servers can support neither,
either, or both:
To discover available resources, clients send a resources/list
request. This operation
supports pagination.
Request:
Response:
To retrieve resource contents, clients send a resources/read
request:
Request:
Response:
Resource templates allow servers to expose parameterized resources using URI templates. Arguments may be auto-completed through the completion API.
Request:
Response:
When the list of available resources changes, servers that declared the listChanged
capability SHOULD send a notification:
The protocol supports optional subscriptions to resource changes. Clients can subscribe to specific resources and receive notifications when they change:
Subscribe Request:
Update Notification:
A resource definition includes:
uri
: Unique identifier for the resourcename
: Human-readable namedescription
: Optional descriptionmimeType
: Optional MIME typesize
: Optional size in bytesResources can contain either text or binary data:
The protocol defines several standard URI schemes. This list not exhaustive—implementations are always free to use additional, custom URI schemes.
Used to represent a resource available on the web.
Servers SHOULD use this scheme only when the client is able to fetch and load the resource directly from the web on its own—that is, it doesn’t need to read the resource via the MCP server.
For other use cases, servers SHOULD prefer to use another URI scheme, or define a custom one, even if the server will itself be downloading resource contents over the internet.
Used to identify resources that behave like a filesystem. However, the resources do not need to map to an actual physical filesystem.
MCP servers MAY identify file:// resources with an
XDG MIME type,
like inode/directory
, to represent non-regular files (such as directories) that don’t
otherwise have a standard MIME type.
Git version control integration.
Servers SHOULD return standard JSON-RPC errors for common failure cases:
-32002
-32603
Example error:
The Model Context Protocol (MCP) provides a standardized way for servers to expose resources to clients. Resources allow servers to share data that provides context to language models, such as files, database schemas, or application-specific information. Each resource is uniquely identified by a URI.
Resources in MCP are designed to be application-driven, with host applications determining how to incorporate context based on their needs.
For example, applications could:
However, implementations are free to expose resources through any interface pattern that suits their needs—the protocol itself does not mandate any specific user interaction model.
Servers that support resources MUST declare the resources
capability:
The capability supports two optional features:
subscribe
: whether the client can subscribe to be notified of changes to individual
resources.listChanged
: whether the server will emit notifications when the list of available
resources changes.Both subscribe
and listChanged
are optional—servers can support neither,
either, or both:
To discover available resources, clients send a resources/list
request. This operation
supports pagination.
Request:
Response:
To retrieve resource contents, clients send a resources/read
request:
Request:
Response:
Resource templates allow servers to expose parameterized resources using URI templates. Arguments may be auto-completed through the completion API.
Request:
Response:
When the list of available resources changes, servers that declared the listChanged
capability SHOULD send a notification:
The protocol supports optional subscriptions to resource changes. Clients can subscribe to specific resources and receive notifications when they change:
Subscribe Request:
Update Notification:
A resource definition includes:
uri
: Unique identifier for the resourcename
: Human-readable namedescription
: Optional descriptionmimeType
: Optional MIME typesize
: Optional size in bytesResources can contain either text or binary data:
The protocol defines several standard URI schemes. This list not exhaustive—implementations are always free to use additional, custom URI schemes.
Used to represent a resource available on the web.
Servers SHOULD use this scheme only when the client is able to fetch and load the resource directly from the web on its own—that is, it doesn’t need to read the resource via the MCP server.
For other use cases, servers SHOULD prefer to use another URI scheme, or define a custom one, even if the server will itself be downloading resource contents over the internet.
Used to identify resources that behave like a filesystem. However, the resources do not need to map to an actual physical filesystem.
MCP servers MAY identify file:// resources with an
XDG MIME type,
like inode/directory
, to represent non-regular files (such as directories) that don’t
otherwise have a standard MIME type.
Git version control integration.
Servers SHOULD return standard JSON-RPC errors for common failure cases:
-32002
-32603
Example error: