chore: release v2.5.1 — add mcp-name token to README for registry validation

[cmeans-claude-dev]

Patch release fixing the v2.5.0 publish-registry failure.

What happened

v2.5.0 (PR #124, tag v2.5.0 pushed) ran publish.yml. publish-pypi succeeded — mcp-clipboard 2.5.0 is on PyPI. But publish-registry (the first-ever firing of the registry-publish workflow added in #120) failed:

Error: publish failed: server returned status 400
{"title":"Bad Request","status":400,"detail":"Failed to publish server",
 "errors":[{"message":"registry validation failed for package 0 (mcp-clipboard):
   PyPI package 'mcp-clipboard' ownership validation failed.
   The server name 'io.github.cmeans/mcp-clipboard' must appear as
   'mcp-name: io.github.cmeans/mcp-clipboard' in the package README"}]}

The MCP registry validates ownership by looking for that literal token in the README that ships with the PyPI package. mcp-synology embeds the same comment at README.md:31 (<!-- mcp-name: io.github.cmeans/mcp-synology -->); we missed mirroring this in the registry-setup PR (#120).

Adding the token to main alone doesn't satisfy the v2.5.0 validation — the registry check runs against the already-published v2.5.0 PyPI artifact, whose README is fixed at upload time. The only path forward is a new release that bakes the token into a fresh wheel.

Fix

• README.md: add <!-- mcp-name: io.github.cmeans/mcp-clipboard --> after the intro paragraph, matching mcp-synology's placement.
• pyproject.toml: 2.5.0 → 2.5.1.
• server.json: synced to 2.5.1 via scripts/sync-server-json.py per the new release flow from chore(release): register with MCP Server registry via server.json + publish-registry workflow #120.
• CHANGELOG.md: [2.5.1] entry under ### Fixed explaining the registry validation requirement and the v2.5.0 → v2.5.1 path.

hatchling re-bundles README.md into the wheel's PKG-INFO/long_description on every build, so v2.5.1's PyPI entry will carry the validating string.

What stays as-is

• v2.5.0 on PyPI: stays. PyPI version slots are immutable, and v2.5.0 is functionally correct (all features work). It just doesn't satisfy the registry's ownership check, so it remains unregistered.
• v2.5.1 on PyPI: will land on tag-push, with the validating README.
• v2.5.1 in the MCP registry: publish-registry will re-run on the new tag and register io.github.cmeans/mcp-clipboard for the first time.

Verification

• uv run pytest -q: 599 passed, 19 deselected, 5 xfailed (no test changes).
• uv run ruff check src/ tests/ scripts/: clean.
• python scripts/sync-server-json.py --check: server.json in sync (2.5.1).
• uv build --wheel: builds dist/mcp_clipboard-2.5.1-py3-none-any.whl successfully.

Test plan

• CI green across lint, typecheck, test (3.11/3.12/3.13), integration-x11, version-sync, validate-server-json.
• uv build --wheel succeeds; the wheel's PKG-INFO / long_description includes the mcp-name comment.
• Tag-push fires publish.yml and all three jobs (validate, publish-pypi, publish-registry) land green.
• curl -s 'https://registry.modelcontextprotocol.io/v0/servers?search=mcp-clipboard' returns a hit afterward.

Co-Authored-By: Claude Opus 4.7 (1M context) noreply@anthropic.com

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[cmeans]

LGTM

[cmeans]

QA Review — Round 1

Verdict: Pass — zero findings.

Clean patch release with the right end-to-end fix for the v2.5.0 publish-registry first-run failure. The validating <!-- mcp-name: io.github.cmeans/mcp-clipboard --> token is now embedded in the wheel's METADATA — verified directly on the locally-built wheel. v2.5.0 stays on PyPI (correctly, since PyPI version slots are immutable); v2.5.1 lands with the token, and publish-registry re-runs against the new tag.

Diagnosis check

The PR body's reproduction of the v2.5.0 failure error message is exact, and the fix matches the registry's stated requirement:

registry validation failed for package 0 (mcp-clipboard):
PyPI package 'mcp-clipboard' ownership validation failed.
The server name 'io.github.cmeans/mcp-clipboard' must appear as
'mcp-name: io.github.cmeans/mcp-clipboard' in the package README

The token has to be in the README that ships with the PyPI package, not just the repo. Since v2.5.0 is fixed on PyPI, only a fresh release with the token in PKG-INFO/long_description can satisfy this — exactly what this PR does.

Verification (run locally on chore/release-v2.5.1-registry-fix @ c2f5efb)

Check	Result
uv run pytest -q	599 passed / 19 deselected / 5 xfailed (matches PR body — no test changes)
uv run ruff check src tests scripts	All checks passed
uv run ruff format --check src tests scripts	11 files already formatted
uv run mypy src	Success: no issues found in 4 source files
python3 scripts/sync-server-json.py --check	server.json in sync with pyproject.toml (2.5.1)
uv build --wheel	Successfully built dist/mcp_clipboard-2.5.1-py3-none-any.whl
mcp-name token in wheel METADATA	unzip -p dist/mcp_clipboard-2.5.1-py3-none-any.whl 'mcp_clipboard-2.5.1.dist-info/METADATA' | grep mcp-name returns <!-- mcp-name: io.github.cmeans/mcp-clipboard --> (line 63 of METADATA). This is the bytes the registry will see, and they match the required mcp-name: io.github.cmeans/mcp-clipboard token. ✓
Token format	Exact string match per the registry error: mcp-name: io.github.cmeans/mcp-clipboard (HTML-comment wrapped, hyphen between mcp and name, colon-space, full namespaced name). ✓
Token placement	README.md:31 — directly after the intro paragraph, matches the mcp-synology convention referenced in the PR body
Diff shape	4 files: README.md (+2/-0 — token + blank line), pyproject.toml (+1/-1), server.json (+2/-2), CHANGELOG.md (+19/-0). Two-file release-commit shape extended cleanly to four when README is part of the fix.
[Unreleased] after roll	empty, ready for the next cycle
Release date 2026-05-05	matches today
British-spelling grep on new content	clean
CI on c2f5efb	All green: lint, typecheck, test (3.11/3.12/3.13), integration-x11, codecov/patch (100% patch), version-sync, validate-server-json

Test-plan checkbox status (post-review)

• CI green across lint, typecheck, test (3.11/3.12/3.13), integration-x11, version-sync, validate-server-json — verified
• uv build --wheel succeeds; the wheel's PKG-INFO / long_description includes the mcp-name comment — verified end-to-end (the token is at METADATA line 63 of the locally-built mcp_clipboard-2.5.1-py3-none-any.whl)
• Tag-push fires publish.yml and all three jobs land green — post-merge step
• curl -s 'https://registry.modelcontextprotocol.io/v0/servers?search=mcp-clipboard' returns a hit — post-merge step

Follow-up tickets

None. The fix is the smallest possible response to the v2.5.0 failure, and the wheel-level verification confirms the bytes that the registry will see now contain the validating token.

Applying Ready for QA Signoff as the final act.

[cmeans]

QA Audit — PR #125 / round 1

• Branch: chore/release-v2.5.1-registry-fix @ c2f5efb
• Diff: 4 files (README.md +2 with the mcp-name token, pyproject.toml 2.5.0→2.5.1, server.json synced to 2.5.1, CHANGELOG.md [2.5.1] / Fixed entry).
• End-to-end verification of the registry-validation fix: locally-built mcp_clipboard-2.5.1-py3-none-any.whl METADATA line 63 contains exactly <!-- mcp-name: io.github.cmeans/mcp-clipboard -->. This is the bytes that the MCP registry's ownership check sees, and they match the token format the v2.5.0 failure error message asked for.
• Token placement at README.md:31 matches the mcp-synology convention referenced in the PR body.
• All gates clean: pytest 599 passed; ruff/format/mypy clean; sync-server-json --check reports in-sync at 2.5.1; uv build --wheel produces the new wheel.
• 2 of 4 test-plan checkboxes ticked (CI + uv-build-with-token); the other two are post-merge tag-push observations.
• v2.5.0 stays on PyPI as-is (correctly — PyPI version slots are immutable; v2.5.0 is functionally fine, just unregistered); v2.5.1 carries the validating README and publish-registry re-runs on the new tag.
• No findings; no follow-up tickets.

Applying Ready for QA Signoff as the final act.