ci: publish to the MCP Registry on every tagged release - #35
Merged
Conversation
The registry listing was hand-published once, at 0.4.1, and nothing kept it current: 0.5.0, 0.5.1, 0.5.2 and 0.6.0 all shipped to PyPI while the registry went on advertising 39 tools from April. Everything the registry needs was already in the repo — server.json, and the `mcp-name:` marker in README.md that proves PyPI ownership — so the only missing piece was the publish itself. The new job runs after the PyPI upload and derives both version fields in server.json from the tag, which is the part that actually stops the drift; leaving them to be bumped by hand is what produced it. It waits for the new version to appear on PyPI first, because ownership is verified by fetching that exact version's metadata and looking for the marker, so a publish that races the index fails the check. Auth is GitHub Actions OIDC — no stored secret, just id-token: write on the job. 0.6.0 was backfilled to the registry by hand; the automation starts at the next tag. Verified locally against the real tooling rather than by inspection: the jq stamp step with GITHUB_REF_NAME=v0.6.1 rewrites both fields; the curl|tar install line produces a working binary whose `login --help` lists github-oidc; `mcp-publisher validate` passes on both the repo's server.json and the stamped copy; the PyPI poll finds 0.6.0 and correctly retries then fails on a version that does not exist. The end-to-end publish cannot be exercised without pushing a tag. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
🟡 Changes recommended
The workflow’s curl | tar install step for mcp-publisher is malformed (missing -f -), and will likely fail on the runner.
Once you've addressed the issues Copilot identified, you can request another Copilot review.
Pull request overview
Adds automated publication of this server’s metadata to the MCP Registry as part of the existing tagged-release workflow, keeping the registry listing in sync with PyPI releases without manual intervention.
Changes:
- Add a
publish-registryjob to the release workflow to stampserver.json, wait for PyPI propagation, then authenticate via GitHub OIDC and publish withmcp-publisher. - Add an
[Unreleased]changelog entry documenting the new release automation. - Ignore the locally downloaded
mcp-publisherbinary in.gitignore.
File summaries
| File | Description |
|---|---|
CHANGELOG.md |
Documents the new MCP Registry publish automation under [Unreleased]. |
.gitignore |
Ignores the ad-hoc mcp-publisher binary when downloaded locally. |
.github/workflows/release.yml |
Adds a post-PyPI job to stamp server.json, wait for PyPI, then publish to the MCP Registry via OIDC. |
Review details
- Files reviewed: 2/3 changed files
- Comments generated: 1
- Review effort level: Lite
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Comment on lines
+102
to
+105
| - name: Install mcp-publisher | ||
| run: | | ||
| curl -L "https://github.com/modelcontextprotocol/registry/releases/latest/download/mcp-publisher_$(uname -s | tr '[:upper:]' '[:lower:]')_$(uname -m | sed 's/x86_64/amd64/;s/aarch64/arm64/').tar.gz" | tar xz mcp-publisher | ||
|
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What does this PR do?
Adds a
publish-registryjob to the release workflow so a tagged release updates the MCP Registry listing, instead of leaving it to be hand-published.The listing was published by hand once, at 0.4.1 in April, and nothing kept it current — 0.5.0, 0.5.1, 0.5.2 and 0.6.0 all shipped to PyPI while the registry went on advertising 39 tools. Everything the registry actually requires was already here:
server.json, and themcp-name:marker inREADME.mdthat proves PyPI ownership. The only missing piece was the publish.The job runs after the PyPI upload and:
versionfields ofserver.json. This is the part that stops the drift — leaving them to be bumped by hand is what caused it.mcp-publisher, validates,login github-oidc, publishes. OIDC means no stored secret — justid-token: writeon the job.0.6.0 was backfilled to the registry by hand, so the listing is current today; the automation takes over at the next tag.
Also gitignores the
mcp-publisherbinary, which lands in the repo root if you run the manual publish from there.Tested Isaac Sim Version(s)
isaac-sim.sh)isaac-sim.newton.sh)What was verified, against the real tooling rather than by reading the YAML:
jqstamp step run verbatim withGITHUB_REF_NAME=v0.6.1→ bothversionfields rewritten to0.6.1.curl | tarinstall line run verbatim → workingmcp-publisher, whoselogin --helplistsgithub-oidcas a supported method.mcp-publisher validateon both the repo'sserver.jsonand the stamped copy →✅ server.json is valid.ruff check . && ruff format --check .clean;pytest271 passed / 43 skipped; workflow parses with the job graph intact (publish-registryneedsbuild-and-publish).Not verifiable without pushing a tag: the end-to-end publish, and the OIDC-to-namespace grant (
io.github.whats2000/*fromwhats2000/isaacsim-mcp-server) — the docs state it as a pattern. The first tagged release is the real test, and it fails visibly rather than silently if the grant is wrong.Before submitting
CHANGELOG.mdunder a new[Unreleased]heading.ruff check . && ruff format .)?Who can review?
@whats2000
🤖 Generated with Claude Code