SEP-1352: Add gRPC as a transport #1352

Author: Kurtis Van Gent (@kurtisvg) Mark Roth (@markdroth) Harvey Tuch (@htuch)
Status: Draft
Type: Standards Track
Created: 2025-08-15

Abstract

This SEP proposes the addition of gRPC as an official, standardized transport mechanism for the Model Context Protocol (MCP). By leveraging Protocol Buffers (Protobuf) for serialization and HTTP/2 for transport, this proposal aims to provide a high-performance, strongly-typed, and stream-capable alternative to the existing JSON-RPC transport. The primary goals are to meet the performance demands of enterprise applications, enable efficient inter-company communication, and prevent ecosystem fragmentation by establishing a single, community-endorsed gRPC specification for MCP.

Motivation

The Model Context Protocol has seen significant adoption, but its reliance on JSON-RPC over HTTP/1.1 presents performance bottlenecks for latency-sensitive and high-throughput use cases. As discussed in Issue #966, there is a strong and growing demand from the community, particularly from enterprise users, for a more performant communication layer.

The key motivations for this proposal are:

1. Performance and Efficiency: JSON-RPC's text-based nature is verbose and computationally expensive to parse compared to the binary format of Protobuf. gRPC's use of Protobuf and HTTP/2 offers significantly lower latency and reduced network bandwidth usage, which is critical for interactive AI applications and large data payloads. gRPC also brings additional benefits in terms of client-side discovery, load balanced, and security.
2. Enterprise Demand for Interoperability: Numerous enterprise organizations wish to use MCP for inter-company communication. gRPC is a mature and widely adopted standard in these environments. A standardized MCP gRPC transport will allow these organizations to connect their systems reliably and efficiently, fostering a more interconnected ecosystem.
3. Preventing Fragmentation: In the absence of an official standard, multiple organizations have begun creating their own bespoke gRPC implementations of MCP. This is leading to a fragmented ecosystem where tools and servers are incompatible with one another. A formal SEP provides a canonical specification that unifies development efforts and ensures interoperability.
4. Advanced Streaming Capabilities: gRPC provides first-class support for bidirectional streaming. This is a natural fit for many MCP workflows, such as streaming tool outputs, real-time resource updates, or handling long-running, conversational AI agent tasks.
5. Strong Typing and API Contracts: Protobuf definitions (.proto files) create a strict, language-agnostic contract between the client and server. This improves developer experience, reduces runtime errors, and makes the protocol more robust and maintainable.

Specification

1. Protobuf Definition

A new mcp.proto file will be added to the specification, defining the services and messages. In order to maintain compatibility between transports, this proto can be based on (and perhaps even autogenerated from) the schema.js file. SEP-1319 helps separate the data model from the RPC involved, which would enable data consistency between transports. If we are unable to autogenerate from the existing source of truth, we can develop conformance tests to help encourage consistency.

This file can be used to generate gRPC libraries for specific languages that SDKs can use if they wish to implement support for gRPC as a transport layer.

2. Representation in documentation

Today, there are many differences between the two existing transports (STDIO and Streamable HTTP). Most (if not all) of these differences are captured on the Transports page. In addition to updating this page to add gRPC, we can also start making use of Mintlify’s tabs feature to better call-out differences between spec. This is similar to how A2A represents gRPC in their specification.

3. High-performance open-source proxy

To help address compatibility between transports, we should encourage the development of open-source proxies such as mcp-remote for translation between layers. Envoy would be a good base for a high performance proxy to help address this problem.

Rationale

This section details the design decisions behind the proposed gRPC transport, focusing on maintainability, developer experience, and ensuring consistency with the existing MCP specification.

• Consistency Through a Single Source of Truth: A core principle of this proposal is to avoid protocol divergence. By basing the Protobuf definition on the canonical schema.js file, as suggested in the specification, we ensure that the data models for both gRPC and JSON-RPC transports remain compatible.
• Prioritizing Developer Experience and Discoverability: The proposal extends beyond the technical implementation to consider how developers will interact with the specification. The plan to update the documentation using tabs to clearly distinguish between transport-specific details (gRPC, STDIO, HTTP) is a deliberate choice to improve clarity. This makes the specification easier to navigate and implement, reducing ambiguity and lowering the barrier to adoption for both client and server authors.
• Enabling a Unified and Interoperable Ecosystem: The ultimate goal of this rationale is to support the core motivation: preventing ecosystem fragmentation. By providing a gRPC specification that is not only performant but also easy to maintain (via a single schema source) and easy to understand (via clear documentation), this SEP provides a compelling and "official" path for adoption. These design choices are intended to encourage the community to rally around a single standard, ensuring true interoperability between different MCP implementations.

Backwards Compatibility

This SEP is fully backwards compatible. It introduces a new, optional transport layer without altering the existing JSON-RPC specification.

• An MCP server can choose to implement only JSON-RPC, only gRPC, or both.
• An MCP client can be updated to implement as many or as few transports as needed, and the user can opt which to use.
• No changes are required for existing implementations that do not wish to adopt gRPC.

Reference Implementation

// TODO