Skip to main content

Resource In

Defines a resource that can be read by MCP clients. Resources are data sources (files, documents, API responses, database records) that clients can access through the MCP protocol. Resource In nodes receive read requests and trigger your automation to fetch and return the requested content.

Common Properties​

  • Name - The custom name of the node.
  • Color - The custom color of the node.
  • Delay Before (sec) - Waits in seconds before executing the node.
  • Delay After (sec) - Waits in seconds after executing node.
  • Continue On Error - Automation will continue regardless of any error. The default value is false.
info

If the ContinueOnError property is true, no error is caught when the project is executed, even if a Catch node is used.

Inputs​

  • Resource Name - The human-readable name of the resource. Example: Project README, User Profile, Sales Report.
  • Resource URI - The unique URI identifying this resource. Can be static (e.g., docs://readme) or templated (e.g., users://{id}/profile). Template variables in curly braces become query parameters.
  • Resource Description - A description explaining what the resource contains and when to use it. Helps clients understand the resource's purpose.
  • Content Type - The MIME type of the resource. Common values:
    • text/plain - Plain text
    • text/markdown - Markdown documents
    • application/json - JSON data
    • text/html - HTML content
    • text/csv - CSV data
    • application/xml - XML documents

Outputs​

  • Resource URI - The URI of the resource requested by the client (with template variables replaced by query parameters).
  • Query Parameters - An object containing query parameters extracted from the templated URI or provided by the client.

How It Works​

When a Resource In node is connected to a Listen node's resources port:

  1. Registration - The resource is registered with the MCP server at startup
  2. Discovery - Clients can discover the resource via ListResources
  3. Client Request - When a client calls ReadResource with the URI
  4. URI Matching - The server matches the URI and extracts any template parameters
  5. Triggering - The Resource In node receives the request with URI and parameters
  6. Processing - Your flow fetches or generates the resource content
  7. Response - A Resource Out node sends the content back to the client

URI Templates​

Resource URIs support template variables for dynamic resources:

  • Static URI: docs://readme - Always returns the same resource
  • Templated URI: users://{id}/profile - Client specifies id parameter
  • Multi-parameter: reports://{year}/{month}/sales - Multiple path parameters
  • Query-based: api://data?type={type}&filter={filter} - Query string parameters

Template variables are extracted from client requests and provided in the Query Parameters output.

Requirements​

  • Must be connected to a Listen node's resources port
  • Resource URI must be unique within the server
  • Content Type should accurately describe the resource format

Usage Notes​

Resource Types​

Static Resources:

  • Fixed content that doesn't change (or changes rarely)
  • Examples: README files, API documentation, configuration schemas
  • URI: docs://readme

Dynamic Resources:

  • Content that varies based on parameters
  • Examples: User profiles, database records, generated reports
  • URI: users://{userId}/profile

Template Resources:

  • Generated content using parameters
  • Examples: Customized documents, filtered data, personalized views
  • URI: templates://{template_name}?params={params}

URI Design​

  • Use descriptive scheme prefixes (docs://, users://, api://)
  • Keep URIs human-readable and meaningful
  • Use consistent naming conventions
  • Template variables should be clearly named
  • Avoid exposing internal system paths

Content Type Selection​

Choose the appropriate MIME type:

  • Text content → text/plain or text/markdown
  • Structured data → application/json
  • Web content → text/html
  • Spreadsheets → text/csv
  • Configuration → application/json or application/xml

Examples​

Example 1: Static Document Resource​

Configuration:

  • Resource Name: Project README
  • Resource URI: docs://readme
  • Resource Description: The project's README file
  • Content Type: text/markdown

Flow:

  1. Resource In receives request for docs://readme
  2. Read File node loads README.md from disk
  3. Resource Out returns the markdown content

Use Case: Provide project documentation to AI assistants.

Example 2: User Profile (Templated URI)​

Configuration:

  • Resource Name: User Profile
  • Resource URI: users://{id}/profile
  • Resource Description: User profile information by user ID
  • Content Type: application/json

Client Request: users://123/profile

Query Parameters Output:

{
  "id": "123"
}

Flow:

  1. Resource In receives request with id=123
  2. Database Query node fetches user data
  3. Format as JSON
  4. Resource Out returns user profile

Example 3: Dynamic Report Generation​

Configuration:

  • Resource Name: Sales Report
  • Resource URI: reports://{year}/{month}/sales
  • Resource Description: Monthly sales report for specified year and month
  • Content Type: text/csv

Client Request: reports://2024/03/sales

Query Parameters Output:

{
  "year": "2024",
  "month": "03"
}

Flow:

  1. Resource In receives year and month parameters
  2. Query sales database for the period
  3. Generate CSV report
  4. Resource Out returns CSV data

Example 4: API Data Access​

Configuration:

  • Resource Name: Product Catalog
  • Resource URI: api://products?category={category}
  • Resource Description: Product listings filtered by category
  • Content Type: application/json

Client Request: api://products?category=electronics

Query Parameters Output:

{
  "category": "electronics"
}

Flow:

  1. Resource In receives category parameter
  2. Call internal API or database
  3. Filter products by category
  4. Format as JSON
  5. Resource Out returns product list

Example 5: Configuration Schema​

Configuration:

  • Resource Name: Server Configuration Schema
  • Resource URI: schemas://server-config
  • Resource Description: JSON schema for server configuration
  • Content Type: application/json

Flow:

  1. Resource In receives request
  2. Load configuration schema from file
  3. Resource Out returns schema JSON

Use Case: Provide configuration schema to AI for validation and generation.

Best Practices​

  1. URI Design:

    • Use meaningful, descriptive URIs
    • Follow consistent naming patterns
    • Use appropriate scheme prefixes (docs://, api://, users://)
    • Template variables should be clearly named
    • Keep URIs concise but informative

  2. Resource Naming:

    • Use clear, human-readable names
    • Describe what the resource contains
    • Be consistent across related resources

  3. Descriptions:

    • Explain what the resource provides
    • Document required and optional parameters
    • Mention any access restrictions or requirements
    • Include examples of valid URIs

  4. Content Types:

    • Always specify accurate MIME types
    • Use standard MIME types when possible
    • Match Content Type to actual content format

  5. Parameter Handling:

    • Validate all parameters before processing
    • Provide meaningful error messages for invalid parameters
    • Document parameter formats in the description
    • Handle missing optional parameters gracefully

  6. Security:

    • Validate and sanitize all URI parameters
    • Implement access controls in your flow
    • Don't expose sensitive file paths
    • Sanitize user input to prevent injection attacks

  7. Performance:

    • Cache frequently accessed static resources
    • Implement pagination for large datasets
    • Use efficient database queries
    • Set appropriate timeouts

Common Errors and Solutions​

Error: "Resource URI already exists"​

Cause: Two Resource In nodes have the same Resource URI.

Solution:

  • Ensure each Resource In node has a unique URI
  • Check all Resource In nodes connected to the Listen node
  • Use different scheme prefixes or paths

Error: "Invalid URI format"​

Cause: URI contains invalid characters or format.

Solution:

  • Use valid URI characters
  • Ensure template variables are properly formatted: {varname}
  • Avoid spaces in URIs (use hyphens or underscores)

Error: "Missing required parameters"​

Cause: Client didn't provide required template variables.

Solution:

  • Document required parameters clearly in description
  • Validate parameters in your flow
  • Return helpful error messages via Resource Out

Tips for Effective Use​

  1. Parameter Documentation - Clearly document all URI template variables in the description
  2. Versioning - Include version in URI if resource format may change (e.g., api://v1/users)
  3. Consistency - Use consistent URI patterns across related resources
  4. Validation - Always validate parameters before processing
  5. Error Handling - Return appropriate error responses for invalid requests
  6. Testing - Test with various parameter combinations
  7. Monitoring - Log resource access for debugging and analytics
  8. Caching - Implement caching for frequently accessed static resources

Advanced Patterns​

Pattern 1: Hierarchical Resources​

docs://               (list all docs)
docs://api            (API documentation)
docs://api/endpoints  (specific section)

Pattern 2: Filtered Collections​

users://              (all users)
users://?role={role}  (filtered by role)
users://{id}          (specific user)

Pattern 3: Computed Resources​

analytics://summary?from={start}&to={end}

Dynamically compute analytics for date range.

Pattern 4: Multi-Format Resources​

reports://sales?format={format}

Return same data in different formats (json, csv, xml).

Pattern 5: Nested Resources​

projects://{project_id}/tasks
projects://{project_id}/tasks/{task_id}

Model relationships between resources.