From the course: Hands-On AI: Building AI Agents with Model Context Protocol (MCP) and Agent2Agent (A2A)

Transport in MCP

From the course: Hands-On AI: Building AI Agents with Model Context Protocol (MCP) and Agent2Agent (A2A)

Start my 1-month free trial

Transport in MCP

“

- [Instructor] Software services need a transport layer to communicate and exchange data. In this video, we will discuss the transport options supported by MCP. Let's begin with the concept of messages. Messages are the unit of communication in MCP. When MCP clients and servers communicate, they do so by exchanging messages. There are a few message types in MCP. A request is a message that is sent from a client to a server in MCP. It usually contains the query for which data needs to be fetched. A response is a message that is sent from the server to the client. A response is returned for each request received by the server, and notification is a message that is initiated by the server to the client. Unlike a response, a notification is self initiated by the server. It is usually used to send alerts to the client if the resource or tool on the server side is updated with new data. All messages are exchanged in JSON-RPC2.0 format between the client and the server. Both MCP client and server uses prebuilt SDKs for communication. This SDKs take care of formatting messages, as well as executing the transport protocol. Next comes the protocol options available in MCP. There are two such options supported. The first option is STDIO. This is the standard input output protocol that is used for software programs running on the same machine to communicate with each other. Here, the client writes to the input stream for a running process and reads from its output stream. This can only be used when the client and server are running on the same machine or virtual machine instance. For STDIO, the client may actually start the MCP server, exchange messages and terminate the server when closing the connection. The second option is the streamable HTTP option with server site event support for notification. With HTTP, the MCP server can be running in a local machine, remote machine, or any public URL. It provides a standard mechanism to communicate with independently running servers. The server service should already be running for the client to contact it. The client will not attempt to start the server. This transport method provides streaming support so the response can be streamed back to the client in case of long running responses like text or video streams. Server notifications can be sent by a callback URL provided by the client using server side events. Let's revisit the MCP architecture example we discussed in an earlier video. For the first MCP client for PGVector, the MCP server can be local and deployed on the same machine as the sales AI assistant. The sales AI assistant will start the PGVector MCP server when needed, and use STDIO for communication. The Salesforce MCP server may be remote and hosted using an HTTP SSE interface. This can even be running in the Salesforce Cloud. The MCP client connects to this server when needed to exchange messages. Irrespective of the transport used, all messages will be exchanged in JSON-RPC 2.0 format.

Contents