MCP is built on JSON-RPC 2.0. Does that make it 'just RPC'? What does MCP add beyond raw JSON-RPC?
Free · 2 AI evals / day
**JSON-RPC** is a tiny, generic spec. It tells you how to format a request (a method name, some parameters, an id), how to match a response back to its request, and how to report errors. That is the whole job. It says nothing about which methods exist or what they do.
So no, MCP is not 'just JSON-RPC'. JSON-RPC is the envelope; MCP is the letter inside and the rules of conversation.
MCP layers real meaning on top. It defines a startup handshake where the two sides introduce themselves and agree on what they each support. It defines three named kinds of things a server can offer: tools you can call, resources you can read, and prompts you can fill in. It defines standard method names like `tools/list` and `tools/call` so every server speaks the same dialect.
The payoff is that any compliant host can talk to any compliant server with zero custom code. That shared agreement, not the wire format, is what makes MCP valuable.
No. JSON-RPC 2.0 is only a message-framing convention. It standardizes request and response correlation by id, method dispatch, and a small set of error codes. It deliberately says nothing about which methods exist or what they mean.
MCP supplies exactly those missing semantics as an application-layer protocol. It defines a capability-negotiation lifecycle. The host and server exchange an `initialize` and `initialized` handshake and declare what each side supports. It also defines a typed primitive model with three kinds. Tools are calls the model makes, resources are data it reads, and prompts are templates the host offers users.
MCP also fixes the namespace. Methods like `tools/list` and `resources/read` mean the same thing everywhere. It defines a consent model too, where the host mediates user approval before a tool runs.
The decisive addition is the ecosystem. Because the semantics are standardized, one server you write plugs into Claude Code, Cursor, or Zed unchanged. Without MCP, every team reinvents discovery, consent, and primitive semantics over their own private RPC. That reinvention was the actual status quo before late 2024.
Quick reference
TL;DR
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.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example.
A single closed app calling one in-process tool set with no external servers You gain none of MCP's interop and pay handshake plus process overhead for nothing.
Two services you fully control with a stable bespoke contract already in place Plain JSON-RPC or gRPC is simpler when discovery and cross-vendor reuse are not goals.
Hard real-time paths with a sub-millisecond per-call budget The initialize lifecycle and JSON-RPC framing add latency a tight in-process call avoids.
Quick scan · 2–4 min
Everything important, quickly.
4 min: separate the JSON-RPC envelope from MCP's contract, then enumerate lifecycle, primitives, namespaces, consent, and ecosystem with one concrete host example.
Side-by-side
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-world examples
Real products, models, and research that use this idea.
1Claude Code spawns each configured MCP server, runs the initialize handshake, then calls tools/list to build its catalog before the first user turn.
2Anthropic'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.
3Cursor and Zed adopted MCP in 2025, so a server written for Claude Code drops into both without rewriting the RPC layer.
Interviewer follow-ups
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.
Sign in or go Pro to see the approach for this follow-up.
QWhy standardize a method namespace instead of letting each server name methods freely?
Sign in or go Pro to see the approach for this follow-up.
QHow does the consent model interact with prompt injection from a tool's output?
Sign in or go Pro to see the approach for this follow-up.
Don't say this
Red flags and common mistakes that signal junior thinking. Click to expand.
Most common mistake
Saying MCP is just JSON-RPC with a logo. JSON-RPC frames messages; MCP defines what the messages mean, which is the whole point.