Resource Provider

The provider must implement the resources/list method to return a complete catalog of available resources. Each entry includes:

• Resource URI: A unique identifier (e.g., file:///docs/report.md, db://customers/123).
• Name & Description: Human-readable metadata for client display.
• MIME Type: Declares the content format (e.g., text/markdown, application/json). This allows clients to dynamically discover what data is accessible without prior configuration.

When a client requests a specific resource via its URI using the resources/get method, the provider must return the resource's metadata envelope. This envelope contains the declared name, description, MIME type, and may include other annotations. Crucially, it does not initially contain the full resource contents, enabling efficient browsing and context selection before a full data transfer is requested.

Upon a client's explicit resources/read request for a specific URI, the provider is responsible for fetching and returning the actual data payload. This involves:

• Data Retrieval: Accessing the underlying data source (filesystem, database, API).
• Formatting: Ensuring the output conforms to the declared MIME type.
• Error Handling: Returning appropriate JSON-RPC error codes for missing resources or access failures. The contents are then injected into the AI model's context window.

For structured data resources, the provider should define and advertise a JSON Schema via the resource's metadata. This schema acts as a contract, specifying the expected shape, data types, and required fields of the resource's contents. Clients or orchestration layers can use this schema for pre-emptive validation, ensuring the data is usable by downstream tools or prompts before it is injected into a model's context.

Advanced Resource Providers can implement the optional resources/changed notification. This allows the server to proactively inform connected clients when a resource's contents have been updated (e.g., a database record modified, a log file appended). Clients can then choose to re-read the resource, ensuring the AI agent operates on the most current data. This is critical for real-time monitoring or dashboard applications.

The provider enforces logical boundaries and access rules. Key responsibilities include:

• URI Namespacing: Designing a coherent URI scheme (e.g., git://repo/branch/path) to avoid collisions.
• Scope Enforcement: Respecting client permissions or authentication context to determine if a requested resource is accessible.
• Resource Lifecycle: Managing the creation, caching, and cleanup of resource representations, especially for dynamically generated content.

A Tool Provider is the complementary server-side component to a Resource Provider. While a Resource Provider serves static or dynamic data objects, a Tool Provider defines and executes actionable functions. It is responsible for:

• Registering available tools with their input schemas.
• Containing the handler logic that runs when a tool is invoked.
• Returning structured results or errors to the client.

Together, Resource and Tool Providers form the two primary capability interfaces of an MCP server, exposing data and actions, respectively.

An MCP Server is the overarching process that hosts one or more Resource Providers and Tool Providers. It acts as the standardized gateway between AI applications and external systems. Its key responsibilities include:

• Implementing the MCP protocol over a specified transport (e.g., stdio, SSE).
• Managing lifecycle and connections for all its providers.
• Handling JSON-RPC messages for listing, reading, and invoking.
• Performing initial capability negotiation with connecting clients.

A Resource Provider operates within an MCP server, which provides the networking and protocol framework.

A Resource URI (Uniform Resource Identifier) is the unique address for a specific piece of data served by a Resource Provider. It functions as a primary key within the provider's namespace. Critical characteristics include:

• It must be a stable identifier that clients can cache or reference.
• It often follows a hierarchical scheme (e.g., file:///docs/report.md, db://customers/12345).
• The Resource Provider uses the URI in the list and read requests to locate and return the correct resource's contents and metadata.

URIs enable precise, deterministic access to resources, forming the basis of the client's data retrieval model.

JSON-RPC is the lightweight remote procedure call protocol that forms the messaging layer of MCP. All communication between a client and a server—including interactions with a Resource Provider—uses this format. Key aspects are:

• Messages are JSON-encoded and consist of requests, responses, and notifications.
• The core methods a Resource Provider responds to are resources/list, resources/read, and resources/subscribe.
• It provides a structured way to convey parameters, results, and error codes.

A Resource Provider's interface is fundamentally defined by the specific JSON-RPC methods it implements.

Schema Validation is the programmatic process of ensuring data conforms to a defined structure. While more critical for Tool Providers (validating inputs), it is also relevant to Resource Providers in advanced use cases:

• A Resource Provider can use JSON Schema to describe the expected structure of a resource's contents if it's JSON data.
• This allows clients to understand the data model of a resource before parsing it.
• For resources created or modified via tools, validation ensures integrity between the provider's data and the tool's output.

It is a key mechanism for maintaining data consistency and interface reliability across the MCP ecosystem.

A Context Directory is the client-side registry or management system that tracks available MCP servers and their capabilities. From the perspective of a Resource Provider:

• The client discovers the provider through the directory via server registration.
• The directory caches the list of resources and tools each server's providers offer.
• It manages the connection pooling and lifecycle to the server hosting the provider.

This client-side abstraction is what allows an AI application to seamlessly interact with multiple Resource Providers from different servers as a unified source of dynamic context.