MCP Core Concepts

Resources

Resources represent read-only data that servers expose to clients. Unlike tools which execute actions, resources provide static or dynamic content for LLMs to use as context. While you could implement read-only tools for data access, resources give clients more control. For instance, Claude Desktop might request resources on-demand, while other clients could pre-fetch them for RAG or cache them for performance.

URI Structure

Resources are identified using URIs following the pattern [protocol]://[host]/[path]. For example:

• file:///workspace/src/main.js - Local source files that the LLM can analyze for debugging or code review

• mysql://analytics/sales/quarterly_reports - Database tables containing business metrics for analysis

• memory://context/conversation_history - In-memory storage of previous interactions or state

Resource Types

Text resources

UTF-8 encoded content like source code, configuration files, or logs. These resources are sent as plain text in the protocol, making them ideal for content the LLM needs to read and understand directly.

Binary resources

Base64-encoded data like images, PDFs, or audio files. The encoding ensures safe transport through the JSON-RPC protocol while preserving the original binary format.

Discovery Methods

Direct resources

Concrete resources exposed via resources/list with metadata. Servers return a complete list of available resources with their URIs, human-readable names, and optional metadata like file size or last modified date.

type DirectResource = {  
  uri: string;  
  name: string;  
  description?: string;  
  mimeType?: string;  
  size?: number;
}

Resource templates

URI templates (RFC 6570) for dynamic resource construction. These templates allow clients to construct valid resource URIs by filling in parameters, useful for resources that follow patterns like logs by date or database records by ID.

type ResourceTemplate = {
  uriTemplate: string;
  name: string;
  description?: string;
  mimeType?: string;
}

Key Characteristics

• Resources are application-controlled, meaning the host/user decides when to fetch them, not the LLM. This design ensures users maintain control over what data is accessed and when.

• Servers can notify clients when resources change via notifications/resources/updated. This enables real-time synchronization for dynamic content like log files or live system metrics.

• Clients can subscribe to specific resources for real-time updates. The subscription model allows efficient monitoring without constant polling.

• Multiple resources can be returned from a single read request. For example, reading a directory resource might return all files within it as separate resource objects.

Best practices

• Use clear, descriptive URIs that indicate the resource type. Good: config://app/production/database.yml, Bad: resource://1234

• Include appropriate MIME types to help clients handle content correctly. This enables clients to provide syntax highlighting, validation, or specialized rendering.

• Implement resource templates for dynamic content patterns. Templates like logs://app/{date}/errors allow flexible access to time-based or parameterized resources.

• Cache resource contents when appropriate for performance. Static resources should be cached to reduce server load, with proper cache invalidation for updates.

• Consider pagination for large resource lists. Return resources in chunks with continuation tokens to handle directories with thousands of files efficiently.

• Validate all resource URIs to prevent directory traversal attacks. Never allow URIs like file:///../../../etc/passwd without proper sanitization and access controls.