|
3 | 3 |
|
4 | 4 | 1. [Lifecycle](#lifecycle) |
5 | 5 | 1. [Transports](#transports) |
| 6 | + 1. [Stdio Transport](#stdio-transport) |
| 7 | + 1. [Streamable Transport](#streamable-transport) |
| 8 | + 1. [Custom transports](#custom-transports) |
| 9 | + 1. [Concurrency](#concurrency) |
6 | 10 | 1. [Authorization](#authorization) |
7 | 11 | 1. [Security](#security) |
8 | 12 | 1. [Utilities](#utilities) |
| 13 | + 1. [Cancellation](#cancellation) |
| 14 | + 1. [Ping](#ping) |
| 15 | + 1. [Progress](#progress) |
9 | 16 |
|
10 | 17 | ## Lifecycle |
11 | 18 |
|
@@ -87,22 +94,37 @@ func Example_lifeCycle() { |
87 | 94 | ## Transports |
88 | 95 |
|
89 | 96 | A |
| 97 | +[transport](https://modelcontextprotocol.io/specification/2025-06-18/basic/transports) |
| 98 | +can be used to send JSON-RPC messages from client to server, or vice-versa. |
| 99 | + |
| 100 | +In the SDK, this is achieved by implementing the |
90 | 101 | [`Transport`](https://pkg.go.dev/github.com/modelcontextprotocol/go-sdk/mcp#Transport) |
91 | | -is used to connect a client or server to a peer. Specifically, it's something |
92 | | -that can create a (logical) bidirectional stream of JSON-RPC messages. Most |
93 | | -transport implementations described below are specific to either the client or |
94 | | -server: a "client transport" is something that can be used to connect a client |
95 | | -to a server, and a "server transport" is something that can be used to connect |
96 | | -a server to a client. However, it's possible for a transport to be both a |
97 | | -client and server transport, such as the `InMemoryTransport` used in the |
| 102 | +interface, which creates a (logical) bidirectional stream of JSON-RPC messages. |
| 103 | +Most transport implementations described below are specific to either the |
| 104 | +client or server: a "client transport" is something that can be used to connect |
| 105 | +a client to a server, and a "server transport" is something that can be used to |
| 106 | +connect a server to a client. However, it's possible for a transport to be both |
| 107 | +a client and server transport, such as the `InMemoryTransport` used in the |
98 | 108 | lifecycle example above. |
99 | 109 |
|
100 | 110 | Transports should not be reused for multiple connections: if you need to create |
101 | 111 | multiple connections, use different transports. |
102 | 112 |
|
103 | 113 | ### Stdio Transport |
104 | 114 |
|
105 | | -<!-- TODO --> |
| 115 | +In the |
| 116 | +[`stdio`](https://modelcontextprotocol.io/specification/2025-06-18/basic/transports#stdio) |
| 117 | +transport clients communicate with an MCP server running in a subprocess using |
| 118 | +newline-delimited JSON over its stdin/stdout. |
| 119 | + |
| 120 | +**Client-side**: the client side of the `stdio` transport is implemented by |
| 121 | +[`CommandTransport`](https://pkg.go.dev/github.com/modelcontextprotocol/go-sdk/mcp#CommandTransport), |
| 122 | +which starts the a given `exec.Cmd` as a subprocess and communicates over its |
| 123 | +stdin/stdout. |
| 124 | + |
| 125 | +**Server-side**: the server side of the `stdio` transport is implemented by |
| 126 | +`StdioTransport`, which connects over the current processes `os.Stdin` and |
| 127 | +`os.Stdout`. |
106 | 128 |
|
107 | 129 | ### Streamable Transport |
108 | 130 |
|
|
0 commit comments