Conversation
| // No client specified, prompt user to select one | ||
| var err error | ||
| clientName, err = selectClientInteractively(cmd.OutOrStdout()) | ||
| clientName, err = selectClientInteractively(cmd.ErrOrStderr()) |
There was a problem hiding this comment.
Unrelated to this PR - just noticed it was using stdout before, but we're trying to standardize on stderr for non-structured output.
| if err != nil { | ||
| return fmt.Errorf("failed to create MCP server: %w", err) | ||
| } | ||
| defer server.Close() |
There was a problem hiding this comment.
Unrelated to this PR, but I realized we weren't properly closing the server in case of an error. Close is idempotent, so it should be safe to call it again in the successful case too.
| serverTransport, clientTransport := mcp.NewInMemoryTransports() | ||
|
|
||
| client := mcp.NewClient(&mcp.Implementation{ | ||
| Name: ServerName, | ||
| Version: config.Version, | ||
| }, nil) | ||
|
|
||
| serverSession, err := s.mcpServer.Connect(ctx, serverTransport, nil) | ||
| if err != nil { | ||
| return nil, fmt.Errorf("failed to connect server: %w", err) | ||
| } | ||
| defer serverSession.Close() | ||
|
|
||
| clientSession, err := client.Connect(ctx, clientTransport, nil) | ||
| if err != nil { | ||
| return nil, fmt.Errorf("failed to connect client: %w", err) | ||
| } | ||
| defer clientSession.Close() |
There was a problem hiding this comment.
Creating an MCP client and connecting it to the server via an in-memory transport seemed like the easiest and most fool-proof way of listing all of the server's capabilities (including the proxied tools), without having to duplicate the list of tools/prompts, or complicate the way in which they're registered with the server.
There was a problem hiding this comment.
Almost seems like something the sdk could provide to every server?
We could consider doing a PR upstream? Although I guess this doens't cover all mcp primitives only the ones we use.
There was a problem hiding this comment.
Yeah, if we had access to the mcp.Server's internals, I think we could just iterate over these fields directly, instead of creating a client connection via an in-memory transport. Not sure why they don't already support that, tbh. Maybe they just didn't think many people would have a use for it? We could submit a proposal and see what they say.
| The proxied documentation server ([tiger-docs-mcp-server](https://github.com/timescale/tiger-docs-mcp-server)) currently provides the following tools: | ||
| - `get_guide` - Retrieve comprehensive guides for TimescaleDB features and best practices | ||
| The proxied documentation server ([pg-aiguide](https://github.com/timescale/pg-aiguide)) currently provides the following tools: | ||
| - `view_skill` - Retrieve comprehensive guides for TimescaleDB features and best practices |
There was a problem hiding this comment.
The docs MCP and this tool were both renamed upstream. This is just keeping things in-sync.
2 participants
This PR adds a new
tiger mcp listcommand that lists all of the available MCP capabilities (tools, prompts, resources, and resource templates).It accepts an
-o/--outputflag that controls the output format. The default format istable(or whatever is set viatiger config set outputor theTIGER_OUTPUTenv var), but it also supportsjsonandyamlformats. The JSON and YAML formats are significantly more verbose than the table format (including things like the description, title, input/output JSON schemas, etc.). This is similar to how the JSON and YAML formats work for other commands that support them (such astiger service list).I plan to add another command for getting detailed info about a specific tool/prompt/resource in a future PR (
tiger mcp get/tiger mcp describeor something like that).Related: AGE-287
CC @billy-the-fish for docs update.