What does MCP add beyond JSON-RPC 2.0 that makes it more than 'just RPC'?
JSON-RPC is only the envelope. MCP adds capability negotiation, 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. It mixes up a transport and 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: capability negotiation, 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. The wrong options point to 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.
Capability negotiation
Bare JSON-RPC has no way to state versions or capabilities. 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 explicit negotiation. Every request carries, in its _meta field, the protocol version and the client's capability flags, such as whether it supports elicitation. The client can call server/discover first to learn the server's supported versions and the capabilities it offers, such as tools, resources, or prompts. If the server does not support the requested version, it returns an error listing the versions it does support. The client then retries with a shared version. Both sides work from a precise picture of the feature subset in use.
This negotiation is doing real work. It is what lets the specification evolve without breaking older peers: a newer client talking to an older server settles on the intersection of what both understand, and neither has to assume a capability the other lacks. Each request is also self-contained, so MCP needs no stateful session to remember what was agreed.
JSON-RPC gives you none of this. It has no version or capability negotiation. 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 |
| Negotiation | None; no version or capability exchange | Per-request version and capability negotiation; server/discover |
| 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.
- The MCP project's reference servers, such as the filesystem server, negotiate protocol version and capabilities before exposing tools.
What an interviewer would ask next. Try answering before peeking at the approach.
QWhat exactly is negotiated in each request's _meta field, and why does it matter for compatibility?
The protocol version and the client's capability flags, with the server's capabilities available from server/discover. A server that lacks the version returns an error listing the ones it supports. 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 capability negotiation, 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
How each request negotiates protocol version and capabilities
Primary sources. Browse if you want the original framing.
Same topic, related formats. Practice these next.