请求、响应与通知

Under the hood, MCP speaks JSON-RPC. Every exchange is just one of three message shapes, and once you know them the wire stops feeling like magic.

A request asks the other side to do something and expects an answer. It carries an id so the reply can be matched back to it later.

A response answers exactly one request. It echoes the same id, so the client always knows which question it is replying to.

A notification is a one-way heads-up. It looks like a request but has no id, so nobody sends a reply back.

The presence of an id is the whole difference: with an id you owe a reply, without one you do not. That single field separates requests from notifications.

JSON-RPC is symmetric, so MCP is too. The server can send requests to the client, not just the other way around. Both parties play both roles.

Every response carries either a result or an error, never both. Success fills result; failure fills error. You always know which one to read.

MCP uses notifications for live signals like progress, logs, and list changes. No reply is needed, so they keep the conversation flowing freely.

Because each request carries a unique id, many calls can be in flight at once. Replies need not arrive in order; the id keeps everything paired.

Picture a round trip: the client requests tools/list, the server answers with the same id, and then the client knows which tools exist.

These three shapes cover everything MCP needs: ask and wait, answer, or announce. That simplicity is why JSON-RPC was chosen for the protocol.

You spot a JSON-RPC message with no id field. What kind is it?

You learned MCP's whole vocabulary: requests ask with an id, responses answer with that id, and notifications announce with no id at all. Three shapes, endless conversations.