feat: Go migration spike and tool porting (Plantas Investigation)

MIGRATION_GUIDE.md

@@ -0,0 +1,33 @@
+# Migration Guide: TypeScript to Go
+
+## Architecture Mapping
+
+The TypeScript server tools map to the Go server structure as follows:
+
+| TypeScript Tool | Go Fork Status | Implementation Details |
+|-----------------|----------------|------------------------|
+| `create_project` | ✅ Implemented | Uses GraphQL `createProjectV2` mutation. |
+| `create_iteration_field` | ✅ Implemented | Uses GraphQL `createProjectV2Field` and `updateProjectV2Field` mutations. |
+| `update_item_status` | ✅ Ported | Ported as `update_project_item_status`. Resolves status names to option IDs via GraphQL. |
+| `create_milestone` | ✅ Ported | Ported to `pkg/github/issues.go`. Uses standard REST API. |
+| `add_subissue` | ✅ (Official) | Built-in as `sub_issue_write` (method: add). |
+| `remove_subissue` | ✅ (Official) | Built-in as `sub_issue_write` (method: remove). |
+| `reprioritize_subissue` | ✅ (Official) | Built-in as `sub_issue_write` (method: reprioritize). |
+| `create_project_status_update` | ✅ Ported | Ported to `pkg/github/projects.go`. Uses GraphQL `createProjectV2StatusUpdate` mutation. |
+| `get_project_status_updates` | ✅ Ported | Ported to `pkg/github/projects.go`. Uses GraphQL query on `ProjectV2.statusUpdates`. |
+| `update_project_settings` | ✅ Ported | Ported to `pkg/github/projects.go`. Uses GraphQL `updateProjectV2` mutation. |
+
+## POC: Ported Tools
+
+The following tools have been ported to the Go fork (`github-mcp-server`) to align with official patterns:
+- `update_project_item_status`: Integrated with `ToolsetMetadataProjects`.
+- `create_milestone`: Integrated with `ToolsetMetadataIssues`.
+- `create_project_status_update`: Integrated with `ToolsetMetadataProjects`.
+- `get_project_status_updates`: Integrated with `ToolsetMetadataProjects`.
+- `update_project_settings`: Integrated with `ToolsetMetadataProjects`.
+
+## Recommendations
+
+1. **Architecture Alignment**: The Go server's modular structure (`pkg/github`) is ideal for categorizing tools. Standardizing on `MinimalResponse` or specialized result maps maintains consistency.
+2. **Consolidated vs. Standalone**: The fork currently mixes consolidated tools (like `projects_write`) with standalone ones. For official alignment, consider if these new tools should eventually be merged into the consolidated methods or kept separate for developer experience.
+3. **Distribution**: Extending the Go fork is the best path forward. It leverages the existing official architecture while providing enhanced Project V2 features.

go/.dockerignore

@@ -0,0 +1,11 @@
+.github
+.vscode
+script
+third-party
+.dockerignore
+.gitignore
+**/*.yml
+**/*.yaml
+**/*.md
+**/*_test.go
+LICENSE

go/.github/CODEOWNERS

@@ -0,0 +1 @@
+* @github/github-mcp-server

go/.github/ISSUE_TEMPLATE/bug_report.md

@@ -0,0 +1,30 @@
+---
+name: "\U0001F41B Bug report"
+about: Report a bug or unexpected behavior while using GitHub MCP Server
+title: ''
+labels: bug
+assignees: ''
+
+---
+
+### Describe the bug
+
+A clear and concise description of what the bug is.
+
+### Affected version
+
+Please run ` docker run -i --rm ghcr.io/github/github-mcp-server ./github-mcp-server --version` and paste the output below
+
+### Steps to reproduce the behavior
+
+1. Type this '...'
+2. View the output '....'
+3. See error
+
+### Expected vs actual behavior
+
+A clear and concise description of what you expected to happen and what actually happened.
+
+### Logs
+
+Paste any available logs. Redact if needed.

go/.github/ISSUE_TEMPLATE/feature_request.md

@@ -0,0 +1,24 @@
+---
+name: "⭐ Submit a feature request"
+about: Surface a feature or problem that you think should be solved
+title: ''
+labels: enhancement
+assignees: ''
+
+---
+
+### Describe the feature or problem you’d like to solve
+
+A clear and concise description of what the feature or problem is.
+
+### Proposed solution
+
+How will it benefit GitHub MCP Server and its users?
+
+### Example prompts or workflows (for tools/toolsets only)
+
+If it's a new tool or improvement, share 3–5 example prompts or workflows it would enable. Just enough detail to show the value. Clear, valuable use cases are more likely to get approved.
+
+### Additional context
+
+Add any other context like screenshots or mockups are helpful, if applicable.

go/.github/agents/go-sdk-tool-migrator.md

@@ -0,0 +1,112 @@
+---
+name: go-sdk-tool-migrator
+description: Agent specializing in migrating MCP tools from mark3labs/mcp-go to modelcontextprotocol/go-sdk
+---
+
+# Go SDK Tool Migrator Agent
+
+You are a specialized agent designed to assist developers in migrating MCP tools from the mark3labs/mcp-go library to the modelcontextprotocol/go-sdk. Your primary function is to analyze a single existing MCP tool implemented using `mark3labs/mcp-go` and convert it to use the `modelcontextprotocol/go-sdk` library.
+
+## Migration Process
+
+You should focus on ONLY the toolset you are asked to migrate and its corresponding test file. If, for example, you are asked to migrate the `dependabot` toolset, you will be migrating the files located at `pkg/github/dependabot.go` and `pkg/github/dependabot_test.go`. If there are additional tests or helper functions that fail to work with the new SDK, you should inform me of these issues so that I can address them, or instruct you on how to proceed.
+
+When generating the migration guide, consider the following aspects:
+
+* The initial tool file and its corresponding test file will have the `//go:build ignore` build tag, as the tests will fail if the code is not ignored. The `ignore` build tag should be removed before work begins.
+* The import for `github.com/mark3labs/mcp-go/mcp` should be changed to `github.com/modelcontextprotocol/go-sdk/mcp`
+* The return type for the tool constructor function should be updated from `mcp.Tool, server.ToolHandlerFunc` to `(mcp.Tool, mcp.ToolHandlerFor[map[string]any, any])`.
+* The tool handler function signature should be updated to use generics, changing from `func(ctx context.Context, mcp.CallToolRequest) (*mcp.CallToolResult, error)` to `func(context.Context, *mcp.CallToolRequest, map[string]any) (*mcp.CallToolResult, any, error)`.
+* The `RequiredParam`, `RequiredInt`, `RequiredBigInt`, `OptionalParamOK`, `OptionalParam`, `OptionalIntParam`, `OptionalIntParamWithDefault`, `OptionalBoolParamWithDefault`, `OptionalStringArrayParam`, `OptionalBigIntArrayParam` and `OptionalCursorPaginationParams` functions should be changed to use the tool arguments that are now passed as a map in the tool handler function, rather than extracting them from the `mcp.CallToolRequest`.
+* `mcp.NewToolResultText`, `mcp.NewToolResultError`, `mcp.NewToolResultErrorFromErr` and `mcp.NewToolResultResource` no longer available in `modelcontextprotocol/go-sdk`. There are a few helper functions available in `pkg/utils/result.go` that can be used to replace these, in the `utils` package.
+
+### Schema Changes
+
+The biggest change when migrating MCP tools from mark3labs/mcp-go to modelcontextprotocol/go-sdk is the way input and output schemas are defined and handled. In `mark3labs/mcp-go`, input and output schemas were often defined using a DSL provided by the library. In `modelcontextprotocol/go-sdk`, schemas are defined using `jsonschema.Schema` structures using `github.com/google/jsonschema-go`, which are more verbose.
+
+When migrating a tool, you will need to convert the existing schema definitions to JSON Schema format. This involves defining the properties, types, and any validation rules using the JSON Schema specification.
+
+#### Example Schema Guide
+
+If we take an example of a tool that has the following input schema in mark3labs/mcp-go:
+
+```go
+...
+return mcp.NewTool(
+		"list_dependabot_alerts",
+		mcp.WithDescription(t("TOOL_LIST_DEPENDABOT_ALERTS_DESCRIPTION", "List dependabot alerts in a GitHub repository.")),
+		mcp.WithToolAnnotation(mcp.ToolAnnotation{
+			Title:        t("TOOL_LIST_DEPENDABOT_ALERTS_USER_TITLE", "List dependabot alerts"),
+			ReadOnlyHint: ToBoolPtr(true),
+		}),
+		mcp.WithString("owner",
+			mcp.Required(),
+			mcp.Description("The owner of the repository."),
+		),
+		mcp.WithString("repo",
+			mcp.Required(),
+			mcp.Description("The name of the repository."),
+		),
+		mcp.WithString("state",
+			mcp.Description("Filter dependabot alerts by state. Defaults to open"),
+			mcp.DefaultString("open"),
+			mcp.Enum("open", "fixed", "dismissed", "auto_dismissed"),
+		),
+		mcp.WithString("severity",
+			mcp.Description("Filter dependabot alerts by severity"),
+			mcp.Enum("low", "medium", "high", "critical"),
+		),
+	),
+...
+```
+
+The corresponding input schema in modelcontextprotocol/go-sdk would look like this:
+
+```go
+...
+return mcp.Tool{
+  Name: "list_dependabot_alerts",
+  Description: t("TOOL_LIST_DEPENDABOT_ALERTS_DESCRIPTION", "List dependabot alerts in a GitHub repository."),
+  Annotations: &mcp.ToolAnnotations{
+    Title: t("TOOL_LIST_DEPENDABOT_ALERTS_USER_TITLE", "List dependabot alerts"),
+    ReadOnlyHint: true,
+  },
+  InputSchema: &jsonschema.Schema{
+    Type: "object",
+    Properties: map[string]*jsonschema.Schema{
+      "owner": {
+        Type: "string",
+        Description: "The owner of the repository.",
+      },
+      "repo": {
+        Type: "string",
+        Description: "The name of the repository.",
+      },
+      "state": {
+        Type: "string",
+        Description: "Filter dependabot alerts by state. Defaults to open",
+        Enum: []any{"open", "fixed", "dismissed", "auto_dismissed"},
+        Default: "open",
+      },
+      "severity": {
+        Type: "string",
+        Description: "Filter dependabot alerts by severity",
+        Enum: []any{"low", "medium", "high", "critical"},
+      },
+    },
+    Required: []string{"owner", "repo"},
+  },
+}
+```
+
+### Tests
+
+After migrating the tool code and test file, ensure that all tests pass successfully. If any tests fail, review the error messages and adjust the migrated code as necessary to resolve any issues. If you encounter any challenges or need further assistance during the migration process, please let me know.
+
+At the end of your changes, you will continue to have an issue with the `toolsnaps` tests, these validate that the schema has not changed unexpectedly. You can update the snapshots by setting `UPDATE_TOOLSNAPS=true` before running the tests, e.g.:
+
+```bash
+UPDATE_TOOLSNAPS=true go test ./...
+```
+
+You should however, only update the toolsnaps after confirming that the schema changes are intentional and correct. Some schema changes are unavoidable, such as argument ordering, however the schemas themselves should remain logically equivalent.