Support for Go modules (go install) as a package type #1307

Activity

1. koriyoshi2041 commented on May 29, 2026

   

   koriyoshi2041

   on May 29, 2026

   More actions

   I'd like to take this one — go would round out the package types nicely, given how many MCP servers ship as a single go install-able binary.

   Reading through how the existing types are wired: ValidatePackage in internal/validators/package.go switches on RegistryType and dispatches to the per-registry validators under internal/validators/registries/. Existence + ownership for npm/pypi/etc. works by fetching the published package metadata and checking it carries the server name (npm's mcpName matching serverName).

   Go is a bit different: modules don't carry an arbitrary metadata field we could stuff the server name into — there's no mcpName equivalent in go.mod — so the npm-style "package declares its MCP name" check doesn't map directly.

   What does map cleanly is that a Go module path is its source location. For a server published under the io.github.<owner>/... namespace with a module path of github.com/<owner>/<repo>/..., the publisher already authenticated for that GitHub namespace and the module is rooted at the same repo, so matching the owner segment proves ownership without needing anything extra inside the module. Existence/version can be confirmed against the module proxy (https://proxy.golang.org/<case-encoded-module>/@v/list and /@latest).

   Does that ownership model sound acceptable, or would you prefer an explicit marker (sentinel file / go.mod directive) so non-GitHub module paths can be supported too? Happy to implement once the approach is settled — looks like a new model.RegistryTypeGo, a case in the switch, and a registries/go.go validator + tests mirroring the existing ones.

   👍React with 👍1Reacted by Antoine
2. P4ST4S commented on May 29, 2026

   

   P4ST4S

   on May 29, 2026 · Hidden as spam

   Author

   show commentMore actions
3. koriyoshi2041 commented on May 30, 2026

   

   koriyoshi2041

   on May 30, 2026

   More actions

   Opened #1321 implementing this. It follows the v1 shape we discussed: GitHub-namespace ownership (io.github.<owner> ⇒ module rooted at github.com/<owner>/..., owner compared case-insensitively), existence verified via proxy.golang.org, non-GitHub paths left as a follow-up. identifier is the module path. Happy to iterate on edge cases — and if you want to be the first publisher once it lands, github.com/P4ST4S/mcp-audit should validate cleanly.

   👍React with 👍1Reacted by Antoine
4. koriyoshi2041

   added a commit that references this issue on May 30, 2026

   feat: support Go modules as a package type

   ...

   This issue will close once commit f6fa124 is merged into the 'main' branch.

   f6fa124
5. lsequeiraa commented on Jun 2, 2026

   

   lsequeiraa

   on Jun 2, 2026

   Last edited by lsequeiraa

   More actions

   +1, hit the same wall publishing io.github.lsequeiraa/mcp-sidecar, a Go MCP server whose canonical install is go install github.com/lsequeiraa/mcp-sidecar@latest.

   Since "wrap it in npm" comes up as the suggested workaround, a concrete data point on what that actually costs:

   • Wrapper package (mcp-sidecar) with a bin.js that resolves the platform binary via require.resolve.
   • Five platform packages (@mcp-sidecar/{darwin-arm64,darwin-x64,linux-arm64,linux-x64,win32-x64}) listed as optionalDependencies so npm picks the right one per host.
   • GoReleaser for the Go binaries, plus a CI step that cross-compiles a second time for npm, version-bumps every sub-package, and npm publishes six packages per release.
   • "registryType": "npm" in server.json, even though the artifact is a Go binary.

   It works (same pattern esbuild/swc/biome use), but it's a lot of mechanism for a tool whose canonical install is one go install command. Native registryType: "go" would collapse that to publishing the module and writing the server.json.

   #1321 looks like the right shape: ownership anchored in the GitHub namespace the publisher already authenticates for, existence via proxy.golang.org. Would be great to see it land.

   👍React with 👍1Reacted by Antoine
6. koriyoshi2041

   added 2 commits that reference this issue on Jun 3, 2026

   feat: support Go modules as a package type

   ...

   This issue will close once commit 13a0e7c is merged into the 'main' branch.

   13a0e7c

   feat: support Go modules as a package type

   ...

   This issue will close once commit b42b684 is merged into the 'main' branch.

   b42b684
7. localden

   closed this as completedon Sep 28, 2026