Skip to content

feat(mcp): store/distribution readiness -- release machinery, MCPB bundle, Codex CLI docs #8

Closed

Description

@cristim

Summary

Store and distribution readiness for the CUDly MCP server, covering release metadata, macOS/Linux packaging, the MCPB bundle, and client setup documentation. Phase A tool annotations are tracked separately in LeanerCloud/cloud-commitments-cli#1882.

Implementation slices

Platform contract

CUDly is built and supported on macOS and Linux, with Linux as the deployment target. Windows support is not planned and is outside this issue.

Out of scope

Cutting the first release tag, publishing before all required slices merge, and any third-party directory submission that depends on a live privacy-policy page.

Activity

  1. cristim commented on Aug 25, 2026

    @cristim
    MemberAuthor

    Split into three sequenced PRs per the workstream plan's ~700-line-diff guidance, each based on main independently:

    None of the three carries an auto-close keyword since merge order isn't fixed and any single one merging shouldn't prematurely close this tracking issue. This issue will be closed manually once all three have merged.

  2. cristim commented on Oct 7, 2026

    @cristim
    MemberAuthor

    claimed by cc-mcp-w2

  3. cristim commented on Oct 7, 2026

    @cristim
    MemberAuthor

    Closing as already-done: every slice this issue asks for is implemented in cloud-commitments-mcp, and verified locally on main at 86a698e.

    Evidence per slice:

    B1 + D - version injection and Codex CLI docs. cmd/cudly-mcp/main.go:30 declares var Version = "dev" with a build-time override comment; server.go:45 takes it as NewServer(version string) and passes it to gosdk.Implementation.Version (server.go:54). README.md:96 documents the ~/.codex/config.toml [mcp_servers.<name>] shape, including the project-scoped-trust caveat. Landed in 1159ab1 (CLI #1891). The end-to-end check is a real subprocess, not a unit assertion: cmd/cudly-mcp/version_test.go builds the binary with -ldflags "-X main.Version=..." and asserts over a live stdio initialize handshake. go test ./cmd/cudly-mcp/ -run Version -count=1 passes.

    B2 + B3 - server.json and its CI gate. Root server.json declares $schema https://static.modelcontextprotocol.io/schemas/2025-12-11/server.schema.json and name io.github.LeanerCloud/cudly-mcp, the canonical namespace. .github/workflows/mcp-server-json.yml fails loud on a schema-URL or identity mismatch, validates against the fetched official schema via .github/scripts/server-json-validator/validate.cjs, and its assert-version-matches-tag job fails when server.json.version disagrees with the pushed v* tag. Landed in 14fd3f5 and 420273a (CLI #1892).

    B4 + C - release machinery and the MCPB bundle. .goreleaser.yml builds cmd/cudly-mcp for darwin/linux on amd64/arm64, with CGO_ENABLED=0, the -X main.Version ldflag, per-platform cudly-mcp_{{.Os}}_{{.Arch}} names, and a sha256 checksum file. .github/workflows/release.yml chains consistency-gate (asserts both server.json and mcpb/manifest.json versions match the tag) -> test -> goreleaser -> mcpb -> publish-registry. The mcpb job downloads the release binaries, verifies them with sha256sum -c cudly-mcp_checksums.txt, stages them into the MCPB layout, packs with a pinned @anthropic-ai/mcpb, attests provenance for both binaries and bundle, and uploads the bundle. The publish-registry job patches the placeholder fileSha256/identifier in the ephemeral runner checkout only (never writes back to the repo), verifies the mcp-publisher binary by sha256 and a Sigstore cosign verify-blob against the registry's OIDC identity, then authenticates with mcp-publisher login github-oidc and publishes. No long-lived secret anywhere. Landed in d38a895 with follow-ups 2c6f787, 77c9f21, 2cdc02b (CLI #1893).

    Local verification on main at 86a698e: make build succeeds; go test ./... is green across all three packages (mcp 0.673s, cmd/cudly-mcp 19.815s, tools 5.163s).

    Out-of-scope items stay out of scope, as the issue itself specifies: no release tag has been cut yet (git tag is empty, gh release list is empty), and no third-party directory submission is claimed. Both are gated on a real release existing, and the machinery to make the first one is now in place.

    No code change was needed for this issue, so there is nothing to review or merge here.

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

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions