phase6: server.json + release workflow for PyPI + MCP registry publish#7
Merged
Merged
Conversation
Phase 6 of the AI-discoverability plan (https://github.com/m-dev-tools/.github/blob/main/docs/ai-discoverability/AI-discoverability-plan.md §7 Phase 6). Adds the two artifacts the maintainer needs so that every future `v*` tag push automates: 1. Build the wheel 2. Attach to a GitHub Release (idempotent if already cut) 3. Publish to PyPI under `m-dev-tools-mcp` via Trusted Publisher OIDC (no stored token) 4. Update the official MCP registry record at registry.modelcontextprotocol.io under the namespace io.github.m-dev-tools/m-dev-tools-mcp via mcp-publisher with GitHub OIDC auth ### server.json (new, repo root) Schema-compliant server.json per https://static.modelcontextprotocol.io/schemas/2025-12-11/server.schema.json. Declares one PyPI package: * name: io.github.m-dev-tools/m-dev-tools-mcp * identifier: m-dev-tools-mcp * registryType: pypi * registryBaseUrl: https://pypi.org (only base URL the official registry accepts) * runtimeHint: uvx * transport: stdio The committed `version` + `packages[0].version` (currently "0.1.0") are templates; the release workflow rewrites both to the tag name before invoking mcp-publisher publish, so a v0.2.0 tag automatically ships v0.2.0. ### .github/workflows/release.yml (new) Single-job workflow keyed to `v*` tag pushes. Steps: * actions/checkout + setup-python@3.12 * pip install build; python -m build --wheel * gh release create with the wheel attached * pypa/gh-action-pypi-publish@release/v1 (Trusted Publisher OIDC — zero stored secrets) * curl-install mcp-publisher (single Go binary; release downloads from modelcontextprotocol/registry) * Python one-liner rewrites server.json's `version` + `packages[0].version` to match the tag * mcp-publisher login github-oidc && mcp-publisher publish Permissions: contents: write (Release creation), id-token: write (PyPI + mcp-publisher OIDC). ### AGENTS.md — Status section + new Release process Status section rewritten — Phase 4 closed 2026-05-11, Phase 6 ships PyPI + registry. Pre-existing "Track A/B/C/D/E" historical phrasing replaced with current state. New "Release process" subsection spells out the maintainer's five-step playbook (bump pyproject + server.json, PR, tag, push) plus the one-time PyPI Trusted Publisher prereq. ### Verified locally * make check — ruff + mypy + 41/41 pytest + manifest + check-agents drift gates all clean. ### What lands next (out of this PR) * Maintainer-side: configure `m-dev-tools-mcp` as a PyPI Trusted Publisher pointing at this workflow. * Then push the next `v*` tag to fire the workflow end-to-end. First run claims the `io.github.m-dev-tools/*` registry namespace and publishes both PyPI + the registry record.
3 tasks
rafael5
added a commit
that referenced
this pull request
May 11, 2026
Bumps every version-bearing surface to 0.2.0 so the next `v0.2.0` tag push fires the release.yml workflow (built in PR #7) end-to-end: GH-Release with wheel attached, PyPI publish via Trusted Publisher OIDC, MCP-registry publish via GitHub OIDC. * pyproject.toml: version 0.1.0 → 0.2.0 * src/m_dev_tools_mcp/__init__.py: __version__ → "0.2.0" * server.json: top-level `version` + packages[0].version → "0.2.0" (release.yml rewrites both at publish time too, so the in-repo copy stays a current-state snapshot rather than a moving target) * dist/mcp-tools.json regen — the version field embeds the package version, so the drift gate catches a forgotten bump ### Verified locally * make check — ruff + mypy + 41/41 pytest + manifest + check-agents drift gates all clean * make build — produces dist/m_dev_tools_mcp-0.2.0-py3-none-any.whl * Fresh-venv install of the wheel exposes `m-dev-tools-mcp --version` → 0.2.0 ### What lands next (after merge) Push a v0.2.0 tag on main. release.yml fires.
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
Phase 6 of the AI-discoverability plan (
§7 Phase 6). Adds the two artifacts so that every futurev*tag push automates:m-dev-tools-mcpvia Trusted Publisher OIDC (no stored token)registry.modelcontextprotocol.iounderio.github.m-dev-tools/m-dev-tools-mcpviamcp-publisherwith GitHub OIDC authserver.json(new, repo root)Schema-compliant against
https://static.modelcontextprotocol.io/schemas/2025-12-11/server.schema.json. Declares one PyPI package:name:io.github.m-dev-tools/m-dev-tools-mcpidentifier:m-dev-tools-mcpregistryType:pypiregistryBaseUrl:https://pypi.org(the only PyPI base URL the official registry accepts)runtimeHint:uvxtransport:stdioCommitted
version+packages[0].version(currently"0.1.0") are templates. The release workflow rewrites both to the tag name before invokingmcp-publisher publish, so av0.2.0tag automatically ships v0.2.0..github/workflows/release.yml(new)Single-job workflow keyed to
v*tag pushes. Steps:actions/checkout+setup-python@3.12pip install build+python -m build --wheelgh release createwith the wheel attachedpypa/gh-action-pypi-publish@release/v1(Trusted Publisher OIDC — zero stored secrets)curl-installmcp-publisherfrommodelcontextprotocol/registryReleasesserver.json's versions to match the tagmcp-publisher login github-oidc && mcp-publisher publishPermissions:
contents: write(Release creation),id-token: write(PyPI + mcp-publisher OIDC).AGENTS.md— Status + new Release processpyproject.toml+server.json, PR, tag, push) plus the one-time PyPI Trusted Publisher prereq.Verified locally
make checkclean — ruff + mypy + 41/41 pytest +check-manifest+check-agentsdrift gates all green.Test plan
make checkcleanserver.jsonvalidates against the published schema (visual diff against the registry'spypiexample ingeneric-server-json.md)m-dev-tools-mcppointing at thisrelease.ymlworkflow (PyPI project settings → Publishing).v0.2.0tag. First mcp-publisher invocation auto-claims theio.github.m-dev-tools/*namespace via the runner's GitHub OIDC token; subsequent tags update the record.Why now
The companion
.githubPR (#43) just reversed the§5.3PyPI deferral and added a new "Phase 6 — Distribution surface" section to the parent plan. The registry-listing constraint (it only accepts NPM / PyPI / NuGet / Docker-OCI / MCPB; not arbitrarygit+...) means PyPI is the natural channel for a Python MCP server. This PR is the cross-repo half of Phase 6.