Expose server capabilities as client

[spachava753]

Is your feature request related to a problem? Please describe.
Currently, it looks like there is no way for a ClientSession to return the server's capabilities, leading to users of the ClientSession guessing whether a certain capability is supported by the server. For example, the DeepWiki MCP server only supports the tools capability, and trying to use the List Prompts method returns an error.

Describe the solution you'd like
Instead, I think a method on ClientSession to expose the server's capabilities will allow users to check if method is supported before calling it, potentially saving the network call in cases of connecting to HTTP servers. We already store the server's capabilities in the initialize result:

go-sdk/mcp/client.go

Lines 158 to 164 in 8dd9a81

	type ClientSession struct {
	conn *jsonrpc2.Connection
	client *Client
	initializeResult *InitializeResult
	keepaliveCancel context.CancelFunc
	mcpConn Connection
	}

go-sdk/mcp/protocol.go

Lines 304 to 322 in 8dd9a81

	// After receiving an initialize request from the client, the server sends this
	// response.
	type InitializeResult struct {
	// This property is reserved by the protocol to allow clients and servers to
	// attach additional metadata to their responses.
	Meta `json:"_meta,omitempty"`
	Capabilities *serverCapabilities `json:"capabilities"`
	// Instructions describing how to use the server and its features.
	//
	// This can be used by clients to improve the LLM's understanding of available
	// tools, resources, etc. It can be thought of like a "hint" to the model. For
	// example, this information may be added to the system prompt.
	Instructions string `json:"instructions,omitempty"`
	// The version of the Model Context Protocol that the server wants to use. This
	// may not match the version that the client requested. If the client cannot
	// support this version, it must disconnect.
	ProtocolVersion string `json:"protocolVersion"`
	ServerInfo *Implementation `json:"serverInfo"`
	}

Describe alternatives you've considered
A possible alternative is simply returning an exposed sentinel error, that the user can check with error.Is or error.As. This alternative can also be implemented with the solution described above, offering both ways to understand a server's capabilities as a client.

Additional context
Add any other context or screenshots about the feature request here.

[samthanawalla]

I agree that serverCapabilities should be accessible to the client. I think @findleyr added the serverCapabilities struct, maybe he knows why they were unexported originally?

[jba]

I'm reluctant to expose all these types, but offhand I don't see another way. @findleyr ?

[jba]

I think if we controlled the server, we could return a special error from the ListXXX functions that the client could inspect to see that feature wasn't supported. But we don't—the server could be anything.

[jba]

Ugh. Based on looking at some other SDKs, I think we should go further: let the client see the InitializationResult. That still requires exporting serverCapabilities and everything it contains.

[spachava753]

Ugh. Based on looking at some other SDKs, I think we should go further: let the client see the InitializationResult. That still requires exporting serverCapabilities and everything it contains.

I agree, looking at the InitializationResult, it contains some other fields, like Instructions and Protocol Version that seems useful for the client to access.

Though, I think simply exporting the InitializationResult would allow users to modify the field values, so I think creating a getter on ClientSession, like InitializationResult() would be better, which the getter would return a copy of the initializationResult field in ClientSession. I've done this for ServerCapabilities in #173, but I think it can be extended to the entire ClientSession.initializationResult field. Alternatively, we can set up separate methods for each field, like ClientSession.Instructions(), ClientSession.ServerProtocolVersion(), but that seems like it would achieve the same effect simply creating a ClientSession.InitializationResult() method.

If modification of ClientSession.initializationResult is not a concern as long as it is documented in the doc comments that values in this field should be modified, then we simply just export the field and subtypes of InitializationResult.

[findleyr]

I agree, I don't see any other way (other than something way too complicated, that duplicates the logic of the protocol types). I think we'd prefer not to leak the protocol in this way, but it seems simplest.

The reason they were originally unexported was simply that I defaulted to unexporting everything that wasn't strictly necessary.

[findleyr]

Per discussion in #148, we should probably have an accessor for SessionState.