MCP uses JSON-RPC 2.0: what does it add beyond raw RPC?
MCP is built on JSON-RPC 2.0. Does that make it 'just RPC'? What does MCP add beyond raw JSON-RPC?
JSON-RPC is only the message envelope. MCP adds the semantics: three typed primitives, a capability-negotiation lifecycle, a consent model, named methods, and a shared ecosystem.
JSON-RPC is like the postal system. It tells you how to put a letter in an envelope, address it, and get a reply back. But it says nothing about what you write inside or what the words mean. Two people could both use the post and still fail to understand each other if one writes in French and the other in Japanese. MCP is the agreed language and etiquette inside those envelopes. It says: first introduce yourself and list what you can do, here is how you ask for a tool versus a file, and here is when to check with the human before acting. Because everyone agrees on that shared language, any writer can talk to any reader without a private dictionary per pair.
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 question is a favorite because it sounds like a gotcha. The setup invites you to say "MCP is built on JSON-RPC, so it's basically just RPC," and a weak candidate takes the bait. The strong answer reframes the question around layering: JSON-RPC and MCP live at different altitudes and do entirely different jobs.
JSON-RPC 2.0 is a message-framing convention. It tells two parties how to package a remote call and route the reply. It is intentionally generic and says nothing about what the calls mean. MCP is an application-layer protocol that supplies those missing meanings: a lifecycle, a typed set of primitives, a fixed namespace, a consent model, and a shared ecosystem of implementations.
The rest of this walkthrough separates the two layers cleanly, then enumerates each thing MCP adds, so you can deliver a crisp, structured answer instead of hand-waving about "more structure."
What JSON-RPC 2.0 actually specifies
JSON-RPC 2.0 is one of the smallest useful protocols in wide use. A request is a JSON object with a method string, an optional params value, and an id that ties the response back to the request. A response carries either a result or an error object with a numeric code and a message. There are notifications, which are requests with no id that expect no reply, and batching, which is an array of requests. That is essentially the entire specification.
Crucially, JSON-RPC defines no methods of its own. It does not know what getWeather or tools/call mean, whether a method has side effects, or how a client should discover the methods a server supports. It defines no notion of a session, no handshake, no versioning, and no authorization. It is pure plumbing: correlation, dispatch, and a uniform error envelope.
It is worth being precise about the boundary, because that boundary is the whole answer to this question. JSON-RPC answers three questions and only three. How do I package a call so the other side can route it? How do I match a reply to the call that produced it? How do I signal a transport or dispatch failure in a uniform way? Everything past that is left to the layer above. The spec is content-neutral on purpose, which is why the same JSON-RPC framing carries Language Server Protocol traffic, Ethereum node calls, and MCP messages without modification.
This minimalism is a feature, not a flaw. JSON-RPC is meant to be a substrate that higher layers build on, the same way TCP is a substrate that HTTP builds on. Nobody calls HTTP "just TCP," because the interesting semantics, methods, status codes, headers, content negotiation, live in the layer above. The mistake the question invites is assuming the substrate is the whole building.
Situations where this technique stops working.
2–4 min · Everything important, quickly.
| Concern | Raw JSON-RPC 2.0 | MCP on top |
|---|---|---|
| What it defines | Message framing only | Application-layer semantics |
| Discovery | None; you invent it | initialize handshake plus capability negotiation |
| Method names | Arbitrary, per app | Fixed: tools/list, tools/call, resources/read |
| Primitives | None | Tools, resources, prompts |
| Consent model | None | Host-mediated per-call approval |
| Interop | Per-pair custom glue | One server runs in any host |
Real products, models, and research that use this idea.
- Claude Code spawns each configured MCP server, runs the initialize handshake, then calls tools/list to build its catalog before the first user turn.
- Anthropic's reference servers for filesystem, GitHub, Postgres, and Slack all speak the same tools/call and resources/read methods, so any host reuses them unchanged.
What an interviewer would ask next. Try answering before peeking at the approach.
QWalk me through what happens during the MCP initialize handshake, field by field.
Client sends protocol version plus its capabilities; server replies with its capabilities and server info; client confirms with an initialized notification before any tools/list call.
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.
Saying MCP is just JSON-RPC with a logo. JSON-RPC frames messages; MCP defines what the messages mean, which is the whole point.
60 second bullets to scan on the way to the call.
What JSON-RPC 2.0 actually standardizes and where it stops
The initialize and initialized handshake and capability negotiation
Primary sources. Browse if you want the original framing.
Same topic, related formats. Practice these next.