Add MCP Registry sync pilot — workflow + drift-visible badges#2
Merged
Conversation
Per Patton's 2026-05-16 review on the version-drift architecture: solar-mcp is the pilot repo for the registry-sync rollout. Once this ships and the next real solar-mcp release demonstrates the workflow end-to-end, the same pattern fans out to the other 12 MCP repos. Changes: - .github/workflows/publish.yml — appended 'registry-publish' job that runs after PyPI publish succeeds. Uses GitHub OIDC for auth (no PAT to manage). Bumps server.json in-memory to the tag version before invoking 'mcp-publisher publish'. - README.md — added PyPI + MCP Registry shields.io badges side-by-side for visible-drift transparency. Plus a one-liner explaining the forward-only sync model. - CHANGELOG.md — '[Unreleased]' section documenting the CI hygiene addition and the known drift on pre-0.2.1 versions. Forward-only sync (per Patton's Option C): existing Registry entries stay stale until each server's next real release naturally catches them up. No content-free version bumps for hygiene's sake — that would corrupt the version history permanently to fix a temporary problem. The badges make the staleness transparent rather than hidden. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
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
1 participant
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.
Summary
solar-mcp is the pilot repo for the MCP Registry sync rollout. Once this ships and the next real solar-mcp release demonstrates the workflow end-to-end, the same pattern fans out to the other 12 qso-graph + IONIS-AI MCP repos (per Patton's 2026-05-16 architecture review).
No release triggered by this PR — it just wires up the automation. The next time solar-mcp tags a real release, the registry-publish job runs automatically.
Why
We found a real operational gap after the fleet rollouts: PyPI has the current versions of every MCP, but the Official MCP Registry is months behind on every server. Registry-listed
solar-mcpis v0.1.1; PyPI is v0.2.1. Discovery surfaces (Claude Desktop's MCP browser, mcp.so, third-party catalogs) show our packages at stale versions that don't haveget_version_infoor the security fixes from earlier.The fix has two layers:
Per Patton's review, the forward-only model is the right discipline. Tagging content-free patch releases just to sync the Registry would corrupt the version log permanently to fix a temporary visible-drift problem. Better: ship the automation, make the drift visible via README badges + CHANGELOG, let next real release catch the Registry up.
Changes
.github/workflows/publish.yml— newregistry-publishjob. Runs after PyPI publish succeeds (needs: publish). Uses GitHub OIDC auth (no PAT). Bumpsserver.jsonin-memory to the tag version, then./mcp-publisher publish.README.md— added PyPI and MCP Registry version badges side-by-side. If they show different numbers, drift is immediately visible.CHANGELOG.md—[Unreleased]section documenting the CI hygiene addition and the known stale state of pre-0.2.1 versions on the Registry.Reference
Canonical template (copy source for the fleet fan-out): qso-graph/.github TEMPLATES.md
Test plan
After this lands
qso-graph/.github/TEMPLATES.mdand on thesolar-mcprepoArchitectural note (per Patton)
Per-repo copy of the registry-publish job is the right call (same logic as the
ci.ymldecision): publish workflows have higher consequence than test workflows, so isolation matters more. Single point of evolution isqso-graph/.github/TEMPLATES.md; each repo holds its own diff-able copy. Manual coordination of explicit copies > implicit coordination through shared workflow. Auditability is the feature.