feat(mcp): expose server capabilities to client #173
Conversation
This change introduces a new method, `ServerCapabilities()`, on the `ClientSession`. This allows a client to inspect the capabilities of the connected server after the initialization handshake. Previously, the capability-related structs were unexported, and the client session did not provide a way to access them. This change exports the `ServerCapabilities` type and related structs, making them part of the public API. The `ServerCapabilities()` method returns a deep copy of the capabilities to prevent accidental modification of the session's internal state. In addition, this commit also introduces a `.gitignore` file to prevent tracking of unwanted local files, such as generated files and IDE-specific configurations.
|
I filed an issue (#166) earlier, and wanted to create a PR that could serve as a possible implementation, if the feature from the issue gets approved to be implemented |
| @@ -0,0 +1,27 @@ | |||
| ### Go.AllowList template | |||
| @@ -174,6 +174,59 @@ func (cs *ClientSession) ID() string { | |||
| return cs.mcpConn.SessionID() | |||
| } | |||
|
|
|||
| // ServerCapabilities returns a copy of the server capabilities obtained during initialization. | |||
| // If the session has not been initialized or capabilities are not available, it returns nil. | |||
| func (cs *ClientSession) ServerCapabilities() *ServerCapabilities { | |||
There was a problem hiding this comment.
I wonder if we can just use an exported field. The doc will say not to modify it, but even if someone does, they're only hurting themselves, as far as I can tell.
Or if we're not sure, let's use the function, but not bother copying until we discover a case where it could matter. But really I think the field suffices.
There was a problem hiding this comment.
I agree with not copying right now.
I think we should go with the cs.ServerCapabilities() function because cs.InitializeResult.Capabilities is a bit cumbersome/less obvious to use. Plus, like you said, we can add copying to ServerCapabilities later.
| @@ -907,46 +907,51 @@ type Implementation struct { | |||
| Version string `json:"version"` | |||
| } | |||
|
|
|||
| // CompletionCapabilities represents server capabilities for argument autocompletion suggestions. | |||
There was a problem hiding this comment.
We say "is" or "are" instead of represents.
Change throughout.
|
@jba @samthanawalla @findleyr I've opened a new PR to address the comments and expose the entire initialized result rather than just the server capabilities via a |
|
Can we close this PR, since #228 is a replacement? |
|
superseded |
This change introduces a new method,
ServerCapabilities(), on theClientSession. This allows a client to inspect the capabilities of the connected server after the initialization handshake.Previously, the capability-related structs were unexported, and the client session did not provide a way to access them. This change exports the
ServerCapabilitiestype and related structs, making them part of the public API. TheServerCapabilities()method returns a deep copy of the capabilities to prevent accidental modification of the session's internal state.In addition, this commit also introduces a
.gitignorefile to prevent tracking of unwanted local files, such as generated files and IDE-specific configurations.