بنية استدعاء JSON-RPC

Let us dissect one real MCP message field by field. A JSON-RPC call is a small JSON object, and four keys carry all of its meaning.

Every message starts with jsonrpc set to the string 2.0. It marks the dialect so both sides parse the rest the same way.

The id is a number or string that labels a request. The matching response repeats it, so replies never get confused across many calls.

The method string says what you want, like tools/call or resources/read. MCP groups methods with a slash, namespace before the verb.

The params object holds the arguments for that method. For a tool call it names the tool and the values it should receive.

Put the four keys together and you have a complete request. This one asks the server to run the add tool with two numbers.

Some methods need no input at all. When that happens you simply omit params, as tools/list does when it just wants the full catalog.

MCP always passes params as a JSON object with named keys, not a bare list. Names make the arguments self-documenting and order-independent.

The reply mirrors the request: same jsonrpc, same id, but method and params are gone. In their place sits a single result field.

Across MCP traffic you mostly meet tools/list, tools/call, resources/read, and prompts/get. Spot these methods and the intent jumps right out.

Now any MCP line is readable: jsonrpc is the version, id pairs the reply, method is the verb, and params are the inputs. Four keys, full clarity.

In a JSON-RPC request, which field holds the arguments for the method?

You can now read any call: jsonrpc sets the version, id pairs the reply, method names the action, and params supplies its inputs. That is the whole anatomy.