What is the key difference between `resources/read` and `resources/subscribe` in MCP?
`resources/read` is a one-shot pull of a resource's current contents; `resources/subscribe` registers for server-push notifications whenever that resource later changes.
Think of a recipe pinned to a friend's fridge. Reading it is walking over once and copying down today's version: a single trip, and you're done. Subscribing is leaving a sticky note that says 'text me whenever you change this'. Now you don't keep walking back to check; your friend pings you only when something actually changes, and then you go grab the fresh copy. Both deal with the same recipe on the same fridge. One is a single look right now; the other is a standing arrangement to be told about future edits. In MCP terms, the fridge is a server exposing a resource by URI, and your trips are the host fetching that resource for the model.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
MCP exposes three primitive kinds from a server: tools (callable, side-effectful functions), resources (read-only data addressed by URI), and prompts (parameterized templates). This question lives entirely inside the resources primitive, which is exactly the trap. Because the names read and subscribe sit next to each other, candidates reach for a read versus write story, or a binary versus text story. Neither is right.
The real axis is interaction model. resources/read is a one-shot pull of a resource's current state. resources/subscribe is a standing registration that asks the server to push a notification whenever that same resource changes. Same data, same read-only semantics, two different ways of staying current.
This deep dive walks the resources primitive, the precise mechanics of each method, the notification flow that ties subscriptions together, and the production tradeoffs that decide which one you actually reach for.
The resources primitive in one paragraph
A resource is application-controlled, read-only context that an MCP server exposes to a host, identified by a URI. The scheme is free-form: file:///project/src/main.py, postgres://db/orders/recent, or a custom scheme a server invents. Servers can also advertise URI templates such as file:///{path}, which describe a parameterized family of resources rather than enumerating every concrete URI up front.
The word read-only is load-bearing. Reading a resource never mutates server state, which is the cleanest line separating resources from tools. A tool call like send_email has side effects and usually wants user approval. Reading a file resource does not.
The other load-bearing phrase is application-controlled. The host decides which resources to surface into the model's context, unlike tools, where the model itself decides to invoke. That control point is why resources fit paging large context without a tool round-trip per fetch.
In practice the lifecycle of a resource has two distinct phases, and the question's two methods straddle the second. First the host discovers what exists, either by calling resources/list to enumerate concrete URIs or by reading the URI templates the server advertised. Then the host actually consumes a resource. Consumption is where resources/read and resources/subscribe come in: read pulls the bytes once, subscribe arranges to be told when those bytes change. Keeping discovery separate from consumption in your head stops you from confusing list_changed (the catalog changed) with updated (one resource's contents changed), a distinction the rest of this deep dive leans on heavily.
Situations where this technique stops working.
2–4 min · Everything important, quickly.
| Aspect | resources/read | resources/subscribe |
|---|---|---|
| Interaction model | One-shot request-response | Standing registration plus push |
| Who initiates updates | Host pulls each time | Server pushes on change |
| Returns contents | Yes, current state directly | No, sends an updated notification only |
| Freshness mechanism | Poll again | Wait for notification, then read |
| Capability needed | Core resources support | Server must advertise subscribe |
Real products, models, and research that use this idea.
- A filesystem MCP server exposes a log file as a resource; the host subscribes and re-reads only when new lines land, instead of polling on a timer.
- Claude Desktop and Claude Code connect to MCP servers over stdio, where a persistent connection makes resource subscriptions practical.
What an interviewer would ask next. Try answering before peeking at the approach.
QHow does the host learn the new contents after a resources updated notification arrives?
The notification carries the URI, not the payload; the host issues a fresh resources/read for that URI to pull the changed contents.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Guessing the split is binary versus text, or read versus write. Both methods target the same read-only resource; the real axis is one-shot pull versus standing push.
60 second bullets to scan on the way to the call.
Why both methods act on read-only resources, not a read versus write split
What resources/read returns and when it goes stale
Primary sources. Browse if you want the original framing.
Same topic, related formats. Practice these next.