Publish the server entry to the MCP Registry, and let it backfill - #63
Merged
Merged
Conversation
PyPI is one publication; the MCP Registry is the other, and only the first was automated. The registry entry io.github.wandercom/kindex sat at 0.38.0 while 0.39 through 0.44 shipped to PyPI, so every MCP client discovered a version six releases behind what users could install. .github/workflows/publish-mcp.yml publishes on a tag and, through workflow_dispatch, for a release that is already tagged and on PyPI but never reached the registry — so catching up never requires inventing a version number. It refuses a server.json that does not name the tag, and refuses to advertise a version PyPI does not have: the registry must never name something a client cannot install. Authentication is GitHub OIDC, so the io.github.wandercom/* namespace is proven by the repository's own identity and there is no token to hold or rotate. The release checklist gains the registry verification step. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZvSuic9iUQSXAFQoDR2Es
![adaptcom[bot]](https://avatars.githubusercontent.com/in/1609964?s=60&v=4){kind=small}
There was a problem hiding this comment.
Confidence Score: 2/5
Summary
Adds MCP Registry publishing and manual backfills. Automatic releases can fail before PyPI finishes, and the documented verification can select the wrong registry entry.
Important Files Changed
| File | Overview |
|---|---|
| .github/workflows/publish-mcp.yml | Tag-triggered and manual MCP publication with version checks |
| CLAUDE.md | Adds registry release and verification instructions |
| "https://pypi.org/pypi/kindex/json", timeout=30 | ||
| ) as response: | ||
| released = json.load(response)["releases"] | ||
| if tag not in released: |
There was a problem hiding this comment.
Both workflows start on the same tag, so this check can fail before PyPI finishes; run MCP publication after successful PyPI publishing or add bounded retries.
| 7. Watch the workflow: `gh run watch <id> -R wandercom/kindex` -- all three jobs (test, build, publish) must pass | ||
| 8. Verify on PyPI: `pip index versions kindex 2>/dev/null | head -1` or check https://pypi.org/project/kindex/ | ||
| 9. Verify the MCP listing metadata is current: `server.json` version/package fields match the release, and https://mcpmarket.com/server/kindex reflects the published package after indexing. | ||
| 9. The tag also publishes the server entry to the MCP Registry (`.github/workflows/publish-mcp.yml`, OIDC, no token; it refuses to publish a version PyPI does not have, and can be run by hand with `gh workflow run publish-mcp.yml -f tag=vX.Y.Z` to backfill a release that was tagged before this existed). Confirm it: `curl -s "https://registry.modelcontextprotocol.io/v0/servers?search=kindex" | grep -o '"version":"[^"]*"' | tail -1` must show the released version. The registry is how MCP clients discover the server, and it stalled at 0.38.0 through six PyPI releases because nothing automated it. |
There was a problem hiding this comment.
The search includes multiple servers and historical versions, so grep/tail can verify the wrong entry; query the exact Wander server’s latest-version endpoint and parse its JSON.
Two findings from review, both real: The tag started the PyPI workflow and the registry workflow at the same moment, so the registry's "is this on PyPI yet" check raced the upload it was meant to depend on — the first real release would have failed the check it was built to satisfy. The registry publish is now a job in the release workflow with `needs: publish`, calling this one as a reusable workflow, so it cannot start before PyPI finishes. Bounded retries (20 x 15s) remain for PyPI's own index propagation, which lags a successful upload; a version that never appears is a failed release and this fails with it rather than waiting. The documented verification piped a `search=kindex` result through `grep | tail -1`. That search matches substrings across every server and every historical version — `io.github.jmcentire/kindex` and every release back to 0.19.0 come back too — so the position it picked was arbitrary. Both the doc and a new confirmation step now match the exact server name and the registry's own `isLatest` flag. `workflow_dispatch` still backfills a release tagged before any of this existed. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZvSuic9iUQSXAFQoDR2Es
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
2 participants
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.
The gap: PyPI publishing is automated; MCP Registry publishing never was.
io.github.wandercom/kindexsits at 0.38.0 while 0.39 through 0.44 shipped to PyPI, so every MCP client discovers a version six releases behind what users can install.This PR:
.github/workflows/publish-mcp.ymlpublishes the server entry on a tag, and viaworkflow_dispatchfor a release already tagged and on PyPI that never reached the registry — so catching up doesn't require inventing a version number.It refuses a
server.jsonthat doesn't name the tag, and refuses to advertise a version PyPI doesn't have: the registry must never name something a client can't install. Auth is GitHub OIDC, so there's no token to hold or rotate.After merge, backfill 0.44.0 with:
Test suite: 1335 passed. The one failure (
test_installed_console_script_transfers_and_reopens_for_recall) is environmental — it needs the package installed in the running venv — and fails identically at the pre-change commit.🤖 Generated with Claude Code
https://claude.ai/code/session_01EZvSuic9iUQSXAFQoDR2Es