Resource URI

An MCP Resource URI is a globally unique string that identifies one specific resource. Its internal structure is opaque to the client; the client treats it as a token to request content, not as a path to parse. The server defines the URI scheme and is solely responsible for mapping it to the underlying data.

• Example: file:///etc/config.yaml or postgresql://users/12345
• Key Point: The URI's format is a contract between the server and its resources, not a filesystem path the client should interpret.

Resource URIs are organized within a hierarchical namespace managed by the MCP server. This structure allows for logical grouping and discovery via the mcp.listResources call.

• Structure: URIs often resemble paths (e.g., database://production/schemas/users).
• Discovery: Clients can list resources under a parent URI prefix to understand what's available.
• Purpose: This hierarchy provides organization without exposing implementation details, enabling servers to model complex data landscapes like database tables, API endpoints, or directory trees.

The URI's scheme (the part before ://) is a critical routing mechanism. It often dictates which Resource Provider within the server handles the request. A single MCP server can host multiple providers for different data sources.

• Example: A server might handle URIs with schemes like file:, github:, and postgresql:.
• Function: When a client requests a resource, the server uses the scheme to dispatch the call to the correct internal handler responsible for that type of data.

The primary function of a Resource URI is to serve as a key for dynamic context retrieval. When an AI agent needs specific information, the client uses the URI to fetch the exact resource contents via mcp.readResource and injects them into the model's context window.

• Process: 1. Discover URI via listResources. 2. Request content via readResource. 3. Inject result into prompt.
• Benefit: This enables agents to access real-time, proprietary, or too-large-to-prompt data on demand, grounding responses in authoritative sources.

Each Resource URI is associated with metadata returned by the server, which includes a human-readable name, description, and MIME type. This metadata is crucial for the client and the end-user to understand the resource's purpose and format before reading it.

• Standard Fields: uri, name, description, mimeType.
• Example MIME Types: text/plain, application/json, image/png.
• Use Case: A client can present a list of available resources with their names and descriptions, allowing a user or the AI itself to select the most relevant context for a task.

Resource URIs are distinct from other MCP concepts. They are for read-only data access, unlike Tools (for execution) or Prompts (for instruction templates).

• Resource (URI): file:///reports/q3_summary.md - A piece of data to be read.
• Tool: create_report - An executable function that might generate a new resource.
• Prompt: summarize_document - A template for instructing the LLM, which might use a resource's content as a variable. This separation of concerns (data, action, instruction) is a core architectural principle of MCP.

An MCP Resource is the data object identified by a Resource URI. It is a fundamental data unit exposed by an MCP server for client consumption.

• Defined by metadata: Includes a name, description, uri, and MIME type.
• Read-only interface: Clients can read or list resources but cannot directly modify them via the resource interface; modifications require tool invocations.
• Examples: A database record, a log file, a configuration setting, or the current status of a system component.

An MCP Server is the process that hosts and serves resources, making them discoverable via their URIs. It acts as the authoritative source for the resource namespace.

• Hosts the namespace: The server defines the scheme and hierarchy for all Resource URIs it exposes (e.g., file://, github://).
• Implements providers: Contains Resource Providers and Tool Providers that handle client requests.
• Manages lifecycle: Responsible for initializing connections, serving resource contents, and executing tools when invoked by a client.

JSON Schema is the standard used within MCP to define the expected structure and data types for tool inputs and, by extension, can describe the structure of resources returned by a URI.

• Validation foundation: Ensures data integrity for tool invocations and can validate complex nested resource data.
• Defines inputSchema: For tools, the schema dictates required and optional parameters. For resources, metadata can reference a schema describing the resource's JSON content.
• Enables interoperability: Provides a machine-readable contract, allowing clients to dynamically understand how to interact with resources and tools without hard-coded logic.

Context Injection is the client-side process triggered by resolving a Resource URI. The retrieved content is inserted into the LLM's context window to inform its reasoning.

• Dynamic knowledge retrieval: The client reads a resource via its URI and injects the plain text or structured data into the prompt.
• Enables grounding: Moves the AI from static, pre-trained knowledge to dynamic, real-time information from connected systems.
• Orchestrates resources: A sophisticated client may inject content from multiple URIs (e.g., a config file file:///app/config.yaml and a recent log log:///app/errors) to provide composite context for a single task.

Capability Negotiation is the initial handshake where an MCP client and server declare their supported features, including the resource schemes and patterns they support.

• Initial initialize exchange: The server advertises its capabilities, which can include the types of resources it provides (e.g., resources capability).
• Informs URI understanding: The client learns which URI schemes (like file://, sql://) are valid for this specific server connection.
• Prevents errors: Ensures the client does not waste time requesting git:// resources from a server that only provides postgres:// resources.

MCP Transport is the communication layer that carries the JSON-RPC messages containing requests for resources (by URI) and their responses.

• Stdio (Standard Input/Output): A common transport for local integration. A client spawns a server process and communicates via pipes. All URIs resolve on the local machine or within the server's execution context.
• SSE (Server-Sent Events): An HTTP-based transport for remote servers. The client connects to a remote endpoint, and resource URIs are resolved on the remote server's infrastructure.
• Transport-agnostic protocol: The Resource URI abstraction means the same URI (e.g., file:///data/report.md) can be requested over either transport; the server handles the local filesystem access.