JSON-RPC

The protocol's core is its use of JavaScript Object Notation (JSON) for all message encoding. This provides a human-readable, language-agnostic, and widely supported data format. Every request, response, and notification is a single, self-contained JSON object. This simplicity enables easy debugging and interoperability across diverse programming environments, from Python and JavaScript to Go and Rust. The MCP (Model Context Protocol) adopts this format for its messages, ensuring compatibility with a vast ecosystem of tools and libraries.

JSON-RPC operates on a fundamental request-response pattern. A client sends a request object to a server, which processes it and returns a corresponding response object.

• Request Object: Must contain jsonrpc (version), method (name of procedure), params (arguments), and id (unique identifier for the call).
• Response Object: Contains jsonrpc, id (matching the request), and either a result field for success or an error field for failure.
• Statelessness: Each request is independent; the server maintains no client state between calls, aligning with RESTful principles and simplifying server design.

Errors are not signaled via HTTP status codes but through a standardized error object within the JSON-RPC response. This object provides precise, machine-readable failure information.

Key components of the error object:

• code: A predefined integer indicating the error type (e.g., -32700 for Parse error, -32601 for Method not found).
• message: A short, human-readable description of the error.
• data: An optional field containing additional, structured information about the error, such as stack traces or validation details.

This structured approach allows clients, like MCP clients, to programmatically detect and handle different failure modes (network, validation, server logic) without parsing ambiguous text messages.

JSON-RPC supports notifications, which are requests that do not require a response from the server. A notification is a request object that omits the id member. The server processes the method but sends nothing back to the client. This is critical for one-way communication patterns, such as:

• Logging events or telemetry.
• Pushing asynchronous updates from server to client.
• Issuing commands where an acknowledgment is unnecessary.

In the context of MCP transports like SSE (Server-Sent Events), notifications enable servers to push real-time updates (e.g., new resource availability) to connected clients without the overhead of a request cycle.

To optimize network performance, JSON-RPC allows clients to send an array of request objects as a single batch. The server processes each request (potentially in any order) and returns an array of response objects, preserving the order of the responses. The responses in the array correspond to the requests that warranted a reply (notifications within the batch do not generate a response). This feature is essential for reducing latency in scenarios where an AI agent needs to invoke multiple tools or fetch several resources from an MCP server in rapid succession, minimizing round-trip communication overhead.

The protocol is explicitly versioned via the jsonrpc member in every message, with "2.0" being the dominant and recommended version. This clear versioning prevents ambiguity. While the core specification is minimal, it is designed for extensibility. Implementations can introduce:

• Custom Error Codes: Beyond the reserved range (-32000 to -32099) for application-specific errors.
• Extended params Structures: To pass complex, nested data.
• Metadata in Messages: Non-standard fields that compliant peers should ignore.

This balance of a strict core with room for extension makes it ideal for frameworks like MCP, which builds its entire model of resources, tools, and prompts atop the stable JSON-RPC 2.0 foundation.

A Remote Procedure Call (RPC) is a fundamental distributed computing protocol that allows a program to execute a subroutine or procedure on another computer across a network as if it were a local call. It abstracts the complexities of network communication.

• Core Mechanism: The client program sends a request message to a server, which executes the specified function and returns a response.
• Key Abstraction: Enables developers to write code that interacts with remote services using familiar local function-call semantics.
• Foundation: JSON-RPC, gRPC, and XML-RPC are all specific implementations of the RPC paradigm, differing in their serialization formats and transport layers.

JSON Schema is a declarative language for validating the structure and content of JSON data. In protocols like MCP, it defines the expected format for tool inputs and resource metadata.

• Validation Role: Ensures that data passed in Tool Invocation requests conforms to a predefined structure, preventing malformed API calls.
• Tool Definition Core: An MCP Tool Definition includes a JSON Schema object that specifies the required parameters, their data types, and any constraints.
• Standardization: Provides a machine-readable contract between clients and servers, enabling automatic Schema Validation and improving interoperability.

Stdio (Standard Input/Output) refers to the standard streams—input, output, and error—that a program uses to communicate with its environment. It is a common and simple MCP Transport.

• Local Integration: In the Stdio Transport model, an MCP client spawns a server process as a subprocess. They exchange JSON-RPC messages by writing to each other's standard input and reading from standard output.
• Framing: Messages are typically delimited by newlines, a form of Message Framing.
• Use Case: Ideal for integrating with local scripts, command-line tools, or databases where the server is a process on the same machine, avoiding network overhead.