Complete the JSON-RPC 2.0 request structure used by MCP

MCP doesn't invent its own wire format. It rides on **JSON-RPC 2.0**, a tiny, well-known standard for remote procedure calls expressed as JSON objects. A request object carries four fields. `jsonrpc` is always the string "2.0" and tells the receiver which spec to follow. `method` names the operation, like `tools/call` or `resources/read`. `params` is an object holding the arguments for that operation. `id` is a number or string that lets you match a reply back to the request that triggered it. The response comes back with the same `id` plus either a `result` field on success or an `error` field on failure, never both. That id is how the host knows which pending call the answer belongs to when several are in flight. There's one special case. If you send a request with no `id`, it becomes a notification, a fire and forget message that gets no response. MCP uses these for events like progress updates where no reply is needed.

MCP messages are plain **JSON-RPC 2.0** objects. There are three message shapes. A request has four fields. The version marker `jsonrpc` is the literal string "2.0". The `method` field names the operation, such as `tools/call`. The `params` field is an object holding the arguments. The `id` field is a number or string used to correlate the eventual response. The receiver must echo that same id back. A response carries the matching id and exactly one of two fields. On success it returns `result`. On failure it returns `error`, an object with a numeric code and a message. A response never includes both result and error at once. A notification looks like a request but omits `id`. That omission is the whole signal. It means fire and forget, so no response is expected or sent. MCP uses notifications for one-way events like progress and cancellation. The host correlates concurrent calls purely by id. That is why two in-flight requests must never reuse the same value.