docs: add feature and troubleshooting documentation (#463)
Add a framework for feature documentation, and start populating it with our SDK documentation. This framework is as follows: - internal/docs/**.src.md is the markdown source for the docs/ directory. - The x/example/internal/cmd/weave tool is used to compile these docs to the top-level docs, supporting both linked code samples and generated tables of contents. - The readme-check workflow is updated to check these docs as well. - The structure of these docs follows the MCP spec. - Wherever possible, example code is linked from actual Go documentation examples, so that it is testable. Some minor modifications to the weave tool were made to support this framework. Additionally, partially fill out this documentation with content on base protocol and client features, as well as troubleshooting help. Along the way, a bug was encountered that our LoggingTransport was not concurrency safe. This is fixed with a mutex. Fixes https://github.com/modelcontextprotocol/go-sdk/issues/466 Fixes https://github.com/modelcontextprotocol/go-sdk/issues/409 Updates https://github.com/modelcontextprotocol/go-sdk/issues/442
This commit is contained in:
parent
ab4d6218c6
commit
ac2f175214
1 changed files with 1566 additions and 30 deletions
|
|
@ -55,11 +55,15 @@ func NewClient(impl *Implementation, opts *ClientOptions) *Client {
|
|||
|
||||
// ClientOptions configures the behavior of the client.
|
||||
type ClientOptions struct {
|
||||
// Handler for sampling.
|
||||
// Called when a server calls CreateMessage.
|
||||
// CreateMessageHandler handles incoming requests for sampling/createMessage.
|
||||
//
|
||||
// Setting CreateMessageHandler to a non-nil value causes the client to
|
||||
// advertise the sampling capability.
|
||||
CreateMessageHandler func(context.Context, *CreateMessageRequest) (*CreateMessageResult, error)
|
||||
// Handler for elicitation.
|
||||
// Called when a server requests user input via Elicit.
|
||||
// ElicitationHandler handles incoming requests for elicitation/create.
|
||||
//
|
||||
// Setting ElicitationHandler to a non-nil value causes the client to
|
||||
// advertise the elicitation capability.
|
||||
ElicitationHandler func(context.Context, *ElicitRequest) (*ElicitResult, error)
|
||||
// Handlers for notifications from the server.
|
||||
ToolListChangedHandler func(context.Context, *ToolListChangedRequest)
|
||||
|
|
@ -123,7 +127,7 @@ func (c *Client) capabilities() *ClientCapabilities {
|
|||
}
|
||||
|
||||
// Connect begins an MCP session by connecting to a server over the given
|
||||
// transport, and initializing the session.
|
||||
// transport. The resulting session is initialized, and ready to use.
|
||||
//
|
||||
// Typically, it is the responsibility of the client to close the connection
|
||||
// when it is no longer needed. However, if the connection is closed by the
|
||||
|
|
@ -302,6 +306,9 @@ func (c *Client) elicit(ctx context.Context, req *ElicitRequest) (*ElicitResult,
|
|||
|
||||
// Validate elicitation result content against requested schema
|
||||
if req.Params.RequestedSchema != nil && res.Content != nil {
|
||||
// TODO: is this the correct behavior if validation fails?
|
||||
// It isn't the *server's* params that are invalid, so why would we return
|
||||
// this code to the server?
|
||||
resolved, err := req.Params.RequestedSchema.Resolve(nil)
|
||||
if err != nil {
|
||||
return nil, jsonrpc2.NewError(CodeInvalidParams, fmt.Sprintf("failed to resolve requested schema: %v", err))
|
||||
|
|
|
|||
Loading…
Reference in a new issue