What does MCP add beyond JSON-RPC 2.0 that makes it more than 'just RPC'?
JSON-RPC is only the envelope. MCP adds a lifecycle handshake, typed Tools/Resources/Prompts primitives, a consent model, and a shared server ecosystem.
JSON-RPC is like the postal system: a standard way to put a request in an envelope, mail it, and get a reply back. That is useful, but it tells you nothing about what is inside the letters or how two strangers should start a conversation. MCP is the etiquette and shared vocabulary layered on top. It says how a client and server introduce themselves and agree on what each can do. It defines three kinds of things a server offers: actions to run, data to read, and templates to reuse. It says the user must approve risky actions. And because everyone follows the same etiquette, one server you build works with many different apps without rewiring.
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.
The phrase 'MCP is just JSON-RPC with extra steps' is a tempting but wrong simplification, and interviewers use this exact question to see whether you can separate a transport from a protocol. They are not the same kind of thing. One is a way to move bytes; the other is a contract about what those bytes mean and how two parties cooperate.
JSON-RPC 2.0 is a small, generic specification. It tells you how to format a request with a method name, parameters, and an id, how to format a matching response or an error, and how to send a fire and forget notification. That is the whole story. It is deliberately content-agnostic, the same framing carries a stock quote, a database query, or a request to launch a rocket.
MCP picks JSON-RPC as its transport and then adds four things that JSON-RPC pointedly leaves undefined: a connection lifecycle, a typed primitive model, a security and consent model, and a shared ecosystem. Those four additions are exactly what turn raw message framing into a usable protocol for connecting language models to tools and data, and the multiple-choice distractors are designed to tempt you toward smaller, transport-level changes like a new encoding or a WebSocket upgrade. Those would be improvements to the envelope; they are not what made MCP matter. This deep dive walks each real addition and arms you to defend the distinction crisply in an interview.
The lifecycle: capability negotiation
Bare JSON-RPC has no concept of a session opening. You just start sending methods and hope the other side understands them. That is fine for a fixed internal API where both ends ship together, but it is useless when an arbitrary client meets an arbitrary server and neither knows the other's feature set in advance.
MCP fixes this with an explicit handshake. The client opens a connection and sends an initialize request that declares its protocol version and a set of capability flags, things like whether it supports resource subscriptions, prompt listing, or sampling. The server replies with its own version and the capabilities it actually offers. Once the client sends the initialized notification, both sides share a precise, mutually-agreed picture of the feature subset they will use for the rest of the session.
This negotiation is doing real work, and it is easy to undersell in an interview. It is what lets the specification evolve without breaking older peers: a newer client talking to an older server simply settles on the intersection of what both understand, and neither has to assume a capability the other lacks. It also turns the connection into a stateful session rather than a sequence of unrelated calls, which is what later features like subscriptions and progress notifications depend on.
JSON-RPC gives you none of this. It is stateless and version-blind. You would have to design, document, and enforce a versioning and discovery scheme yourself, and every server author would do it differently, which is precisely the fragmentation MCP exists to prevent.
Situations where this technique stops working.
2–4 min · Everything important, quickly.
| Concern | JSON-RPC 2.0 | MCP |
|---|---|---|
| What it is | Generic message-framing standard | AI-to-tool connectivity protocol |
| Lifecycle | None; stateless request and reply | initialize / initialized handshake, capability negotiation |
| Typed semantics | None; method names are opaque | Tools, resources, prompts with defined meaning |
| Security model | Out of scope | Host-mediated user consent per tool call |
| Ecosystem | Just a spec | Thousands of interoperable servers and clients |
Real products, models, and research that use this idea.
- Claude Code, Cursor, and Zed all run the same community MCP servers unchanged because they share one wire contract.
- Anthropic's reference servers for filesystem, GitHub, Postgres, and Slack each speak the initialize handshake before exposing tools.
What an interviewer would ask next. Try answering before peeking at the approach.
QWhat exactly is negotiated during the initialize handshake, and why does it matter for compatibility?
Protocol version plus each side's capability flags; it lets new and old peers agree on a feature subset so the spec can evolve without breaking clients.
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 MCP a thin wrapper over JSON-RPC. The transport is reused, but the lifecycle, typed primitives, consent model, and ecosystem are what make it a protocol.
60 second bullets to scan on the way to the call.
Why JSON-RPC alone is only message framing
The initialize and initialized handshake and what it negotiates
Primary sources. Browse if you want the original framing.
Same topic, related formats. Practice these next.