99
1010## Lifecycle
1111
12+ The SDK provides an API for defining both MCP clients and servers, and
13+ connecting them over various transports. When a client and server are
14+ connected, it creates a logical session, which follows the MCP spec's
15+ [ lifecycle] ( https://modelcontextprotocol.io/specification/2025-06-18/basic/lifecycle ) .
16+
17+ In this SDK, both a
18+ [ ` Client ` ] ( https://pkg.go.dev/github.com/modelcontextprotocol/go-sdk/mcp#Client )
19+ and
20+ [ ` Server ` ] ( https://pkg.go.dev/github.com/modelcontextprotocol/go-sdk/mcp#Server )
21+ can handle multiple peers. Every time a new peer is connected, it creates a new
22+ session.
23+
24+ - A ` Client ` is a logical MCP client, configured with various
25+ [ ` ClientOptions ` ] ( https://pkg.go.dev/github.com/modelcontextprotocol/go-sdk/mcp#ClientOptions ) .
26+ - When a client is connected to a server using
27+ [ ` Client.Connect ` ] ( https://pkg.go.dev/github.com/modelcontextprotocol/go-sdk/mcp#Client.Connect ) ,
28+ it creates a
29+ [ ` ClientSession ` ] ( https://pkg.go.dev/github.com/modelcontextprotocol/go-sdk/mcp#ClientSession ) .
30+ This session is initialized during the ` Connect ` method, and provides methods
31+ to communicate with the server peer.
32+ - A ` Server ` is a logical MCP server, configure with various
33+ [ ` ServerOptions ` ] ( https://pkg.go.dev/github.com/modelcontextprotocol/go-sdk/mcp#ServerOptions ) .
34+ - When a server is connected to a client using
35+ [ ` Server.Connect ` ] ( https://pkg.go.dev/github.com/modelcontextprotocol/go-sdk/mcp#Server.Connect ) ,
36+ it creates a
37+ [ ` ServerSession ` ] ( https://pkg.go.dev/github.com/modelcontextprotocol/go-sdk/mcp#ServerSession ) .
38+ This session is not initialized until the client sends the
39+ ` notifications/initialized ` message. Use ` ServerOptions.InitializedHandler `
40+ to listen for this event, or just use the session through various feature
41+ handlers (such as a ` ToolHandler ` ). Requests to the server are rejected until
42+ the client has initialized the session.
43+
44+ Both ` ClientSession ` and ` ServerSession ` have a ` Close ` method to terminate the
45+ session, and a ` Wait ` method to await session termination by the peer. Typically,
46+ it is the client's responsibility to end the session.
47+
48+ ``` go
49+ func Example_lifeCycle () {
50+ ctx := context.Background ()
51+
52+ // Create a client and server.
53+ // Wait for the client to initialize the session.
54+ client := mcp.NewClient (&mcp.Implementation {Name: " client" , Version: " v0.0.1" }, nil )
55+ server := mcp.NewServer (&mcp.Implementation {Name: " server" , Version: " v0.0.1" }, &mcp.ServerOptions {
56+ InitializedHandler: func (context.Context , *mcp.InitializedRequest ) {
57+ fmt.Println (" initialized!" )
58+ },
59+ })
60+
61+ // Connect the server and client using in-memory transports.
62+ //
63+ // Connect the server first so that it's ready to receive initialization
64+ // messages from the client.
65+ t1 , t2 := mcp.NewInMemoryTransports ()
66+ serverSession , err := server.Connect (ctx, t1, nil )
67+ if err != nil {
68+ log.Fatal (err)
69+ }
70+ clientSession , err := client.Connect (ctx, t2, nil )
71+ if err != nil {
72+ log.Fatal (err)
73+ }
74+
75+ // Now shut down the session by closing the client, and waiting for the
76+ // server session to end.
77+ if err := clientSession.Close (); err != nil {
78+ log.Fatal (err)
79+ }
80+ if err := serverSession.Wait (); err != nil {
81+ log.Fatal (err)
82+ }
83+ // Output: initialized!
84+ }
85+ ```
86+
1287## Transports
1388
89+ A
90+ [ ` 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
98+ lifecycle example above.
99+
14100Transports should not be reused for multiple connections: if you need to create
15101multiple connections, use different transports.
16102
17103### Stdio Transport
18104
105+ <!-- TODO -->
106+
19107### Streamable Transport
20108
21109The [ streamable
@@ -72,10 +160,16 @@ the server using the streamable transport protocol.
72160
73161#### Stateless Mode
74162
163+ <!-- TODO -->
164+
75165#### Sessionless mode
76166
167+ <!-- TODO -->
168+
77169### Custom transports
78170
171+ <!-- TODO -->
172+
79173### Concurrency
80174
81175In general, MCP offers no guarantees about concurrency semantics: if a client
@@ -95,11 +189,11 @@ for more background.
95189
96190## Authorization
97191
98- ** TODO**
192+ <!-- TODO -->
99193
100194## Security
101195
102- ** TODO**
196+ <!-- TODO -->
103197
104198## Utilities
105199
@@ -121,4 +215,8 @@ server has observed it (see [concurrency](#concurrency)).
121215
122216### Ping
123217
218+ <!-- TODO -->
219+
124220### Progress
221+
222+ <!-- TODO -->
0 commit comments