List Resources

​

Overview

The resources/list method returns all resources available to the authenticated user. Resources are application-controlled data sources that provide contextual information to language models.

​

Prerequisites

1. Session Initialization: Complete initialize → notifications/initialized flow
2. Authentication: Valid OAuth token or PAT with mcp.read scope
3. Session ID: Include Mcp-Session-Id header from initialization

​

Request Format

{
  "jsonrpc": "2.0",
  "id": "resources-list-123",
  "method": "resources/list",
  "params": {
    "cursor": "optional_pagination_cursor"
  }
}

​

Request Parameters

​

Response Format

​

Example Responses

{
  "jsonrpc": "2.0",
  "id": "resources-list-123",
  "result": {
    "resources": [
      {
        "uri": "pipedrive://deals/12345",
        "name": "Deal #12345 - Acme Corp Integration",
        "description": "Complete deal information including activities, notes, and stakeholder data",
        "mimeType": "application/json"
      },
      {
        "uri": "pipedrive://contacts/67890",
        "name": "Contact: John Doe",
        "description": "Contact profile with interaction history and preferences",
        "mimeType": "application/json"
      },
      {
        "uri": "pipedrive://activities/report/monthly",
        "name": "Monthly Activity Report",
        "description": "Aggregated activity metrics and performance data",
        "mimeType": "application/json"
      },
      {
        "uri": "pipedrive://files/proposal_v2.pdf",
        "name": "Project Proposal v2.0",
        "description": "Latest project proposal document",
        "mimeType": "application/pdf"
      }
    ],
    "nextCursor": null
  }
}

​

Resource URI Patterns

​

Pipedrive Resources

Our implementation uses structured URI patterns for different resource types:

​

URI Validation

Resource URIs must:

• Be valid URI format with scheme and path
• Reference accessible resources for the authenticated user
• Contain non-empty paths and identifiers
• Follow consistent naming patterns

​

OAuth Filtering Behavior

Our implementation applies OAuth-based filtering:

​

User-Specific Resource Access

• Database Permissions: Resources filtered based on user’s database permissions
• OAuth Client ID: Each client gets appropriate resource subset
• Data Ownership: Users see only resources they have access to
• Dynamic Loading: Resources loaded from database per user context

​

Access Control Validation

// Resources are filtered based on:
// 1. User's OAuth token client_id
// 2. Database resource permissions
// 3. CRM data access rights
// 4. Server configuration

​

Resource Count Expectations

• Minimum: Authenticated users get at least some resources
• Maximum: Limited by user permissions and data scope
• Consistency: Resource count remains stable across requests for same user

​

Resource Types and MIME Types

​

Supported Content Types

​

Content Processing

Resources are processed differently based on MIME type:

• JSON: Structured data ready for analysis
• PDF: Binary content requiring base64 encoding
• Text: Plain text content for direct processing
• Images: Visual content for multimodal analysis

​

Implementation Notes

​

Request ID Requirements

• Must be unique within session
• Cannot be null (enforced by our implementation)
• String or number format accepted

​

Session Management

• Mcp-Session-Id header required after initialization
• Session validates OAuth token and permissions
• Invalid session returns authentication error

​

Pagination Support

• Uses cursor-based pagination
• nextCursor provided when more results available
• Empty cursor parameter returns first page

​

Error Handling

• -32000: Authentication/session errors
• -32600: Invalid request format
• -32602: Invalid parameters

​

Performance Considerations

• Resources cached per user session
• Database queries optimized for user permissions
• Results paginated for large resource sets
• URI validation performed efficiently

​

Resource Discovery

• Resources dynamically discovered from user’s CRM data
• Available resources depend on current data state
• Resource list may change as data is added/modified
• Permissions checked in real-time

​

Subscription Support

Our implementation supports resource subscriptions for change notifications:

// After listing resources, clients can subscribe to changes
// Subscriptions are managed per session and resource URI
// Change notifications sent when subscribed resources are modified

This endpoint provides the foundation for resource discovery, enabling clients to understand what contextual data is available before calling resources/read.