MCP has tools, resources, and prompts. What makes a resource different from a tool?

Attempt it

A resource is read only data the server exposes to the host, identified by a URI (for example file:///path/to/doc, postgres://table/rows). The host, not the LLM, decides when to pull or subscribe to a resource and how to inject the content into the model's context. Resources are application controlled and side effect free. Tools are model initiated and may have side effects. The two primitives exist because read only data and actions that change state deserve different invocation patterns and different policy gates.

Your answer

**A resource** is one of the three primitives an MCP server can expose, alongside tools and prompts. It represents a piece of read only data: a file, a database row, a web page, anything the server wants to make available for the model to see. The core properties are read only and host pulled. **Read only** means there is no write operation in the resource API by design; resources cannot modify anything. **Host pulled** means the host application decides when to fetch a resource and what to include in the model's context. The model never emits 'please read resource X'; the host makes that decision. Each resource has a URI that identifies it. `file:///path/to/doc.md` points at a local file. `postgres://schema/table/rows` points at database content. Servers define their own URI schemes for whatever data they expose. The lifecycle is small. The client calls `resources/list` to discover available resources. The host picks one and calls `resources/read` to fetch the content, which then gets injected into the conversation. Optionally the host can subscribe to a resource with `resources/subscribe` and receive a notification when the data changes. The contrast with tools is the anchor: tools are model invoked and may cause side effects; resources are host pulled and strictly read only.

**A resource** is a piece of read only data exposed by an MCP server, identified by a URI, and pulled by the host (not the model) for inclusion in the model's context. Resources sit alongside tools and prompts in the three primitive families MCP servers expose. **Tools** are model invoked and may have side effects. **Resources** are host pulled and strictly read only. **Prompts** are user invoked parameterized templates. The three exist because three distinct invocation patterns mattered enough to standardize separately, and resources own the read only data slot. Each resource is identified by a URI. The URI scheme tells the host what kind of data it points at: `file:///` for filesystem paths, `postgres://` for database content, `https://` for web pages, and server specific schemes for everything else (a GitHub server might expose `github://owner/repo/issues/42`). Servers also support URI templates with parameters when the resource set is generative rather than enumerable: a Postgres server can advertise `postgres://{table}/rows` instead of listing every table individually. The lifecycle has three JSON-RPC methods. **resources/list** returns available resources or templates. **resources/read** fetches the content of a specific URI as one or more content blocks. **resources/subscribe** registers interest in updates; when the data changes, the server sends `notifications/resources/updated` and the host can re fetch. The model never picks a resource. The host decides when to fetch and what to inject. This deliberate asymmetry keeps the model from accidentally exfiltrating or modifying data through the resource layer; when you want the model to act, use tools instead.

Quick reference

TL;DR

A resource is read only, URI identified data that the host (not the model) pulls and injects into context. Tools are model invoked and may have side effects; resources inform without acting.

Memory aid

Sign in for the mnemonic that makes this stick. See Pro pricing.

Easy to grasp

Think of the AI app as someone with a library card. The librarian (the MCP server) keeps a catalog of documents, each with a unique address like a call number. When the app decides the model needs to see a document, the app goes to the librarian and asks for it. The model never walks to the shelves itself; only the app does. And nothing the app does to a document changes it: there is no write back, no edit, no delete. Resources are how MCP lets a server share read only context with the model without giving the model the keys to modify anything. Files, database rows, web pages, log snippets: any blob of data that should be read but never changed through this channel can be a resource.

Key concepts

Resource URI Host Application Tool

Detailed answer & concept explanation

~7 min read

Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.

Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example.

Sign in for 5 free unlocks/day or go Pro for unlimited. See Pro pricing.

Quick scan · 2–4 min

Everything important, quickly.

5 min: define resources as read only and host pulled, describe URI identification and templates, name the three JSON-RPC methods (list, read, subscribe), distinguish resources from tools and prompts on invocation and side effect axes, and name three concrete examples from real servers.

Real-world examples

Real products, models, and research that use this idea.

Filesystem server exposes files under configured roots as `file:///path` resources; the host can read any file the server is allowed to see and inject it into conversation context.
Postgres and SQLite servers expose table contents as `postgres://` resources, often using URI templates for browsing schemas and tables without listing every row.
GitHub server exposes issues, PRs, and file contents at specific git refs as URI addressed resources for read only inspection alongside its side effecting tools.
Memory server exposes user stored notes as resources, letting the host include relevant snippets in the conversation without giving the model direct invocation ability.
Sentry server exposes recent issue details and stack traces as resources so the model can read diagnostic information without the host calling a tool first.

Interviewer follow-ups

What an interviewer would ask next. Try answering before peeking at the approach.

QWhy are resources host pulled and not model invoked?

Sign in or go Pro to see the approach for this follow-up.

QWhat is the difference between a resource URI and a URI template?

Sign in or go Pro to see the approach for this follow-up.

QHow does resource subscription work, and when is it useful?

Sign in or go Pro to see the approach for this follow-up.

Don't say this

Red flags and common mistakes that signal junior thinking. Click to expand.

Most common mistake

Believing the model invokes resources directly. The host pulls resources and decides when to inject the content; the model only sees what the host chose to include.

Sign in or go Pro to see all red flags and common mistakes. See Pro pricing.

60-second cheat sheet

The night-before-the-interview bullets. Scan these on the way to the call.

Sign in for 5 unlocks/day or go Pro for unlimited revision sheets. See Pro pricing.

References

Primary sources. Skim if you want the original framing.