Predict what happens when a client calls resources/subscribe on a server that did not advertise it
A client completes the initialize handshake with a server. The server's capabilities response does not include the `resources` capability object at all. The client proceeds to send a `resources/subscribe` request for URI `file:///data/config.json`.
The server returns a JSON-RPC error, usually code -32601 Method not found. The deeper point: a correct client never sends this call, because the missing capability was visible at initialize time.
Think of moving into an apartment. On day one the landlord hands you a sheet listing which utilities are connected: water, electricity, internet. Suppose the sheet says nothing about a phone line. If you later pick up a phone and dial, you get dead silence or an error tone, because that service was never wired up. A careful tenant reads the sheet first and simply does not reach for the phone. In MCP, the initialize handshake is that sheet. The server lists which capabilities it offers. If resources is absent and the client calls resources/subscribe anyway, the server replies with an error. But the real mistake happened earlier: the client should have read the sheet and disabled the feature.
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.
This is a predict the output question, and the surface answer is short: the server replies with a JSON-RPC error, conventionally code -32601, Method not found. But the reason it is rated hard is that the interesting part is not the error code. It is the reasoning chain that connects the initialize handshake, capability negotiation, the JSON-RPC contract, and correct client design.
MCP is built on JSON-RPC 2.0, and every session opens with an initialize exchange in which both sides declare what they can do. The server's capabilities object is the authoritative description of its surface for that session. When the resources object is absent, the server has made no promise about resources at all, including subscriptions. There is no fallback default and no implicit enablement: absence means absence.
The scenario then has the client ignore that and fire resources/subscribe anyway. To predict the output correctly you have to know two things at once: what a JSON-RPC server does with an unknown method, and what a well-behaved MCP client should have done long before reaching that point. The first gives you the literal answer; the second is what an interviewer is actually probing when they rate this question hard.
The initialize handshake and capability negotiation
Every MCP session begins with the client sending an initialize request and the server replying with its protocol version and a capabilities object. The client then sends an initialized notification to confirm the handshake is complete. That capabilities object is a map of feature names to their settings. Typical top-level keys are tools, resources, and prompts. Each present key may carry nested sub-flags that refine what the feature supports. The exchange is symmetric, too: the client also declares its own capabilities, such as roots and sampling, so each side knows what the other can do.
The contract is simple and strict. If a capability key is present, the server promises to honor the corresponding methods. If it is absent, the server has declared that surface off limits for this session. There is no implicit default that turns a missing capability on, and there is no autonegotiation step that later adds one. The session is frozen at the values agreed during the handshake.
In this scenario the server's response contains no resources object. The negotiated surface therefore excludes resources/list, resources/read, and resources/subscribe entirely. The client has, in its hands, everything it needs to know that subscribing is not available, before it sends a single resource method. This is the crux of the question: the information needed to avoid the error was delivered to the client at the very first round trip.
Situations where this technique stops working.
2–4 min · Everything important, quickly.
| Behavior | Naive client | Capability-aware client |
|---|---|---|
| Reads capabilities at initialize | No, calls methods blindly | Yes, builds feature set from it |
| Calling resources/subscribe here | Sends it, gets -32601 | Never sends it, feature disabled |
| Failure mode | Runtime JSON-RPC error | Graceful degradation at startup |
| Log noise | High, errors used as discovery | Low, no avoidable error traffic |
Real products, models, and research that use this idea.
- Claude Code and Cursor inspect each MCP server's capabilities at session start and only surface tools or resources the server actually advertised.
- The official MCP TypeScript and Python SDKs route calls to unregistered methods through a JSON-RPC -32601 Method not found response.
What an interviewer would ask next. Try answering before peeking at the approach.
QHow does subscribe differ from a server that advertises resources but not subscriptions?
The resources capability carries nested sub-flags such as subscribe and listChanged; a server can serve resources/read yet still return an error for resources/subscribe if subscribe is false.
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.
Predicting a silent no-op or a crash. The server returns a structured JSON-RPC error, and the real fault is the client skipping capability inspection.
60 second bullets to scan on the way to the call.
What the initialize handshake negotiates
How a server signals a capability is absent
Primary sources. Browse if you want the original framing.
Same topic, related formats. Practice these next.