---
title: "Resources"
description: "Expose read-only data sources as MCP resources to provide context to AI models."
canonical_url: "https://mcp-toolkit.nuxt.dev/resources/overview"
---
# Resources

> Expose read-only data sources as MCP resources to provide context to AI models.

## What are Resources?

Resources are a standardized way for MCP servers to expose **read-only data** to clients. They provide contextual information that can help AI models understand your application, such as files, database schemas, configuration, or any data accessible via a URI.

<prompt :actions="["copy","cursor","windsurf"]" description="Scaffold a new MCP resource" icon="i-lucide-package">

Create a new MCP resource in my Nuxt app using @nuxtjs/mcp-toolkit.

- Create a file in server/mcp/resources/ (e.g. server/mcp/resources/readme.ts)
- Use defineMcpResource (auto-imported) with a description
- For local files, use the file property: file: 'README.md' (URI, MIME type, and handler are auto-generated)
- For custom data, define uri and handler manually, returning { contents: <span>

{ uri, text, mimeType }

</span>

 }
- For dynamic resources, use ResourceTemplate from @modelcontextprotocol/sdk/server/mcp.js with URI variables
- Name and title are auto-generated from the filename
- Use subdirectories to auto-infer groups (e.g. resources/config/app.ts → group: 'config')

Docs: [https://mcp-toolkit.nuxt.dev/resources/overview](https://mcp-toolkit.nuxt.dev/resources/overview)

</prompt>

<callout color="primary" icon="i-lucide-lightbulb">

**Key concept**: Unlike [tools](https://mcp-toolkit.nuxt.dev/tools/overview) which are invoked directly by the AI to perform actions, resources are **application-driven**. The host application (not the AI) decides when and how to fetch and include resource content in the conversation.

</callout>

Each resource is uniquely identified by a URI (e.g., `file:///project/README.md` or `api://users/123`).

## Resources vs Tools

Understanding the difference between resources and tools is essential:

<table>
<thead>
  <tr>
    <th>
      Aspect
    </th>
    
    <th>
      Resources
    </th>
    
    <th>
      Tools
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      <strong>
        Purpose
      </strong>
    </td>
    
    <td>
      Provide context and data
    </td>
    
    <td>
      Perform actions
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        Invocation
      </strong>
    </td>
    
    <td>
      Application-driven (user or app selects)
    </td>
    
    <td>
      AI-driven (model decides to call)
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        Nature
      </strong>
    </td>
    
    <td>
      Read-only data access
    </td>
    
    <td>
      Can read and modify state
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        Control
      </strong>
    </td>
    
    <td>
      User/application controls what's included
    </td>
    
    <td>
      AI decides when to use
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        Examples
      </strong>
    </td>
    
    <td>
      Files, configs, DB schemas, logs
    </td>
    
    <td>
      Send email, create file, query API
    </td>
  </tr>
</tbody>
</table>

**When to use resources:**

- Exposing project files or documentation
- Sharing database schemas or configurations
- Providing logs or system information as context

**When to use tools:**

- Performing actions that modify state
- Executing operations the AI should decide to trigger
- Interacting with external APIs or services

## How Resources are Used

Resources follow an **application-driven** model. The typical flow:

1. **Discovery** — the host application calls `resources/list` to discover available resources.
2. **Selection** — the host displays resources in a UI (tree view, search, list) and the user (or application logic) picks which ones to include.
3. **Reading** — the host fetches the selected URIs via `resources/read`.
4. **Context inclusion** — the host injects the contents into the AI conversation as context.

<callout color="info" icon="i-lucide-info">

The AI model never directly requests resources. It's always the application that decides which resources to include based on user selection, heuristics, or automatic context detection.

</callout>

## Going further

<card-group>
<card color="neutral" icon="i-lucide-file" title="File operations example" to="https://mcp-toolkit.nuxt.dev/examples/file-operations">

Read local files as MCP resources with graceful error handling.

</card>

<card color="neutral" icon="i-lucide-wrench" title="Tools" to="https://mcp-toolkit.nuxt.dev/tools/overview">

Pair resources with actions — tools are AI-driven, resources are application-driven.

</card>

<card color="neutral" icon="i-lucide-toggle-right" title="Dynamic definitions" to="https://mcp-toolkit.nuxt.dev/advanced/dynamic-definitions">

Hide resources from anonymous clients with the `enabled` guard.

</card>

<card color="neutral" icon="i-lucide-list" title="Listing definitions" to="https://mcp-toolkit.nuxt.dev/advanced/listing-definitions">

Read your discovered catalog from your own server routes.

</card>
</card-group>

If you are new to MCP in Nuxt, start with [Tools](https://mcp-toolkit.nuxt.dev/tools/overview) — resources complement tools but follow a different discovery model.

---

- [Static & structure](https://mcp-toolkit.nuxt.dev/resources/static-and-structure)
- [Templates & handlers](https://mcp-toolkit.nuxt.dev/resources/templates-and-handlers)
- [Metadata & content](https://mcp-toolkit.nuxt.dev/resources/content-metadata-errors)
- [Organization](https://mcp-toolkit.nuxt.dev/resources/organization)


## Sitemap

See the full [sitemap](https://mcp-toolkit.nuxt.dev/sitemap.md) for all pages.