Skip to content

Conversation

@dimetron
Copy link
Collaborator

  • Migrated to github.com/modelcontextprotocol/go-sdk
  • Added argocd tools

@dimetron dimetron requested a review from EItanya as a code owner November 18, 2025 17:00
@dimetron dimetron self-assigned this Nov 18, 2025
return &mcp.CallToolResult{
Content: []mcp.Content{&mcp.TextContent{Text: fmt.Sprintf("istioctl proxy-status failed: %v", err)}},
IsError: true,
}, nil
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should we return error here too, instead nil?

namespace := ""
configType := "all"

if val, ok := args["pod_name"].(string); ok {
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: I'd extract this functionality into a separate function - something like:

func getValueOrDefault(args map[string]interface{}, field string) string {
    if val, ok := args[field].(string); ok {
		return val
	  }
   return ""
}

namespace = val
}
if val, ok := args["all_namespaces"].(string); ok {
allNamespaces = val == "true"
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should the val be transformed to lower case and then compared?

Copy link
Contributor

@EItanya EItanya left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Leaving the partial review as this PR is quite large. Spoke offline about switching tool function definitions to use generics

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we need this test? I think it should be the responsibility of the upstream library to test this. Maintaining this on our side seems unnecessary

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same question about testing core mcp library functionality.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So I understand what you are trying to do here, but I think running the built binary adds an unnecessary level of complexity to the test. Why can't we just use the server object from this repo, and the official mcp-go client?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we need 4 separate tests for this, since this is an integration test I think we can just test all in one

  1. Launch
  2. init
  3. List
  4. Call

)

// StdioTestServer represents a server instance for stdio transport testing
type StdioTestServer struct {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This type seems to be functionally equivalent to the ComprehensiveTestServer, can we re-use that? Also same question about using the mcp-go client instead of recreating all of that logic here again

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants