MCP Resource

Every MCP resource is uniquely identified by a Uniform Resource Identifier (URI) within the server's namespace. This URI acts as a permanent, addressable handle that clients use to request the resource's contents. The URI scheme is defined by the server (e.g., file://, db://, api://) and provides a hierarchical structure for organization.

• Example: file:///project/docs/spec.md or github://issues/open#123
• Key Property: URIs are immutable for the lifetime of the resource. If the underlying data changes, the same URI returns the updated content.

Resources are described by a fixed set of metadata fields provided by the server, which clients use for discovery and understanding.

• name: A human-readable label for the resource (e.g., "Quarterly Sales Report").
• description: A plain-text explanation of the resource's content and purpose.
• mimeType: The Multipurpose Internet Mail Extensions (MIME) type that declares the content's format (e.g., text/markdown, application/json, image/png). This tells the client how to interpret the data.
• This metadata is returned when a client lists available resources or requests details, enabling intelligent context selection.

The core MCP resource protocol is fundamentally read-only. Clients can request (resources/list) and fetch (resources/read) resource contents, but cannot create, update, or delete resources through standard resource calls. This design enforces a clear separation of concerns:

• Servers are the authoritative source and manage the lifecycle of data.
• Clients are consumers that retrieve context on-demand.
• Modification of underlying data must be performed through MCP Tools, which are separate, executable functions. This ensures state changes are explicit, auditable, and validated.

A resource's content can be either static or dynamically generated at read-time, abstracted from the client.

• Static Resources: Reference fixed data, like a file on disk or a cached API response. The URI consistently returns the same content until the source is externally updated.
• Dynamic Resources: Are computed upon each read request. Examples include:
  • stock://price/TSLA (fetches live price)
  • db://query/results (executes a parameterized query)
  • server://metrics/cpu (returns current system load)
• The client interacts with both types identically via the resources/read call, simplifying the architecture.

Through the mimeType metadata and protocol design, MCP resources natively support both text and binary data formats.

• Text Resources: Use MIME types like text/plain, text/markdown, application/json. Their contents are transmitted as strings in JSON-RPC messages.
• Binary Resources: Use MIME types like image/png, application/pdf, audio/mpeg. The MCP protocol encodes binary data using Base64 when transmitting over JSON-RPC. The client is responsible for decoding the Base64 string based on the mimeType.
• This allows the protocol to handle a vast range of contextual data, from code snippets and configuration files to diagrams and audio clips.

Resources are integrated into the broader MCP ecosystem through specific JSON-RPC methods and lifecycle events.

• Discovery: Client calls resources/list to get a catalog of available URIs and their metadata.
• Reading: Client calls resources/read with a URI to fetch the actual content.
• Notifications: Servers can send resources/updated or resources/removed notifications to subscribed clients, enabling real-time context awareness when resources change.
• Relationship to Tools: While distinct, resources and tools are complementary. A resources/read call might fetch a configuration file (resource), whose contents are then used as parameters for a subsequent tools/call to execute an action.

An MCP Server is the process that implements the Model Context Protocol to expose resources, tools, or prompts. It acts as the standardized interface between an AI application and external data or functionality. The server is responsible for:

• Hosting Resource Providers and Tool Providers.
• Responding to client requests for resource metadata and contents.
• Executing Tool Handlers when a tool is invoked.
• Managing the lifecycle and access to the data objects it exposes.

A Resource URI (Uniform Resource Identifier) is a unique string that identifies a specific resource within an MCP server's namespace. It functions as a precise address that a client uses to request the resource's contents. Key characteristics include:

• It follows a hierarchical structure, often resembling a file path (e.g., file:///docs/report.md, db://records/customer_123).
• The URI scheme can indicate the type of resource or its origin.
• It enables the client to request a specific data object without ambiguity, forming the basis for the mcp:// protocol's addressing system.

Context Injection is the critical process where an MCP client dynamically inserts the contents of retrieved resources (or tool results) into a language model's context window. This is the primary value of an MCP Resource. The process involves:

• The client reading the resource's contents via its URI.
• Formatting the data (text, JSON, etc.) along with its metadata (name, description, MIME type) into a structured context message.
• Appending this context to the model's prompt, thereby grounding its responses in the freshly retrieved, external data.
• This creates a Dynamic Context as opposed to static, pre-loaded knowledge.

An MCP Transport is the underlying communication layer that facilitates message exchange between an MCP client and server. Resources are requested and delivered over this transport. Common types include:

• Stdio Transport: Exchanges JSON-RPC messages over standard input/output streams. Ideal for integrating local scripts and command-line tools.
• SSE Transport: Uses a long-lived HTTP connection with Server-Sent Events, allowing a server to asynchronously push messages. Suitable for web-based or remote servers.
• The transport handles Message Framing—delimiting individual JSON-RPC messages—to ensure reliable parsing of requests for resources and their subsequent responses.

JSON-RPC is the lightweight remote procedure call protocol that forms the messaging backbone of MCP. All communication regarding resources—including listing, reading, and notifications of changes—uses this format. Key aspects are:

• Every request from a client (e.g., resources/read) and every response from a server is a JSON-RPC message.
• It defines standard fields like jsonrpc, method, params, id, and result.
• This standardization ensures interoperability between any compliant MCP client and server, regardless of their implementation language or the transport used.

Capability Negotiation is the initial handshake process in an MCP connection where the client and server declare their supported features. For resources, this involves the server advertising the resources capability and the client indicating it wishes to use it. This process determines:

• Which protocol versions are supported.
• What types of features the server provides (resources, tools, prompts).
• The initial set of resources available to the client.
• This ensures compatibility and sets the foundation for all subsequent resource discovery and access.