Explain how URI templates are used in MCP Resources and describe the difference between a `resources/read` call and a `resources/subscribe` subscription.
URI templates let one MCP resource declaration cover a whole family of addresses; read is a one-shot pull, subscribe is a server push on change.
Think of a parking garage. Instead of printing a separate sign for every single spot, the garage posts one rule: spot B-{number}. That one pattern covers hundreds of spots without listing each. An MCP URI template works the same way: the server says file://{path} and the host fills in the blank to address any file. Now imagine two ways to check if your car is still there. You could walk down every hour and look yourself, that is a read, one fetch, done. Or you could ask the attendant to text you the moment anything changes, that is a subscribe. The attendant pushes you a message instead of you walking back over and over. Same data, but one is you pulling and one is the server pushing.
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 primitives a server can offer a host: tools, resources, and prompts. Resources are the read-only one, addressable context the host can pull and hand to the model without triggering side effects. This question lives entirely inside the resources primitive, and it has two moving parts that interviewers like to separate: how a server names a family of resources with a URI template, and how a host gets the data, by pulling once or by subscribing to pushes.
The trap is to wave at both as if they were the same mechanism. They are not. URI templates are about addressing, the shape of the name. Read versus subscribe is about transport timing, who initiates the data flow and when. A strong answer keeps those two axes distinct and shows you understand why each exists, and ideally shows where they meet in a real session.
This deep dive defines resources and contrasts them with tools, walks RFC 6570 templating with concrete examples and the operators that matter, contrasts the read and subscribe paths down to the wire messages, and closes with the capability negotiation, lifecycle, and tradeoffs a senior engineer is expected to raise. By the end you should be able to draw the two axes on a whiteboard and explain why MCP split them.
Resources, and why they are read-only
A resource in MCP is a piece of context the host can fetch and feed to the model. Each one is identified by a URI, exactly like a web address. A filesystem server might offer file:///project/src/main.py. A database server might offer postgres://public/users. The scheme tells the host which server owns the address, and the rest locates the specific item. Each resource also carries metadata: a human-readable name, an optional description, and a MIME type so the host knows whether it received text, JSON, or a binary blob.
The defining property is that resources are read-only. Fetching a resource never changes state. This is the deliberate split from the tools primitive, where calling send_email actually sends mail and run_query can mutate a table. Resources are pull-only data references; tools are side-effectful actions.
That split also drives a control distinction that interviewers love. Resources are app-controlled: the host decides what to surface and when to read, often paging large context by URI without ever asking the model. Tools are model-initiated: the model decides to call them mid-reasoning. The inclusion of a resource into context is therefore the host's call, not the model's, which is why resources are the right primitive for handing curated background data to the model while keeping the model from triggering side effects.
Mixing these up is the single most common resources mistake, so anchor on read-only and app-controlled as the first things you say. If a candidate describes a resource that writes or mutates, they have reached for the wrong primitive.
Situations where this technique stops working.
2–4 min · Everything important, quickly.
| Aspect | resources/read | resources/subscribe |
|---|---|---|
| Initiator | Host pulls | Server pushes after registration |
| Timing | Synchronous, one-shot | Ongoing until unsubscribe or disconnect |
| Returns content? | Yes, immediately | No, later via notifications/resources/updated |
| Server state | Stateless per call | Tracks subscribers per URI |
| Best for | On-demand snapshots | Live or frequently changing data |
Real products, models, and research that use this idea.
- The official MCP filesystem server exposes a file://{path} template so a host can read any file under a root without enumerating the tree.
- A Postgres MCP server advertises a postgres://{schema}/{table} template, letting the model address tables it discovers at runtime.
What an interviewer would ask next. Try answering before peeking at the approach.
QHow does a host know which resources support subscription versus only one-shot reads?
Capabilities are negotiated in the initialize handshake; the server advertises a resources capability with a subscribe flag, and a robust host degrades to periodic reads when it is absent.
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.
Calling a URI template a glob or regex. It is RFC 6570 variable expansion, and resource subscriptions notify on change rather than returning content on the subscribe call itself.
60 second bullets to scan on the way to the call.
What RFC 6570 is and why templates beat enumerating every URI
How a host expands a template into a concrete URI
Primary sources. Browse if you want the original framing.
Same topic, related formats. Practice these next.