[ajitpratap0]

Summary

Add the official MCP Registry manifest for io.github.ajitpratap0/gosqlx and automate publication of the existing https://mcp.gosqlx.dev/mcp remote through GitHub OIDC. The workflow validates the stable GitHub release, main ancestry, manifest identity/version/URL, and deployed version before publishing with a pinned, checksum-verified publisher.

Upload release artifacts before downstream dispatches, skip registry dispatch for nonstable tags, and allow up to five minutes for deployment readiness. Explicit dispatch handles releases created with GITHUB_TOKEN. Include the manifest in the existing version-consistency gate and document publication and recovery. The initial 1.16.0 registry entry is published and verified active.

Test Plan

• task check passed after syncing current main, including formatting, vet, lint, and race tests.
• mcp-publisher validate server.json passed against the official registry.
• Workflow YAML and embedded Bash syntax, stable-tag guard cases, and artifact-upload ordering verified.
• Independent review and automated PR review completed with no blockers.
• Publisher SHA-256 matches the official v1.8.1 Linux amd64 release asset: a06c9096dcb9727c13555b6be26c7effa707b01f06a4c561ba7a3635443cf2cc.
• Live MCP initialization and all seven tools verified; registry API read-back matches the manifest.
• All 41 GitHub checks passed on 8b37bb3f09afdcdc838ceb6b19790d38af9e9e44; GitHub reports the PR clean and mergeable.
• OIDC publishing will run from main after merge on a future stable release; the workflow has not been executed in GitHub Actions yet.

Breaking Changes

None.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
gosqlx-website	Ready	Preview	Oct 22, 2026 9:00pm UTC

[github-actions]

Claude finished @ajitpratap0's task in 27s —— View job

---

Review of PR #859: MCP registry manifest and publish workflow

I read the diff and the surrounding files. I did not run the workflow, because it can only execute on GitHub. The PR description says the same. Overall this is well built: the publisher binary is pinned and checksummed, the tag goes through env: rather than being interpolated into the script, permissions are minimal, and there are release, ancestry and manifest gates. The points below are mostly robustness issues.

Medium

1. A failed dispatch skips the artifact upload (release.yml, new "Dispatch MCP Registry publish" step). The dispatch step runs before "Upload assets". If gh workflow run fails, for example on a transient API error or a missing actions: write, the job fails and dist/ is never uploaded. The same risk already exists for the Glama dispatch, and this PR adds a second one. Either move the upload step above both dispatches, or add continue-on-error: true to the dispatch steps. The release itself is already published by then, so a failed registry dispatch shouldn't cost you the artifacts.
2. Prerelease tags make the dispatched run fail. release.yml dispatches unconditionally, but publish-mcp.yml rejects prereleases in its verify step. A v1.17.0-rc1 tag would be rejected by the ^v[0-9]+\.[0-9]+\.[0-9]+$ check, so every RC would leave a red run. Consider guarding the dispatch step with something like if: ${{ !contains(github.ref_name, '-') }}, matching however GoReleaser decides prerelease.
3. The two-minute deploy window may be tight. The workflow is dispatched immediately after GoReleaser, and then it polls /health for about 2 minutes (12 attempts, 10s apart). If the deploy of the new version takes longer, the run fails and someone has to rerun it by hand. That is documented, but since this path is automated, consider a longer window (5–10 minutes; timeout-minutes: 10 leaves room for it). Alternatively, trigger the dispatch from the deploy workflow once the deploy finishes.

Low
4. Duplicate runs. The workflow listens for release: published and also gets dispatched from release.yml. For GoReleaser releases made with GITHUB_TOKEN there is no overlap. If a maintainer publishes a release by hand and release.yml also runs, both runs share one concurrency group and run one after the other. The second would likely hit the registry's duplicate-version rejection and show up as a failure. It's benign, but the docs could mention it.
5. Re-running after main moves on. The job checks out main rather than the tag so the 1.16.0 backfill works. If main later bumps server.json to a newer version, a retry for an older tag fails the .version == $version check. That fails safe, and the docs already say to keep the manifest at the intended version. It means the backfill and retry procedure only works while main's server.json still matches the tag.
6. Test coverage (version_manifests_test.go). Adding server.json to the version gate is the right move. The test checks only version. The workflow separately depends on name and the remote URL. A small test asserting those two, or at least that remotes[0].url is https://mcp.gosqlx.dev/mcp, would catch drift before release time instead of in the workflow.
7. Nit. The release.yml diff adds the trailing newline at the end of the file. That's fine.

Security

• OIDC is scoped only to the publish job (id-token: write), and persist-credentials: false is set. Good.
• Third-party code is limited to the checksum-verified mcp-publisher v1.8.1 binary. I could not independently confirm the SHA-256 digest, so verify it against the upstream release's checksums file before merging.
• workflow_dispatch is restricted to refs/heads/main, and the tag input is regex-validated. Good.

Verdict: No blockers. I'd address items 1 and 2 before merge, since they affect the automated release path, and consider item 3.
· Branch: chore/mcp-registry

[github-actions]

Claude finished @ajitpratap0's task in 22s —— View job

---

Review of PR #859: MCP registry manifest and publish workflow

I read the full diff against origin/main. I did not run the workflow, because it can only execute on GitHub.

The previous review's main points are already fixed in the current head (6db6741):

• The "Upload assets" step now runs before both dispatch steps in release.yml. A failed dispatch no longer costs the dist/ artifacts.
• The MCP dispatch skips non-vX.Y.Z tags, so release candidates no longer produce a red run.
• The deploy wait is now 300s (timeout-minutes: 10), up from about 2 minutes.

Remaining suggestions (none are blockers):

1. Test coverage. pkg/gosqlx/version_manifests_test.go checks only server.json's version. The workflow also depends on name and on a streamable-http remote with the URL https://mcp.gosqlx.dev/mcp. A small test asserting those would catch drift at PR time instead of at release time.
2. Dispatch failure is still fatal. The release and assets are already published when the dispatch steps run. A transient gh workflow run failure marks the whole release job red. Consider continue-on-error: true on the two dispatch steps, or accept the red run as a useful signal.
3. Duplicate runs. A manually published release can trigger both the release: published event and the dispatch from release.yml. They share a concurrency group, so they run one after the other. The second run will likely hit the registry's duplicate-version rejection. This is benign, and one line in docs/MCP_REGISTRY.md would cover it.
4. Retries only work while server.json on main matches the tag. The job checks out main rather than the tag, and the .version == $version check fails safe. The docs already mention this. It may be worth stating explicitly that a retry for an older tag fails once main's manifest has moved on.
5. Checksum. I couldn't independently confirm the mcp-publisher v1.8.1 SHA-256 (a06c9096…). Please check it against the upstream release's checksums file before merging.

Security: The tag reaches the scripts through env:, not by interpolation, and is regex-validated. id-token: write is scoped to the publish job only. persist-credentials: false is set. workflow_dispatch is limited to refs/heads/main. The publisher binary is pinned and checksum-verified.

Verdict: No blockers. Items 1 and 5 are the ones I'd do before merge.
· Branch: chore/mcp-registry

[github-actions]

Claude finished @ajitpratap0's task in 24s —— View job

---

Review of PR #859: MCP registry manifest and publish workflow

I read the full diff against origin/main. I did not run the workflow, because it can only execute on GitHub.

Fixed since the earlier reviews: the manifest checks (name, version and streamable-http remote URL) are now enforced in the workflow's verify step. "Upload assets" runs before both dispatches. The MCP dispatch skips non-vX.Y.Z tags. The deploy wait is 300s with timeout-minutes: 10.

Remaining suggestions (none are blockers):

1. Test coverage. pkg/gosqlx/version_manifests_test.go checks only server.json's version. The workflow also depends on name and on the remote URL. A small test asserting those two would catch drift at PR time instead of at release time. The workflow's jq check already enforces them, so this is a nice-to-have.
2. Dispatch failure is still fatal (release.yml). The release and assets are already published when the dispatch steps run. A transient gh workflow run failure turns the release job red. Consider continue-on-error: true on the dispatch steps, or accept the red run as a signal.
3. Duplicate runs. A manually published release can trigger both release: published and the dispatch from release.yml. The two runs share a concurrency group, so they run one after the other. The second run will likely hit the registry's duplicate-version rejection. This is benign. docs/MCP_REGISTRY.md already warns about repeated runs, and one sentence on this case would cover it.
4. Retries for older tags. The job checks out main, so a retry for an older tag fails once main's server.json moves to a newer version. That fails safe. The docs say to keep the manifest at the intended version, and could state this limit outright.
5. Checksum. I could not independently confirm the mcp-publisher v1.8.1 SHA-256 (a06c9096…). Please compare it with the upstream release's checksums file before merging.

Security:

• The tag reaches the scripts through env: and is regex-validated.
• id-token: write is scoped to the publish job.
• persist-credentials: false is set.
• workflow_dispatch is restricted to refs/heads/main.
• The publisher binary is pinned and checksum-verified.
• The release event path also excludes prereleases and drafts.

Verdict: No blockers. Item 5 is the one I'd do before merge. The rest are optional.
· Branch: chore/mcp-registry

[ajitpratap0]

Checksum verified: a06c9096dcb9727c13555b6be26c7effa707b01f06a4c561ba7a3635443cf2cc matches upstream registry_1.8.1_checksums.txt and GitHub's asset digest for mcp-publisher_linux_amd64.tar.gz (review item 5).