What is the key difference between resources/read and subscriptions/listen in MCP?
resources/read is a one-shot pull of a resource's current contents; subscriptions/listen 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). Both methods serve the resources primitive. Because reading and subscribing sit next to each other, it is tempting to 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. subscriptions/listen 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.
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 central. 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 central 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 both methods belong to 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 subscriptions/listen come in: read pulls the bytes once, subscribe arranges to be told when those bytes change. Keeping discovery separate from consumption stops you from confusing list_changed (the catalog changed) with updated (one resource's contents changed).
Situations where this technique stops working.
2–4 min · Everything important, quickly.
| Aspect | resources/read | subscriptions/listen |
|---|---|---|
| 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 local MCP servers over stdio, a persistent connection, though Claude does not yet support resource subscriptions.
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.