fix(release): bump mcp-publisher to v1.7.6 for new OIDC audience

[pvliesdonk]

Closes #101

Summary

Bumps mcp-publisher from v1.5.0 → v1.7.6 in release.yml.jinja so generated projects' publish-registry job authenticates correctly against the MCP Registry's tightened OIDC audience validation (modelcontextprotocol/registry#1229, merged 2026-04-30).

v1.5.0 requests OIDC audience mcp-registry; v1.7.x requests https://registry.modelcontextprotocol.io, which is what production now expects. The mismatch surfaces as HTTP 401 in the Authenticate to MCP Registry step and was first hit in markdown-vault-mcp's v1.28.0 release.

My review

This is a constants-only change (version + SHA-256) with a comment explaining why for future maintainers. The SHA-256 was verified by downloading the v1.7.6 tarball locally and running sha256sum. No publish-time behavior change in the v1.6/v1.7 changelogs that would affect generated projects' server.json shape — the listed publisher changes (mcpName as authoritative server name in init, copy version from package.json) are interactive init-time, not the publish path the workflow uses.

Downstream

Every generated project (markdown-vault-mcp, image-generation-mcp, scholar-mcp, …) needs a copier update to pick up the bumped pin before its next release. The weekly copier-update.yml cron will handle most of them automatically; markdown-vault-mcp is currently blocked on this and will need a manual dispatch as soon as this lands + a template release goes out.

Test plan

• Pre-commit clean on the changed file (yaml/whitespace/eof).
• SHA-256 verified against the upstream tarball.
• CI green (claude-review on push, gemini auto-review on flip-to-ready).
• After merge + template release, dispatch copier-update on a downstream project (markdown-vault-mcp) to verify the pin propagates and the next release succeeds.

🤖 Generated with Claude Code

[claude]

Claude finished @pvliesdonk's task in 1m 26s —— View job

---

Code Review: fix/mcp-publisher-v1.7.6-oidc-audience

Tasks

• Gather context and understand PR scope
• Read changed file (release.yml.jinja)
• Verify SHA-256 claim and version bump consistency
• Review for correctness, security, and template hygiene
• Post review findings

---

Summary

LGTM. This is a well-scoped, well-documented fix. One minor flag on the SHA-256 digest length and one note on scope.

---

Changed file: .github/workflows/release.yml.jinja (lines 406–418)

What changed

The publish-registry job's Install mcp-publisher step bumps:

• MCP_PUBLISHER_VERSION: v1.5.0 → v1.7.6
• MCP_PUBLISHER_SHA256: updated to match the new tarball
• Adds a multi-line env: comment explaining the OIDC audience breakage

Correctness

The root cause analysis is accurate. v1.5.0 uses OIDC audience mcp-registry; v1.7.x requests https://registry.modelcontextprotocol.io, which production now requires. The id-token: write permission was already present on publish-registry (line 397), so no permission change is needed.

The OIDC comment in the env: block is useful and correctly scoped — it explains why the pin exists, not just what it does. This is good template hygiene.

SHA-256 flag: verify digit count

The hash in the file is:

bcc96ca630cae4cf503b4550bd4a17462d42ad4819273bee56f4385bb059ddee

Counting: 64 hex characters — correct length for SHA-256. ✓

The sha256sum -c verification in the run: block uses the correct two-space delimiter format (<hash> <filename>), so the inline check will pass or hard-fail CI. ✓

Version skip (v1.5.0 → v1.7.6)

The PR body notes v1.6/v1.7 changelog changes (mcpName as authoritative server name, copy version from package.json) affect only the interactive init path, not the publish path this workflow uses. That analysis is correct — generated projects call ./mcp-publisher publish only (line 424), not init. No behavior regression expected. ✓

Scope: linux_amd64 only

The binary pin is architecture-specific (mcp-publisher_linux_amd64.tar.gz). This is fine since ubuntu-latest runners are linux/amd64. No action needed unless runner architecture changes.

Downstream note

The PR body correctly identifies that downstream projects need a copier update + new release to pick up this pin. The weekly copier-update.yml cron handles most; markdown-vault-mcp needs a manual dispatch after this lands + a template release. No changes needed in this PR for that — it's an operational step.

---

Verdict

No blocking issues. The fix is minimal, targeted, and well-commented. Ready to merge after CI green.

[gemini-code-assist]

Note

Gemini is unable to generate a review for this pull request due to the file types involved not being currently supported.

[claude]

Claude finished @pvliesdonk's task in 1m 56s —— View job

---

Code Review: fix/mcp-publisher-v1.7.6-oidc-audience

Tasks

• Gather context and understand PR scope
• Read changed file (release.yml.jinja)
• Verify version bump, SHA-256, and comment accuracy
• Review for correctness, security, and template hygiene
• Post review findings

---

Summary

LGTM. This is a correct, minimal, and well-documented fix. The PR is already merged — this review confirms the change is sound. One minor observation on curl usage that is effectively mitigated by the existing SHA-256 check.

---

Changed file: .github/workflows/release.yml.jinja (lines 406–418)

What changed

The publish-registry job's Install mcp-publisher step (lines 406–418) was updated:

• MCP_PUBLISHER_VERSION: v1.5.0 → v1.7.6
• MCP_PUBLISHER_SHA256: updated hash for the new tarball
• Added a 5-line env: comment explaining the OIDC audience breakage

Correctness ✓

The root cause is accurate. The MCP Registry tightened OIDC audience validation in registry#1229: production now requires audience https://registry.modelcontextprotocol.io. v1.5.0 requests mcp-registry and fails with HTTP 401. v1.7.x is the first release that requests the correct audience. The id-token: write permission was already present on publish-registry (line 397), so no permission change was needed. ✓

SHA-256 verification ✓

bcc96ca630cae4cf503b4550bd4a17462d42ad4819273bee56f4385bb059ddee

64 hex characters — correct length for SHA-256. ✓

The inline check at line 417 uses the correct two-space delimiter format (<hash> <filename>) for sha256sum -c. A tampered or corrupt download will hard-fail CI. ✓

Version skip (v1.5.0 → v1.7.6) ✓

The PR body correctly analyses the v1.6/v1.7 changelogs: mcpName as authoritative server name and copy version from package.json are interactive init-time changes only. Generated projects call ./mcp-publisher publish exclusively (line 424), not init. No behavior regression expected. ✓

Security: supply-chain ✓

The binary is pinned by SHA-256, which neutralises a compromised GitHub release asset. tar xz -f mcp-publisher.tar.gz mcp-publisher (line 418) extracts only the named binary rather than the entire archive — correct targeted extraction. ✓

Minor note: curl -sL without --fail

curl -sL will silently succeed even on HTTP 4xx/5xx, downloading an HTML error page. The SHA-256 check immediately after (line 417) fully mitigates this — an error page will never match the expected hash, so CI will fail loudly. This is not a blocking issue, but adding --fail to the curl invocation at line 416 would make the error message clearer ("HTTP 404" rather than "SHA-256 mismatch"). Fix this →

Architecture scope ✓

The binary pin is linux_amd64 only. This is correct for ubuntu-latest runners. No action needed unless the runner architecture changes.

Comment quality ✓

The comment in the env: block (lines 408–412) explains why the pin exists (OIDC audience validation, upstream PR reference, HTTP 401 symptom) — not just what it does. This is good template hygiene and will help future maintainers avoid regressing it.

---

Verdict

No blocking issues. The fix is minimal, targeted, and correct. Downstream projects will pick up the bumped pin via the weekly copier-update.yml cron; markdown-vault-mcp needs a manual dispatch after the next template release.